Rekursīvā maršrutēšana: kad tunelis pārtver savus pakešus

Tunelis paceļas, žurnāls rāda pabeigtu rokasspiedienu, un sekundi vēlāk tā pati sesija mirst un atkal pieslēdzas cilpā. Šim modelim ir konkrēts iemesls: maršruts uz serveri tagad rāda tunelī, tāpēc pakešus, kas pārnēsā tuneli, sūta caur tuneli. Autentifikācijā nekas nav mainījies, tāpēc atkārtota pieteikšanās datu ievade neko nemaina. Salīdziniet ārējo ceļu pirms maršruta maiņas un pēc tās, un rekursija kļūst redzama.

Vispirms pārbaudiet ārējo ceļu

Spēlē ir divi pakeši, nevis viens. Iekšējais pakešs pieder lietojumprogrammai un tam jābūt šifrētam, bet ārējais pakešs ir adresēts serverim un tam jānokļūst pie tā pa ceļu, kas nav atkarīgs no tuneļa.

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

Pajautājiet kodolam maršrutu uz servera adresi pēc tam, kad tunelis ir pacēlies, un vēlreiz pēc tam, kad mainījies noklusējuma maršruts. Nākamais lēciens, kas nokrīt uz tuneļa ierīci, ir pati rekursija, un tā ir redzama bez jebkādas pakešu tveršanas. Sasaiste ar saskarni, atzīmes vai tīkla nosaukumu telpa var padarīt vienkāršu meklēšanu nepilnīgu, tāpēc izmantojiet kontekstu, ko izmanto pats klients. Kad atbilde izskatās pareiza, bet sesija joprojām griežas cilpā, lasiet maršrutēšanas politikas noteikumus, ne tikai galveno tabulu.

Kāpēc sesija iztur acumirkli

Rokasspiediens tiek pabeigts pirms jaunā maršruta instalēšanas, tāpēc pirmās sekundes izskatās veselas. Tiklīdz klients pievieno noklusējuma maršrutu, nākamais ārējais pakešs tam seko saskarnē, pa kuru šim ārējam pakešam jābrauc. Serveris neko neredz, klients sūta vēlreiz, un mēģinājums vai nu beidzas ar noildzi, vai nogalina sesiju un sāk no jauna.

Šī secība izskaidro, kāpēc tunelis var strādāt klēpjdatorā un neizdoties maršrutētājā, un kāpēc kļūme bieži sākas, kad sākas datplūsma, nevis pieslēgšanās brīdī. Tā izskaidro arī cilpu: katra atkārtota palaišana atjauno sesiju, pirms maršruts to padara neiespējamu.

Noskaidrojiet, kam pieder galapunkta izņēmums

Atbalstītie klienti iekārto savu izņēmumu: maršrutu uz servera resursdatoru caur sākotnējo vārteju vai atzīmi, kas tur ārējo ligzdu ārpus tuneļa. Jautājums ir, vai kaut kas cits to nav noņēmis vai pārrakstījis.

Maršrutos balstītā IPsec pārbaudiet politikas atlasītājus, kas nosaka, kuri pakeši nonāk tunelī, un apstipriniet, ka partnera adrese no tiem ir izslēgta. WireGuard gadījumā saskarnes ugunsmūra atzīme un tās politikas noteikumi tur transporta pakešus ārpus tuneļa, tāpēc manuāli pievienots noklusējuma maršruts var salauzt šo kārtību. Otrs VPN profils vai pārvaldības skripts, kas pārraksta noklusējuma maršrutu, ir bieži vaininieks. Plaši apiešanas noteikumi, kas pievienoti pa vienam, ir ierastais rezultāts, un tie pārvērš maršrutēšanas kļūdu tabulā, ko neviens nevar uzturēt.

Pēc tīkla maiņas pārbaudiet vēlreiz

Maršruts uz resursdatoru caur Wi-Fi vārteju ir pareizs, līdz iekārta pāriet citā tīklā. Tad tas pats simptoms atgriežas bez jebkādām konfigurācijas izmaiņām.

Pierakstiet galapunkta adresi, maršrutu pirms un pēc pieslēgšanās un saskarni, ko izmantoja katrs. Šie trīs fakti parasti atdala klienta kļūdu no pārrakstīšanas, un tie paliek arī pēc tam, kad tos apkopojušais cilvēks aiziet.

Pieslēdzieties jaunajā tīklā vēlreiz un atkārtojiet nolasīšanu. Ja izņēmums atkal trūkst, labojums pieder profilam, kuram tas ir, nevis vienreizējai komandai, kas ierakstīta pārtraukuma laikā.