Pocu pocu fà aghju avutu affruntatu un compitu assai inusual di stabilisce u routing per MetalLB. Tuttu saria bè, perchè... Di solitu MetalLB ùn hà micca bisognu d'azzioni supplementari, ma in u nostru casu avemu un cluster abbastanza grande cù una cunfigurazione di rete assai simplice.

In questu articulu vi diceraghju cumu cunfigurà u routing basatu in fonti è pulitiche per a reta esterna di u vostru cluster.

Ùn entreraghju micca in dettagliu nantu à a stallazione è a cunfigurazione di MetalLB, postu chì suppone chì avete digià una certa sperienza. Suggeriu d'andà direttamente à u puntu, vale à dì stabilisce u routing. Allora avemu quattru casi:

Casu 1: Quandu ùn hè micca necessariu cunfigurazione

Fighjemu un casu simplice.

A cunfigurazione di routing supplementu ùn hè micca necessariu quandu l'indirizzi emessi da MetalLB sò in a stessa subnet cum'è l'indirizzi di i vostri nodi.

Per esempiu, avete una subnet 192.168.1.0/24, hà un router 192.168.1.1, è i vostri nodi ricevenu indirizzi: 192.168.1.10-30, allura per MetalLB pudete aghjustà a gamma 192.168.1.100-120 è assicuratevi chì anu da travaglià senza cunfigurazione supplementu.

Perchè hè questu? Perchè i vostri nodi anu digià rotte cunfigurate:

# 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

È l'indirizzi da a listessa gamma li riutilizaranu senza alcuna azzione supplementaria.

Casu 2: Quandu persunalizazione supplementu hè necessariu

Duvete cunfigurà rotte supplementari ogni volta chì i vostri nodi ùn anu micca un indirizzu IP cunfiguratu o una strada à a subnet per quale MetalLB emette indirizzi.

Vi spiegheraghju in un pocu più di dettu. Ogni volta chì MetalLB produce un indirizzu, pò esse paragunatu à una assignazione simplice cum'è:

ip addr add 10.9.8.7/32 dev lo

Attenti à:

• a) L'indirizzu hè attribuitu cù un prefissu /32 vale à dì, una strada ùn serà micca aghjunta automaticamente à a subnet per questu (hè solu un indirizzu)
• b) L'indirizzu hè attaccatu à qualsiasi interfaccia di node (per esempiu loopback). Vale a pena menzionate quì e caratteristiche di a pila di rete Linux. Ùn importa micca l'interfaccia chì aghjunghje l'indirizzu, u kernel sempre processerà e dumande arp è mandà risposte arp à qualsiasi di elli, stu cumpurtamentu hè cunsideratu currettu è, in più, hè abbastanza largamente utilizatu in un ambiente cusì dinamicu cum'è Kubernetes.

Stu cumpurtamentu pò esse persunalizatu, per esempiu, attivendu l'arp strettu:

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

In questu casu, i risposti arp seranu mandati solu se l'interfaccia cuntene esplicitamente un indirizzu IP specificu. Questa paràmetra hè necessaria se pensa à aduprà MetalLB è u vostru kube-proxy hè in esecuzione in modu IPVS.

Tuttavia, MetalLB ùn aduprate micca u kernel per processà e dumande arp, ma si face in u spaziu di l'utilizatori, cusì sta opzione ùn affetterà micca l'operazione di MetalLB.

Riturnemu à u nostru compitu. Se a strada per l'indirizzi emessi ùn esiste micca in i vostri nodi, aghjunghje in anticipu à tutti i nodi:

ip route add 10.9.8.0/24 dev eth1

Casu 3: Quandu avete bisognu di routing basatu in fonte

Averete bisognu di cunfigurà u routing basatu in fonte quandu ricevete pacchetti per una porta separata, micca quella cunfigurata per difettu, per quessa, i pacchetti di risposta duveranu ancu passà per a stessa porta.

Per esempiu, avete a stessa subnet 192.168.1.0/24 dedicatu à i vostri nodi, ma vulete emette indirizzi esterni cù MetalLB. Assumimu chì avete parechje indirizzi da una subnet 1.2.3.0/24 situatu in VLAN 100 è vulete usà per accede à i servizii Kubernetes esternamente.

