Rekurzivno usmerjanje: ko tunel ujame lastne pakete

Tunel se dvigne, dnevnik pokaže dokončano rokovanje, in sekundo pozneje ista seja umre ter se znova poveže v zanki. Ta vzorec ima določen vzrok: pot do strežnika zdaj kaže v notranjost tunela, zato se paketi, ki nosijo tunel, pošiljajo skozi tunel. Pri preverjanju pristnosti se ni nič spremenilo, zato ponoven vnos poverilnic nič ne spremeni. Primerjajte zunanjo pot pred spremembo poti in po njej in rekurzija postane vidna.

Najprej preverite zunanjo pot

V igri sta dva paketa, ne eden. Notranji paket pripada aplikaciji in bi moral biti šifriran, medtem ko je zunanji paket naslovljen na strežnik in mora do njega priti po poti, ki ni odvisna 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 dvigu tunela vprašajte jedro za pot do naslova strežnika in znova po spremembi privzete poti. Naslednji skok, ki pristane na napravi tunela, je prav rekurzija in vidna je brez kakršnega koli zajemanja paketov. Vezava na vmesnik, oznake ali omrežni imenski prostor lahko naredijo običajno iskanje nepopolno, zato uporabite kontekst, ki ga uporablja sam odjemalec. Ko je odgovor videti pravilen, seja pa se še vedno vrti v zanki, berite pravila usmerjevalne politike in ne le glavne tabele.

Zakaj seja preživi trenutek

Rokovanje se zaključi, preden se namesti nova pot, zato so prve sekunde videti zdrave. Takoj ko odjemalec doda privzeto pot, ji naslednji zunanji paket sledi v vmesnik, skozi katerega mora ta paket potovati. Strežnik ne vidi ničesar, odjemalec znova pošlje, poskus pa bodisi poteče bodisi ubije sejo in začne znova.

Ta vrstni red pojasnjuje, zakaj lahko tunel deluje na prenosniku in odpove na usmerjevalniku, in zakaj se napaka pogosto začne ob začetku prometa in ne ob povezavi. Pojasnjuje tudi zanko: vsak ponovni zagon vzpostavi sejo, preden pot to naredi nemogoče.

Ugotovite, čigava je izjema za končno točko

Podprti odjemalci si svojo izjemo uredijo sami: pot do gostitelja strežnika skozi prvotni prehod ali oznako, ki drži zunanjo vtičnico zunaj tunela. Vprašanje je, ali jo je kaj drugega odstranilo ali povozilo.

Pri IPsec, ki temelji na poteh, preglejte selektorje politike, ki odločajo, kateri paketi vstopijo v tunel, in potrdite, da je naslov partnerja iz njih izključen. Pri WireGuardu oznaka požarnega zidu vmesnika in njegova pravila politike držijo transportne pakete zunaj tunela, zato lahko ročno dodana privzeta pot pokvari to ureditev. Drugi profil VPN ali upravljalna skripta, ki prepisuje privzeto pot, je pogost krivec. Široka pravila zaobidenja, dodana eno za drugim, so običajen rezultat in napako usmerjanja spremenijo v tabelo, ki je nihče ne more vzdrževati.

Po spremembi omrežja preverite znova

Pot do gostitelja skozi prehod Wi-Fi je pravilna, dokler se stroj ne preseli v drugo omrežje. Takrat se ista težava vrne brez kakršne koli spremembe konfiguracije.

Zapišite naslov končne točke, pot pred povezavo in po njej ter vmesnik, ki ga je uporabil vsak od njiju. Ta tri dejstva običajno ločijo napako odjemalca od povoza in preživijo osebo, ki jih je zbrala.

Znova se povežite v novem omrežju in branje ponovite. Če izjema spet manjka, popravek spada v profil, ki jo ima, in ne v enkratni ukaz, vtipkan med izpadom.