Rrugëtim rekursiv: kur tuneli kap paketat e veta

Tuneli ngrihet, regjistri tregon një shtrëngim duarsh të përfunduar dhe një sekondë më vonë i njëjti sesion vdes dhe rilidhet në një lak. Ky model ka një shkak të caktuar: rruga drejt serverit tani tregon brenda tunelit, prandaj paketat që mbajnë tunelin dërgohen përmes tunelit. Asgjë nuk ka ndryshuar në vërtetim, prandaj rihyrja e kredencialeve nuk ndryshon asgjë. Krahasoni rrugën e jashtme para dhe pas ndryshimit të rrugës dhe rekursioni bëhet i dukshëm.

Fillimisht kontrolloni rrugën e jashtme

Në lojë janë dy paketa, jo një. Paketa e brendshme i përket aplikacionit dhe duhet të jetë e kriptuar, ndërsa paketa e jashtme adresohet drejt serverit dhe duhet ta arrijë në një rrugë që nuk varet nga tuneli.

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

Pyesni kernelin për rrugën drejt adresës së serverit pasi tuneli është ngritur, dhe përsëri pasi rruga parazgjedhëse ka ndryshuar. Hapi tjetër që zbret mbi pajisjen e tunelit është vetë rekursioni, dhe shihet pa asnjë kapje paketash. Lidhja me ndërfaqen, shenjat ose një hapësirë emrash rrjeti mund ta bëjnë një kërkim të thjeshtë të papërfunduar, prandaj përdorni kontekstin që përdor vetë klienti. Kur përgjigja duket e saktë por sesioni vazhdon në lak, lexoni rregullat e politikës së rrugëtimit dhe jo vetëm tabelën kryesore.

Pse sesioni mbijeton një çast

Shtrëngimi i duarve përfundon përpara se të instalohet rruga e re, prandaj sekondat e para duken të shëndetshme. Sapo klienti shton rrugën parazgjedhëse, paketa tjetër e jashtme e ndjek atë në ndërfaqen nëpër të cilën duhet të kalojë ajo paketë. Serveri nuk sheh asgjë, klienti ritransmeton dhe përpjekja ose skadon ose vret sesionin dhe fillon nga e para.

Ky rend shpjegon pse një tunel mund të funksionojë në një laptop dhe të dështojë në një ruter, dhe pse dështimi shpesh fillon kur nis trafiku e jo në momentin e lidhjes. Shpjegon edhe lakin: çdo rinisje rivendos sesionin përpara se rruga ta bëjë të pamundur.

Zbuloni kush e zotëron përjashtimin e pikës fundore

Klientët e mbështetur përgatisin vetë përjashtimin e tyre: një rrugë hosti drejt serverit përmes portës origjinale, ose një shenjë që e mban soketin e jashtëm jashtë tunelit. Pyetja është nëse diçka tjetër e ka hequr ose anashkaluar.

Në IPsec të bazuar në rrugë, shqyrtoni përzgjedhësit e politikës që vendosin cilat paketa hyjnë në tunel dhe konfirmoni që adresa e palës tjetër është e përjashtuar prej tyre. Në WireGuard, shenja e murit të zjarrit të ndërfaqes dhe rregullat e politikës së tij i mbajnë paketat e transportit jashtë tunelit, prandaj një rrugë parazgjedhëse e shtuar me dorë mund ta prishë atë rregullim. Një profil i dytë VPN ose një skript administrimi që rishkruan rrugën parazgjedhëse është fajtori i zakonshëm. Rregullat e gjera të anashkalimit të shtuara një nga një janë rezultati i zakonshëm, dhe e kthejnë një gabim rrugëtimi në një tabelë që askush nuk mund ta mirëmbajë.

Kontrolloni përsëri pas një ndryshimi rrjeti

Një rrugë hosti përmes një porte Wi-Fi është e saktë derisa makina kalon në një rrjet tjetër. Atëherë i njëjti simptomë kthehet pa asnjë ndryshim konfigurimi.

Shënoni adresën e pikës fundore, rrugën para dhe pas lidhjes, dhe ndërfaqen që përdori secila. Këto tre fakte zakonisht ndajnë një gabim klienti nga një anashkalim, dhe mbijetojnë edhe pas personit që i mblodhi.

Rilidhuni në rrjetin e ri dhe përsëritni leximin. Nëse përjashtimi mungon përsëri, rregullimi i përket profilit që e zotëron, jo një komande të vetme të shtypur gjatë një ndërprerjeje.