Rekursyvusis maršrutavimas: kai tunelis pagauna savo paties paketus

Tunelis pakyla, žurnale matomas baigtas rankos paspaudimas, o po sekundės ta pati sesija miršta ir vėl prisijungia ciklu. Šis modelis turi konkrečią priežastį: maršrutas iki serverio dabar rodo į tunelio vidų, todėl tunelį nešantys paketai siunčiami per tunelį. Autentifikacijoje niekas nepasikeitė, todėl pakartotinis prisijungimo duomenų įvedimas nieko nekeičia. Palyginkite išorinį kelią prieš maršruto pakeitimą ir po jo ir rekursija taps matoma.

Pirmiausia patikrinkite išorinį kelią

Žaidime du paketai, o ne vienas. Vidinis paketas priklauso programai ir turėtų būti užšifruotas, o išorinis paketas adresuotas serveriui ir turi jį pasiekti keliu, kuris nepriklauso nuo tunelio.

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

Paklauskite branduolio maršruto iki serverio adreso, kai tunelis jau pakilęs, ir dar kartą po to, kai pasikeitė numatytasis maršrutas. Kitas šuolis, kuris nusileidžia tunelio įrenginyje, yra pati rekursija, ir ji matoma be jokio paketų fiksavimo. Susiejimas su sąsaja, žymos ar tinklo vardų erdvė gali padaryti paprastą paiešką nepilną, todėl naudokite kontekstą, kurį naudoja pats klientas. Kai atsakymas atrodo teisingas, bet sesija vis dar sukasi ciklu, skaitykite maršrutizavimo politikos taisykles, o ne tik pagrindinę lentelę.

Kodėl sesija atsilaiko akimirką

Rankos paspaudimas baigiamas prieš įdiegiant naują maršrutą, todėl pirmos sekundės atrodo sveikos. Kai tik klientas prideda numatytąjį maršrutą, kitas išorinis paketas seka jį į sąsają, per kurią tas išorinis paketas turi keliauti. Serveris nieko nemato, klientas siunčia iš naujo, o bandymas arba baigiasi laiko limitu, arba užmuša sesiją ir pradeda iš naujo.

Ši tvarka paaiškina, kodėl tunelis gali veikti nešiojamajame kompiuteryje ir nepavykti maršrutizatoriuje, ir kodėl gedimas dažnai prasideda pradedant srautui, o ne jungiantis. Ji taip pat paaiškina ciklą: kiekvienas paleidimas iš naujo atkuria sesiją, kol maršrutas daro tai neįmanoma.

Išsiaiškinkite, kam priklauso pabaigos taško išimtis

Palaikomi klientai susitvarko savo išimtį: maršrutas į serverio mazgą per pradinį šliuzą arba žyma, kuri laiko išorinį lizdą už tunelio. Klausimas, ar kas nors kitas jo nepašalino ar nepakeitė.

Maršrutais grindžiamame IPsec patikrinkite politikos selektorius, kurie nusprendžia, kurie paketai patenka į tunelį, ir patvirtinkite, kad partnerio adresas iš jų pašalintas. WireGuard atveju sąsajos ugniasienės žyma ir jos politikos taisyklės laiko transporto paketus už tunelio, todėl rankiniu būdu pridėtas numatytasis maršrutas gali sugriauti tą tvarką. Antrasis VPN profilis arba valdymo scenarijus, perrašantis numatytąjį maršrutą, yra dažnas kaltininkas. Plačios apėjimo taisyklės, pridedamos po vieną, yra įprastas rezultatas, ir jos paverčia maršrutizavimo klaidą lentele, kurios niekas negali prižiūrėti.

Po tinklo pakeitimo patikrinkite dar kartą

Maršrutas į mazgą per Wi-Fi šliuzą yra teisingas tol, kol mašina persikelia į kitą tinklą. Tada tas pats simptomas grįžta visiškai nepakeitus konfigūracijos.

Užsirašykite pabaigos taško adresą, maršrutą prieš prisijungimą ir po jo bei sąsają, kurią naudojo kiekvienas. Šie trys faktai paprastai atskiria kliento klaidą nuo pakeitimo, ir jie išlieka po to, kai juos surinkęs žmogus išeina.

Prisijunkite iš naujo naujame tinkle ir pakartokite skaitymą. Jei išimties vėl trūksta, pataisa priklauso profiliui, kuris ją turi, o ne vienkartinei komandai, įvestai gedimo metu.