Rekursiivne marsruutimine: kui tunnel püüab kinni oma enda paketid

Tunnel tõuseb, logi näitab lõpetatud kätlust ja sekund hiljem sureb sama seanss ning taasühendub silmusena. Sellel mustril on konkreetne põhjus: marsruut serverini osutab nüüd tunneli sisse, seega saadetakse tunneli kandvad paketid läbi tunneli. Autentimises ei ole midagi muutunud, mistõttu volituste uuesti sisestamine ei muuda midagi. Võrrelge välimist teed enne ja pärast marsruudimuudatust ning rekursioon muutub nähtavaks.

Kontrollige esmalt välimist teed

Mängus on kaks paketti, mitte üks. Sisemine pakett kuulub rakendusele ja peaks olema krüpteeritud, samas kui välimine pakett on adresseeritud serverile ja peab jõudma sinna teed pidi, mis ei sõltu tunnelist.

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

Küsige tuumalt marsruuti serveri aadressini pärast tunneli tõusmist ja uuesti pärast seda, kui vaikimisi marsruut on muutunud. Järgmine hüpe, mis maandub tunnelseadmele, ongi rekursioon ja see on nähtav ilma igasuguse paketipüügita. Liidesega sidumine, märgised või võrgu nimeruum võivad muuta tavalise otsingu puudulikuks, seega kasutage konteksti, mida klient ise kasutab. Kui vastus tundub õige, aga seanss käib endiselt silmusena, lugege marsruutimispoliitika reegleid, mitte ainult põhitabelit.

Miks seanss hetkeks püsib

Kätlus lõpeb enne, kui uus marsruut paigaldatakse, seega näivad esimesed sekundid terved. Niipea kui klient lisab vaikimisi marsruudi, järgneb järgmine välimine pakett sellele liidesesse, mille kaudu see välimine pakett peab liikuma. Server ei näe midagi, klient saadab uuesti ja katse kas aegub või tapab seansi ning alustab otsast peale.

See järjekord selgitab, miks tunnel võib sülearvutis töötada ja ruuteris ebaõnnestuda, ning miks tõrge algab sageli liikluse alguses, mitte ühendamise hetkel. See selgitab ka silmust: iga taaskäivitus taastab seansi enne, kui marsruut teeb selle võimatuks.

Leidke, kellele kuulub lõpp-punkti erand

Toetatud kliendid korraldavad ise oma erandi: host-marsruut serverini algse lüüsi kaudu või märgis, mis hoiab välimise pistiku tunnelist väljas. Küsimus on, kas midagi muud selle eemaldas või asendas.

Marsruudipõhise IPsec-i puhul uurige poliitika valijaid, mis otsustavad, millised paketid tunnelisse lähevad, ja kinnitage, et partneri aadress on neist välja jäetud. WireGuardis hoiavad liidese tulemüürimärgis ja selle poliitikareeglid transpordipaketid väljaspool tunnelit, seega käsitsi lisatud vaikimisi marsruut võib selle korralduse rikkuda. Teine VPN-profiil või haldusskript, mis vaikimisi marsruudi ümber kirjutab, on sagedane süüdlane. Ükshaaval lisatud laiad möödaviigureeglid on tavaline tulemus ja need muudavad marsruutimisvea tabeliks, mida keegi ei suuda hallata.

Kontrollige uuesti pärast võrguvahetust

Host-marsruut Wi-Fi lüüsi kaudu on õige seni, kuni masin liigub teise võrku. Siis naaseb sama sümptom ilma igasuguse konfiguratsioonimuudatuseta.

Kirjutage üles lõpp-punkti aadress, marsruut enne ja pärast ühendamist ning liides, mida kumbki kasutas. Need kolm fakti eraldavad tavaliselt kliendi vea asendamisest ja need jäävad püsima ka pärast nende kogujat.

Ühenduge uues võrgus uuesti ja korrake lugemist. Kui erand on jälle puudu, kuulub parandus profiilile, mis seda omab, mitte ühekordsele käsule, mis katkestuse ajal sisestati.