Demek berê ez bi karekî pir neasayî re rûbirû bûm ji bo sazkirina rêgezê ji bo MetalLB. Her tişt dê baş be, ji ber ku ... Bi gelemperî MetalLB ne hewceyî çalakiyên zêde ye, lê di rewşa me de me komek pir mezin bi veavakirina torê ya pir hêsan heye.

Di vê gotarê de ez ê ji we re vebêjim ka meriv çawa ji bo tora derveyî ya koma xwe rêça çavkaniya çavkaniyê û polîtîk-based mîheng dike.

Ez ê di derbarê sazkirin û mîhengkirina MetalLB de hûrgulî nekim, ji ber ku ez texmîn dikim ku we berê hin ezmûnek heye. Ez pêşniyar dikim ku rasterast biçin ser xalê, ango sazkirina rêwiyan. Ji ber vê yekê çar rewşên me hene:

Doza 1: Dema ku veavakirin ne hewce ye

Ka em li dozek hêsan binêrin.

Dema ku navnîşanên ku ji hêla MetalLB ve têne derxistin, wekî navnîşanên girêkên we di heman subnetê de ne pêdivî ye ku veavakirina rêvekirinê ya zêde hewce bike.

Mînakî, te subnetek heye 192.168.1.0/24, ruterek wê heye 192.168.1.1, û girêkên we navnîşanan distînin: 192.168.1.10-30, wê hingê ji bo MetalLB hûn dikarin rêzê rast bikin 192.168.1.100-120 û pê ewle bin ku ew ê bêyî veavakirina zêde bixebitin.

Çima wisa ye? Ji ber ku girêkên we berê xwedan rêgezên mîhengkirî ne:

# 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

Û navnîşanên ji heman rêzê dê wan bêyî kiryarên zêde ji nû ve bikar bînin.

Rewş 2: Dema ku xwerûkirina zêde hewce dike

Gava ku girêkên we navnîşek IP-ya mîhengkirî an rêyek berbi subneta ku MetalLB ji bo wan navnîşanan dike, nebe, divê hûn rêyên din mîheng bikin.

Ez ê hinekî berfirehtir vebêjim. Gava ku MetalLB navnîşek derdixe, ew dikare bi peywirek hêsan re were berhev kirin:

ip addr add 10.9.8.7/32 dev lo

Bala xwe bide:

• a) Navnîşan bi pêşgirek tê destnîşankirin /32 ango, rêyek ji bo wê bixweber li jêrtorê nayê zêdekirin (ew tenê navnîşek e)
• b) Navnîşan bi her navbeynkariya nodê ve girêdayî ye (mînakî loopback). Hêjayî gotinê ye ku li vir taybetmendiyên stûna tora Linux-ê were gotin. Ne girîng e ku hûn navnîşan li kîjan navbeynê lê zêde bikin, kernel dê her gav daxwazên arp pêvajoyê bike û bersivên arp ji yek ji wan re bişîne, ev tevger rast tê hesibandin û, ji bilî vê, di hawîrdorek wusa dînamîkî de wekî Kubernetes bi gelemperî tê bikar anîn.

Ev tevger dikare were xweş kirin, mînakî bi çalakkirina arp hişk:

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

Di vê rewşê de, bersivên arp tenê dê bêne şandin heke navber bi eşkere navnîşek IP-ya taybetî heye. Heke hûn plan dikin ku MetalLB bikar bînin û kube-proxy-ya we di moda IPVS de dixebite ev mîheng hewce ye.

Lêbelê, MetalLB kernelê bikar nayîne da ku daxwazên arp pêvajoyê bike, lê ew bi xwe di cîhê bikarhêner de dike, ji ber vê yekê ev vebijark dê bandorê li xebata MetalLB neke.

Em vegerin ser karê xwe. Ger rêça navnîşanên hatine weşandin li ser girêkên we tune be, wê berê li hemî girêkan zêde bikin:

ip route add 10.9.8.0/24 dev eth1

Doza 3: Dema ku hûn hewceyê rêvekirina-based çavkaniyê bin

Dema ku hûn pakêtan di nav dergehek veqetandî de werdigirin, ne ya ku ji hêla xwerû ve hatî mîheng kirin, pêdivî ye ku hûn rêça-based çavkaniyê mîheng bikin, ji ber vê yekê divê pakêtên bersivdanê jî di heman derî re derbas bibin.

Mînakî, we heman subnet heye 192.168.1.0/24 ji nokên xwe re veqetandî, lê hûn dixwazin navnîşanên derveyî bi karanîna MetalLB derxînin. Werin em bihesibînin ku we gelek navnîşanên ji jêrtorê hene 1.2.3.0/24 di VLAN 100 de cih digirin û hûn dixwazin wan bikar bînin da ku bigihîjin karûbarên Kubernetes li derve.

