WireGuard: două jumătăți de rută contra 0.0.0.0/0 în wg-quick

Două prefixe /1 acoperă exact aceleași adrese IPv4 ca un singur /0, iar această egalitate este valabilă doar în interiorul listei de prefixe permise a peer-ului. Ea încetează să fie valabilă în momentul în care instrumentul de configurare decide cum să direcționeze, deoarece Linux wg-quick tratează un prefix implicit ca un caz special și nu ca aritmetică. Ramura specială instalează o tabelă dedicată, două reguli de politică, un marcaj de socket și setări pentru calea inversă pe care o pereche de jumătăți de rută nu le primește niciodată. Așa că, atunci când un proxy sau un browser încetează să funcționeze după editare, prefixele sunt partea cea mai puțin interesantă a schimbării.

Lista de prefixe nu este întreaga configurație

AllowedIPs face două lucruri simultan, iar doar unul dintre ele ține de acoperire. Pentru WireGuard însuși lista este rutare pe cheie criptografică: decide care destinații sunt criptate către un peer și ce adrese sursă poate folosi acel peer. Pentru wg-quick aceeași listă servește și ca specificație de rute, iar ruta pe care o produce depinde de ramura cu care lista se potrivește din întâmplare. Prin urmare, acoperirea identică la două forme diferite de listă nu spune nimic despre o stare identică a gazdei.

Configurația implicită vă ia această decizie din mâini, deoarece Table este implicit automat și instrumentul alege unde ajung rutele. Un alt manager de rețea, un înveliș de distribuție sau o valoare Table personalizată schimbă din nou rezultatul, motiv pentru care un sfat scris pentru o gazdă poate părea greșit pe următoarea.

Ce adaugă ramura implicită dincolo de o rută

O intrare /0 trimite wg-quick pe calea rutei implicite: o tabelă de rutare separată primește ruta implicită, o regulă de politică trimite acolo traficul nemarcat, o a doua regulă menține rutele mai specifice din tabela principală ca autoritare, iar interfața primește un marcaj de firewall pe propriul socket. Acel marcaj este gardianul buclei. Datagramele criptate care transportă traficul tunelului ies cu marcajul setat, astfel încât regula care direcționează tot restul în tunel să nu înghită pachetele de transport ale tunelului însuși.

În schimb, o pereche de intrări /1 urmează calea obișnuită. Două rute ajung în tabela configurată și niciun element al mașinăriei din jur nu apare, nu pentru că ar fi inutil, ci pentru că acea cale de cod nu a fost niciodată parcursă.

Unde diverg cele două aranjamente

Divergența apare mai întâi ca recursie. Cu jumătățile de rută în tabela principală, adresa de transport a peer-ului însuși cade în interiorul unui prefix de tunel, așa că pachetul care ar trebui să transporte tunelul corespunde unei rute care indică în interiorul tunelului. Ceva trebuie să îl excepteze: o rută de gazdă pentru punctul final curent, un marcaj aplicat manual sau o regulă specifică interfeței. O rută de gazdă funcționează până când se schimbă adresa punctului final, ceea ce se întâmplă cu puncte finale bazate pe DNS, clienți nomazi și configurații cu mai mulți peers.

În al doilea rând, tot ce raționează despre marcaje își schimbă comportamentul. Un proxy transparent care redirecționează conexiuni local creează socketuri noi ale căror marcaje și surse diferă de fluxul original al clientului, iar regulile de politică generate de ramura implicită făceau parte din ceea ce a separat acele fluxuri. Citirea conexiunii de ieșire a proxy-ului însuși este un alt exercițiu decât testarea dacă destinația originală este accesibilă.

Citiți regulile și marcajele înainte de editare

Capturați starea curentă cât timp tunelul este sănătos, apoi din nou după schimbare, și comparați cele două dump-uri în loc să raționați din fișierul de configurare. Includeți regulile de politică, fiecare tabelă, marcajul interfeței și punctele finale înregistrate.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Dacă prima linie a ieșirii a pierdut regula pentru traficul nemarcat și tabela dedicată este goală, ramura implicită nu rulează și nicio aritmetică de prefixe nu îi va restabili efectele. Un marcaj zero pe o interfață care înainte purta unul este același semnal, vizibil într-o singură valoare.

Exersați pierderea tunelului înainte de livrare

Dacă aranjamentul cu jumătăți de rută este alegerea deliberată, el trebuie să furnizeze explicit piesele lipsă: o cale a punctului final care supraviețuiește schimbărilor de adresă, comportamentul dorit când tunelul cade și tratamentul echivalent pentru IPv6. Scrieți-le ca cerințe în loc să le descoperiți în timpul unei întreruperi. Apoi exersați eșecul, pentru că un tunel complet care revine în tăcere la legătura fizică este mai rău decât unul care încetează să funcționeze.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

Căutarea rutei ar trebui să rezolve punctul final din interfața fizică fără a traversa tunelul, iar coborârea interfeței ar trebui să lase gazda în starea pe care designul a promis-o. Un proxy care funcționează după înlocuire dovedește că starea generată a gazdei a contat; nu dovedește că prevenirea buclelor și comportamentul în stare oprită au supraviețuit editării.