Rutare recursivă: când tunelul își prinde propriile pachete

Tunelul se ridică, jurnalul arată o strângere de mână finalizată, iar o secundă mai târziu aceeași sesiune moare și se reconectează în buclă. Acest tipar are o cauză precisă: ruta către server indică acum în interiorul tunelului, așa că pachetele care transportă tunelul sunt trimise prin tunel. Nimic nu s-a schimbat la autentificare, de aceea reintroducerea datelor de acces nu schimbă nimic. Comparați calea exterioară înainte și după schimbarea rutei și recursia devine vizibilă.

Verificați mai întâi calea exterioară

Sunt două pachete în joc, nu unul. Pachetul interior aparține aplicației și ar trebui să fie criptat, în timp ce pachetul exterior este adresat serverului și trebuie să ajungă la el pe o cale care nu depinde de tunel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Întrebați nucleul despre ruta către adresa serverului după ce tunelul este activ, și din nou după ce ruta implicită s-a schimbat. Un salt următor care aterizează pe dispozitivul tunelului este recursia, și se vede fără nicio captură de pachete. Legarea de o interfață, marcajele sau un spațiu de nume de rețea pot face o căutare simplă incompletă, așa că folosiți contextul pe care îl folosește clientul însuși. Când răspunsul pare corect dar sesiunea continuă în buclă, citiți regulile politicii de rutare și nu doar tabelul principal.

De ce sesiunea supraviețuiește o clipă

Strângerea de mână se finalizează înainte de instalarea noii rute, așa că primele secunde par sănătoase. Imediat ce clientul adaugă ruta implicită, următorul pachet exterior o urmează în interfața prin care acel pachet trebuie să călătorească. Serverul nu vede nimic, clientul retransmite, iar încercarea fie expiră, fie ucide sesiunea și o ia de la capăt.

Această ordine explică de ce un tunel poate funcționa pe un laptop și poate eșua pe un router, și de ce defecțiunea începe adesea când pornește traficul și nu la conectare. Explică și bucla: fiecare repornire restabilește sesiunea înainte ca ruta să facă acest lucru imposibil.

Aflați cine deține excepția punctului final

Clienții acceptați își pregătesc propria excepție: o rută de gazdă către server prin gateway-ul original, sau un marcaj care ține soclul exterior în afara tunelului. Întrebarea este dacă altceva a eliminat-o sau a suprascris-o.

La IPsec bazat pe rute, examinați selectorii de politică ce decid ce pachete intră în tunel și confirmați că adresa perechii este exclusă din ei. La WireGuard, marcajul de firewall al interfeței și regulile sale de politică țin pachetele de transport în afara tunelului, așa că o rută implicită adăugată manual poate strica acea rânduială. Un al doilea profil VPN sau un script de administrare care rescrie ruta implicită este un vinovat frecvent. Regulile largi de ocolire adăugate una câte una sunt rezultatul obișnuit, și transformă un defect de rutare într-un tabel pe care nimeni nu îl poate întreține.

Verificați din nou după o schimbare de rețea

O rută de gazdă printr-un gateway Wi-Fi este corectă până când mașina se mută în altă rețea. Atunci același simptom revine fără nicio modificare de configurație.

Notați adresa punctului final, ruta înainte și după conectare și interfața folosită de fiecare. Aceste trei fapte despart de obicei o eroare a clientului de o suprascriere, și supraviețuiesc persoanei care le-a adunat.

Reconectați-vă în noua rețea și repetați citirea. Dacă excepția lipsește din nou, corectarea aparține profilului care o deține, nu unei comenzi unice tastate în timpul unei întreruperi.