Rekurzivno usmjeravanje: kad tunel uhvati vlastite pakete

Tunel se podigne, zapisnik pokaže dovršeno rukovanje, a sekundu kasnije ista sesija umre i ponovno se spoji u petlji. Taj obrazac ima određen uzrok: ruta do poslužitelja 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. Usporedite vanjski put prije i poslije promjene rute i rekurzija postaje vidljiva.

Najprije provjerite vanjski put

U igri su dva paketa, a ne jedan. Unutarnji paket pripada aplikaciji i trebao bi biti šifriran, dok je vanjski paket adresiran na poslužitelj i mora do njega stići putem koji ne ovisi o tunelu.

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 jezgru za rutu do adrese poslužitelja nakon što je tunel podignut, i ponovno nakon što se promijenila zadana ruta. Sljedeći skok koji sleti na uređaj tunela jest rekurzija i vidljiv je bez ikakva hvatanja paketa. Vezivanje za sučelje, oznake ili mrežni prostor imena mogu učiniti običnu pretragu nepotpunom, zato rabite kontekst koji klijent sam rabi. Kada odgovor izgleda ispravno, ali sesija se i dalje vrti u petlji, pročitajte pravila politike usmjeravanja, a ne samo glavnu tablicu.

Zašto sesija preživi trenutak

Rukovanje se dovrš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 sučelje kroz koje taj vanjski paket mora proći. Poslužitelj ne vidi ništa, klijent ponovno š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 usmjerivaču, i zašto kvar često počinje s početkom prometa, 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 čiji je izuzetak za krajnju točku

Podržani klijenti sami urede svoj izuzetak: rutu do hosta poslužitelja kroz izvorni pristupnik ili oznaku koja drži vanjsku utičnicu izvan tunela. Pitanje je je li ga 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 sučelja 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 tablicu koju nitko ne može održavati.

Provjerite ponovno nakon promjene mreže

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

Zabilježite adresu krajnje točke, rutu prije i poslije povezivanja i sučelje koje je svaka rabila. Te tri činjenice obično razdvajaju grešku klijenta od pregaženja i ostaju i nakon osobe koja ih je prikupila.

Povežite se ponovno na novoj mreži i ponovite čitanje. Ako izuzetak opet nedostaje, popravak pripada profilu koji ga posjeduje, a ne jednokratnoj naredbi otipkanoj tijekom prekida.