Rekurzivno usmjeravanje: kada tunel uhvati vlastite pakete

Tunel se podigne, dnevnik pokaže završeno rukovanje, a sekund kasnije ista sesija umre i ponovo se poveže u petlji. Taj obrazac ima određen uzrok: ruta do servera sada pokazuje u tunel, pa se paketi koji nose tunel šalju kroz tunel. U autentifikaciji se ništa nije promijenilo, zato ponovni unos podataka za prijavu ništa ne mijenja. Uporedite vanjski put prije i poslije promjene rute i rekurzija postaje vidljiva.

Prvo provjerite vanjski put

U igri su dva paketa, a ne jedan. Unutrašnji paket pripada aplikaciji i treba biti šifriran, dok je vanjski paket adresiran na server i mora do njega stići putem koji ne zavisi 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

Pitajte jezgro za rutu do adrese servera nakon što je tunel podignut, i ponovo nakon što se promijenila zadana ruta. Sljedeći skok koji sleti na uređaj tunela jeste rekurzija i vidljiv je bez ikakvog hvatanja paketa. Vezivanje za interfejs, oznake ili mrežni prostor imena mogu učiniti običnu pretragu nepotpunom, zato koristite kontekst koji klijent sam koristi. Kada odgovor izgleda ispravno, ali sesija se i dalje vrti u petlji, pročitajte pravila politike usmjeravanja, a ne samo glavnu tabelu.

Zašto sesija preživi trenutak

Rukovanje se završi prije nego što se nova ruta instalira, pa prve sekunde izgledaju zdravo. Čim klijent doda zadanu rutu, sljedeći vanjski paket pođe za njom u interfejs kroz koji taj vanjski paket mora proći. Server ne vidi ništa, klijent ponovo šalje, a pokušaj ili istekne ili ubije sesiju i počne iznova.

Taj redoslijed objašnjava zašto tunel može raditi na prijenosniku, a pasti na ruteru, i zašto kvar često počinje s početkom saobraćaja, a ne u trenutku povezivanja. Objašnjava i petlju: svako ponovno pokretanje uspostavi sesiju prije nego što je ruta učini nemogućom.

Nađite vlasnika izuzetka za krajnju tačku

Podržani klijenti sami urede svoj izuzetak: rutu do hosta servera kroz izvorni pristupnik ili oznaku koja drži vanjsku utičnicu izvan tunela. Pitanje je da li ga je nešto drugo uklonilo ili pregazilo.

Za IPsec zasnovan na rutama pregledajte selektore politike koji odlučuju koji paketi ulaze u tunel i potvrdite da je adresa partnera iz njih isključena. Za WireGuard oznaka zaštitnog zida interfejsa i njegova pravila politike drže transportne pakete izvan tunela, pa ručno dodana zadana ruta može pokvariti taj raspored. Drugi VPN profil ili administrativna skripta koja prepisuje zadanu rutu čest je krivac. Široka pravila zaobilaženja dodana jedno po jedno uobičajen su rezultat i ona pretvaraju grešku u usmjeravanju u tabelu koju niko ne može održavati.

Provjerite ponovo nakon promjene mreže

Ruta do hosta kroz Wi-Fi pristupnik ispravna je dok se mašina ne preseli na drugu mrežu. Isti simptom se tada vraća bez ikakve promjene konfiguracije.

Zabilježite adresu krajnje tačke, rutu prije i poslije povezivanja i interfejs koji je svaka koristila. Te tri činjenice obično razdvajaju grešku klijenta od pregaženja i ostaju i nakon osobe koja ih je prikupila.

Povežite se ponovo na novoj mreži i ponovite čitanje. Ako izuzetak opet nedostaje, popravka pripada profilu koji ga posjeduje, a ne jednokratnoj komandi otkucanoj tokom prekida.