Dema ku têkilî 1.2.3.4 hûn ê daxwazan ji subnetek cûda bikin 1.2.3.0/24 û li benda bersivê bin. Nodeya ku niha ji bo navnîşana ku ji MetalLB hatî derxistin master e 1.2.3.4, dê pakêtê ji routerê bistîne 1.2.3.1, lê bersiv ji bo wî divê bi hewceyî heman rêyê, bi rê ve biçe 1.2.3.1.

Ji ber ku girêka me berê xwedan dergehek xwerû ya mîhengkirî ye 192.168.1.1, wê hingê ji hêla xwerû ve bersiv dê ji wî re biçe, û ne 1.2.3.1, bi rêya ku me pakêt wergirt.

Meriv çawa bi vê rewşê re mijûl dibe?

Di vê rewşê de, hûn hewce ne ku hemî girêkên xwe bi vî rengî amade bikin ku ew amade ne ku navnîşên derveyî bêyî veavakirina zêde xizmetê bikin. Ango, ji bo mînaka jorîn, hûn hewce ne ku di pêş de navgînek VLAN-ê li ser nodê biafirînin:

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

Û dûv re rêgezan lê zêde bikin:

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

Ji kerema xwe not bikin ku em rêçikan li tabloyek rêvekirinê ya cihêreng zêde dikin 100 ew ê tenê du rêyên ku hewce ne ji bo şandina pakêtek bersivê di nav dergehê de hebe 1.2.3.1, li pişt navberê ye eth0.100.

Naha divê em qaîdeyek hêsan lê zêde bikin:

ip rule add from 1.2.3.0/24 lookup 100

ku bi eşkere dibêje: heke navnîşana çavkaniya pakêtê tê de be 1.2.3.0/24, hingê hûn hewce ne ku tabloya rêwîtiyê bikar bînin 100. Di wê de me berê riya ku dê wî bişîne diyar kir 1.2.3.1

Meseleya 4: Dema ku hûn hewceyê rêgez-based polîtîkayê bibin

Topolojiya torê wekî mînaka berê ye, lê em bibêjin hûn jî dixwazin ku hûn bigihîjin navnîşanên hewza derveyî 1.2.3.0/24 ji pêlên te:

Taybetmendî ev e ku dema ku meriv xwe bigihîne her navnîşanê 1.2.3.0/24, pakêta bersivê li girêkê dixe û di nav rêzê de navnîşanek çavkaniyek heye 1.2.3.0/24 dê bi îtaet were şandin eth0.100, lê em dixwazin Kubernetes wê beralî bike pod meya yekem, ya ku daxwaza orîjînal çêkir.

Çareserkirina vê pirsgirêkê dijwar bû, lê ew bi saya rêgez-based polîtîkayê gengaz bû:

Ji bo têgihiştinek çêtir a pêvajoyê, li vir diyagramek bloka netfilterê heye:

Pêşîn, wekî di mînaka berê de, bila em tabloyek rêvekirinê ya zêde biafirînin:

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

Naha em çend rêzikan li iptables zêde bikin:

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

Van qaîdeyan dê girêdanên hatina navberê nîşan bikin eth0.100, hemû pakêtan bi tagê nîşankirin 0x100, bersivên di nav heman girêdanê de jî dê bi heman etîketê bêne nîşankirin.

Naha em dikarin qaîdeyek rêwîtiyê lê zêde bikin:

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

Ew e, hemî pakêtên bi navnîşana çavkaniyê 1.2.3.0/24 û tag 0x100 divê bi karanîna tabloyek were rêve kirin 100.

Bi vî rengî, pakêtên din ên ku li ser navgînek din hatine wergirtin ne di bin vê qaîdeyê de ne, ku dê bihêle ku ew bi karanîna amûrên standard Kubernetes werin rêve kirin.

Tiştek din jî heye, di Linux-ê de fîlterek riya berevajî heye, ku hemî tiştan xirab dike; ew kontrolek hêsan dike: ji bo hemî pakêtên ku têne, ew navnîşana çavkaniyê ya pakêtê bi navnîşana şanderê diguhezîne û kontrol dike ka gelo pakêt dikare bi heman navbeynkariya ku li ser hatî wergirtin derkeve, heke na, ew ê wê fîlter bike.

Pirsgirêk ev e ku di doza me de ew ê rast nexebite, lê em dikarin wê neçalak bikin:

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

Ji kerema xwe not bikin ku fermana yekem tevgera gerdûnî ya rp_filter kontrol dike; heke ew neçalak nebe, fermana duyemîn dê bandorek nebe. Lêbelê, navberên mayî dê bi rp_filter çalak bimînin.

Ji bo ku xebata parzûnê bi tevahî sînordar neke, em dikarin ji bo netfilter pêkanîna rp_filter bikar bînin. Bi karanîna rpfilter wekî modulek iptables, hûn dikarin qaîdeyên pir maqûl mîheng bikin, mînakî:

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

rp_filter li ser navberê çalak bike eth0.100 ji bo hemî navnîşan ji bilî 1.2.3.0/24.

Source: www.habr.com