Quandu cuntattate 1.2.3.4 sarete dumande da una subnet differente da 1.2.3.0/24 è aspetta una risposta. U node chì hè attualmente u maestru per l'indirizzu emessu da MetalLB 1.2.3.4, riceverà u pacchettu da u router 1.2.3.1, ma a risposta per ellu deve necessariamente andà in a stessa strada, attraversu 1.2.3.1.

Siccomu u nostru node hà digià un gateway predeterminatu cunfiguratu 192.168.1.1, allura per difettu a risposta andarà à ellu, è micca à 1.2.3.1, attraversu quale avemu ricevutu u pacchettu.

Cumu affruntà sta situazione?

In questu casu, avete bisognu di preparà tutti i vostri nodi in modu chì sò pronti à serve l'indirizzi esterni senza cunfigurazione supplementu. Questu hè, per l'esempiu di sopra, avete bisognu di creà una interfaccia VLAN in u node in anticipu:

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

E poi aghjunghje rotte:

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

Per piacè nutate chì aghjustemu rotte à una tabella di routing separata 100 cuntene solu duie rotte necessarie per mandà un pacchettu di risposta attraversu u gateway 1.2.3.1, situatu daretu à l 'interfaccia eth0.100.

Avà avemu bisognu di aghjunghje una regula simplice:

ip rule add from 1.2.3.0/24 lookup 100

chì dice esplicitamente: se l'indirizzu fonte di u pacchettu hè in 1.2.3.0/24, allora avete bisognu di utilizà a tabella di routing 100. In questu avemu digià descrittu a strada chì u mandarà attraversu 1.2.3.1

Casu 4: Quandu avete bisognu di routing basatu in pulitica

A topulugia di a rete hè a stessa cum'è in l'esempiu precedente, ma dicemu chì vulete ancu accede à l'indirizzi di piscina esterna. 1.2.3.0/24 da i vostri baccelli:

A peculiarità hè chì quandu accede à qualsiasi indirizzu in 1.2.3.0/24, u pacchettu di risposta chjappà u node è hà un indirizzu fonte in u range 1.2.3.0/24 sarà ubbidiente mandatu à eth0.100, ma vulemu chì Kubernetes u redirezzione à u nostru primu pod, chì hà generatu a dumanda originale.

Risolvi stu prublema hè statu difficiule, ma hè diventatu pussibule grazia à u routing basatu in pulitica:

Per una megliu comprensione di u prucessu, quì hè un diagramma di bloccu di netfilter:

Prima, cum'è in l'esempiu precedente, creemu una tabella di routing supplementu:

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

Avà aghjunghje uni pochi di regule à iptables:

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

Queste regule marcaranu e cunnessione entranti à l'interfaccia eth0.100, marcatu tutti i pacchetti cù l'etichetta 0x100, i risposti in a listessa cunnessione seranu ancu marcati cù a listessa tag.

Avà pudemu aghjunghje una regula di routing:

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

Questu hè, tutti i pacchetti cù un indirizzu fonte 1.2.3.0/24 è tag 0x100 deve esse guidatu cù una tavola 100.

Cusì, altri pacchetti ricevuti nantu à una altra interfaccia ùn sò micca sottumessi à sta regula, chì li permetterà di esse instradati cù l'arnesi standard di Kubernetes.

Ci hè una cosa più, in Linux ci hè un filtru chjamatu per via inversa, chì sguassate tuttu; esegue un cuntrollu simplice: per tutti i pacchetti in entrata, cambia l'indirizzu fonte di u pacchettu cù l'indirizzu di u mittente è verifica se u pacchettu pò lascià attraversu a stessa interfaccia nantu à quale hè statu ricevutu, se no, u filtrerà.

U prublema hè chì in u nostru casu ùn funziona micca bè, ma pudemu disattivà:

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

Per piacè nutate chì u primu cumandamentu cuntrolla u cumpurtamentu glubale di rp_filter; se ùn hè micca disattivatu, u sicondu cumanda ùn hà micca effettu. Tuttavia, l'interfacce restante resteranu cù rp_filter attivatu.

Per ùn limità cumplettamente l'operazione di u filtru, pudemu usà l'implementazione rp_filter per netfilter. Utilizendu rpfilter cum'è un modulu iptables, pudete cunfigurà regule abbastanza flessibili, per esempiu:

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

attivà rp_filter nantu à l'interfaccia eth0.100 per tutti l'indirizzi eccettu 1.2.3.0/24.

Source: www.habr.com