Недавно сам се суочио са веома необичним задатком подешавања рутирања за МеталЛБ. Све би било у реду, јер... Обично МеталЛБ не захтева никакве додатне радње, али у нашем случају имамо прилично велики кластер са врло једноставном мрежном конфигурацијом.

У овом чланку ћу вам рећи како да конфигуришете рутирање засновано на извору и смерницама за спољну мрежу вашег кластера.

Нећу улазити у детаље о инсталирању и конфигурисању МеталЛБ-а, јер претпостављам да већ имате искуства. Предлажем да пређете директно на ствар, односно на постављање рутирања. Дакле, имамо четири случаја:

Случај 1: Када није потребна конфигурација

Погледајмо једноставан случај.

Додатна конфигурација рутирања није потребна када су адресе које издаје МеталЛБ у истој подмрежи као и адресе ваших чворова.

На пример, имате подмрежу 192.168.1.0/24, има рутер 192.168.1.1, а ваши чворови добијају адресе: 192.168.1.10-30, онда за МеталЛБ можете подесити опсег 192.168.1.100-120 и будите сигурни да ће радити без икаквих додатних конфигурација.

Зашто је то? Пошто ваши чворови већ имају конфигурисане руте:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

А адресе из истог опсега ће их поново користити без икаквих додатних радњи.

Случај 2: Када је потребно додатно прилагођавање

Требало би да конфигуришете додатне руте кад год ваши чворови немају конфигурисану ИП адресу или руту до подмреже за коју МеталЛБ издаје адресе.

Објаснићу мало детаљније. Кад год МеталЛБ избаци адресу, она се може упоредити са једноставним додељивањем као што је:

ip addr add 10.9.8.7/32 dev lo

Обратите пажњу на:

• a) Адреса се додељује префиксом /32 то јест, рута неће бити аутоматски додата у подмрежу за њу (то је само адреса)
• b) Адреса је везана за било који интерфејс чвора (на пример повратну петљу). Овде је вредно поменути карактеристике Линук мрежног стека. Без обзира на који интерфејс додате адресу, кернел ће увек обрадити арп захтеве и послати арп одговоре на било који од њих, ово понашање се сматра исправним и, штавише, прилично се користи у тако динамичном окружењу као што је Кубернетес.

Ово понашање се може прилагодити, на пример, омогућавањем строгог арп-а:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

У овом случају, арп одговори ће бити послати само ако интерфејс експлицитно садржи одређену ИП адресу. Ово подешавање је потребно ако планирате да користите МеталЛБ и ваш кубе-проки ради у ИПВС режиму.

Међутим, МеталЛБ не користи кернел за обраду арп захтева, већ то ради сам у корисничком простору, тако да ова опција неће утицати на рад МеталЛБ-а.

Вратимо се нашем задатку. Ако рута за издате адресе не постоји на вашим чворовима, додајте је унапред свим чворовима:

ip route add 10.9.8.0/24 dev eth1

Случај 3: Када вам је потребно рутирање засновано на извору

Мораћете да конфигуришете рутирање засновано на извору када примате пакете преко посебног мрежног пролаза, а не оног који је подразумевано конфигурисан, стога би пакети одговора такође требало да пролазе кроз исти мрежни пролаз.

На пример, имате исту подмрежу 192.168.1.0/24 посвећен вашим чворовима, али желите да издате спољне адресе користећи МеталЛБ. Претпоставимо да имате више адреса из подмреже 1.2.3.0/24 који се налазе у ВЛАН 100 и желите да их користите за екстерни приступ Кубернетес сервисима.

Приликом контактирања 1.2.3.4 постављаћете захтеве из друге подмреже него 1.2.3.0/24 и сачекајте одговор. Чвор који је тренутно главни за адресу коју је издао МеталЛБ 1.2.3.4, примиће пакет са рутера 1.2.3.1, али одговор за њега мора нужно ићи истим путем, кроз 1.2.3.1.

Пошто наш чвор већ има конфигурисан подразумевани гатеваи 192.168.1.1, тада ће подразумевано одговор ићи њему, а не њему 1.2.3.1, преко које смо примили пакет.

Како изаћи на крај са овом ситуацијом?

У овом случају, морате припремити све своје чворове на такав начин да буду спремни да опслужују спољне адресе без додатне конфигурације. То јест, за горњи пример, потребно је да унапред креирате ВЛАН интерфејс на чвору:

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

Затим додајте руте:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

Имајте на уму да додајемо руте у посебну табелу рутирања 100 садржаће само две руте неопходне за слање пакета одговора кроз мрежни пролаз 1.2.3.1, који се налази иза интерфејса eth0.100.

Сада морамо да додамо једноставно правило:

ip rule add from 1.2.3.0/24 lookup 100

који експлицитно каже: ако је изворна адреса пакета у 1.2.3.0/24, онда треба да користите табелу рутирања 100. У њему смо већ описали руту којом ће га послати 1.2.3.1

Случај 4: Када вам је потребно рутирање засновано на политици

Топологија мреже је иста као у претходном примеру, али рецимо да такође желите да можете да приступите спољним адресама скупова 1.2.3.0/24 из ваших махуна:

Посебност је у томе што приликом приступа било којој адреси у 1.2.3.0/24, пакет одговора погађа чвор и има изворну адресу у опсегу 1.2.3.0/24 биће послушно послат на eth0.100, али желимо да га Кубернетес преусмери на наш први под, који је генерисао оригинални захтев.

Испоставило се да је решавање овог проблема тешко, али је постало могуће захваљујући рутирању заснованом на политикама:

За боље разумевање процеса, ево блок дијаграма нетфилтера:

Прво, као у претходном примеру, направимо додатну табелу рутирања:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

Сада додајмо неколико правила у иптаблес:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

Ова правила ће означити долазне везе са интерфејсом eth0.100, означавајући све пакете ознаком 0x100, одговори унутар исте везе ће такође бити означени истом ознаком.

Сада можемо додати правило рутирања:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

То јест, сви пакети са изворном адресом 1.2.3.0/24 и таг 0x100 морају бити рутирани помоћу табеле 100.

Дакле, други пакети примљени на другом интерфејсу не подлежу овом правилу, што ће им омогућити да буду рутирани помоћу стандардних Кубернетес алата.

Има још нешто, у Линуксу постоји такозвани филтер обрнуте путање, који квари целу ствар; он врши једноставну проверу: за све долазне пакете мења изворну адресу пакета са адресом пошиљаоца и проверава да ли пакет може изаћи кроз исти интерфејс на коме је примљен, ако није, филтрираће га.

Проблем је у томе што у нашем случају неће радити исправно, али можемо да га онемогућимо:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

Имајте на уму да прва команда контролише глобално понашање рп_филтер; ако није онемогућена, друга команда неће имати ефекта. Међутим, преостали интерфејси ће остати са омогућеним рп_филтер.

Да не бисмо у потпуности ограничили рад филтера, можемо користити имплементацију рп_филтер за нетфилтер. Користећи рпфилтер као иптаблес модул, можете конфигурисати прилично флексибилна правила, на пример:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

омогући рп_филтер на интерфејсу eth0.100 за све адресе осим 1.2.3.0/24.

Извор: ввв.хабр.цом