Rekurzívne smerovanie: keď tunel zachytí vlastné pakety

Tunel sa zdvihne, záznam ukáže dokončené podanie rúk a o sekundu neskôr tá istá relácia zomrie a znova sa pripojí v slučke. Tento vzor má konkrétnu príčinu: trasa k serveru teraz ukazuje dovnútra tunela, takže pakety, ktoré tunel nesú, sa posielajú cez tunel. V overovaní sa nič nezmenilo, preto opätovné zadanie prihlasovacích údajov nič nerieši. Porovnajte vonkajšiu cestu pred zmenou trasy a po nej a rekurzia sa stane viditeľnou.

Najprv skontrolujte vonkajšiu cestu

V hre sú dva pakety, nie jeden. Vnútorný paket patrí aplikácii a mal by byť šifrovaný, kým vonkajší paket je adresovaný serveru a musí sa k nemu dostať cestou, ktorá nezávisí od tunela.

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

Po zdvihnutí tunela sa opýtajte jadra na trasu k adrese servera a znova po zmene predvolenej trasy. Ďalší skok, ktorý skončí na zariadení tunela, je práve rekurzia a vidno ju bez akéhokoľvek zachytávania paketov. Väzba na rozhranie, značky alebo sieťový menný priestor môžu bežné hľadanie zneprehľadniť, preto použite kontext, ktorý používa samotný klient. Keď odpoveď vyzerá správne, ale relácia stále cykluje, čítajte pravidlá smerovacej politiky, nielen hlavnú tabuľku.

Prečo relácia chvíľu prežije

Podanie rúk sa dokončí skôr, než sa nainštaluje nová trasa, takže prvé sekundy vyzerajú zdravo. Hneď ako klient pridá predvolenú trasu, nasledujúci vonkajší paket ju nasleduje do rozhrania, cez ktoré tento paket musí prejsť. Server nič nevidí, klient znova odosiela a pokus buď vyprší, alebo reláciu zabije a začne odznova.

Toto poradie vysvetľuje, prečo tunel môže fungovať na notebooku a zlyhať na routeri a prečo porucha často začína pri štarte prevádzky, a nie pri pripojení. Vysvetľuje aj slučku: každý reštart obnoví reláciu skôr, než ju trasa urobí nemožnou.

Zistite, komu patrí výnimka pre koncový bod

Podporovaní klienti si svoju výnimku zariaďujú sami: trasu k hostiteľovi servera cez pôvodnú bránu alebo značku, ktorá drží vonkajší socket mimo tunela. Otázkou je, či ju neodstránilo alebo neprepísalo niečo iné.

Pri IPsec založenom na trasách preskúmajte selektory politiky, ktoré rozhodujú, ktoré pakety vstúpia do tunela, a potvrďte, že adresa partnera je z nich vylúčená. Pri WireGuard držia značka firewallu rozhrania a jeho pravidlá politiky transportné pakety mimo tunela, takže ručne pridaná predvolená trasa môže toto usporiadanie pokaziť. Druhý profil VPN alebo správcovský skript, ktorý prepisuje predvolenú trasu, býva častým vinníkom. Široké pravidlá obchádzania pridávané jedno po druhom sú obvyklým výsledkom a menia chybu smerovania na tabuľku, ktorú nikto nedokáže udržiavať.

Po zmene siete skontrolujte znova

Trasa k hostiteľovi cez Wi-Fi bránu je správna, kým sa stroj nepresunie do inej siete. Potom sa ten istý príznak vráti bez akejkoľvek zmeny konfigurácie.

Zapíšte adresu koncového bodu, trasu pred pripojením a po ňom a rozhranie, ktoré použil každý z nich. Tieto tri skutočnosti zvyčajne oddelia chybu klienta od prepísania a prežijú aj toho, kto ich zozbieral.

Pripojte sa znova v novej sieti a čítanie zopakujte. Ak výnimka opäť chýba, oprava patrí profilu, ktorý ju vlastní, nie jednorazovému príkazu napísanému počas výpadku.