Dy lidhje ngjitëse, një portë dhe një peer i WireGuard, trafiku i të cilit vazhdon të shfaqet në linjën rezervë. Shtrëngimi i duarve mbetet i shëndetshëm gjatë gjithë kohës. Prandaj simptoma lexohet lehtë gabimisht si defekt i WireGuard dhe jo si defekt i rrugëtimit.

Kryeni kontrollet më poshtë me radhë. Secili ka kusht ndalimi, dhe kalimi përpara zakonisht jep një përgjigje të sigurt të gabuar.

Ndani shtrëngimin e duarve nga rryma e përcjellë

Shkëmbimi i kriptuar me peer-in ka një rrugë pike fundore drejt adresës publike të serverit. Trafiku i klientit i përcjellë ka një destinacion tjetër dhe mund të zgjidhet nga shenja ose rregulla politike. Janë dy vendime rrugëtimi që ndajnë një ndërfaqe. Trajtimi i njërës si provë për tjetrën është gabimi i parë.

Ndaluni sapo të kapni veten duke arsyetuar nga shtrëngimi i duarve. Ai është provë vetëm për rrugën drejt pikës fundore.

Lexoni rregullin e politikës, jo tabelën e parazgjedhur

Një tabelë e parazgjedhur tregon çfarë ndodh kur asnjë rregull politike nuk përputhet. Në një portë që rrugëton sipas burimit, shenjës ose destinacionit, rregulli vendimtar jeton diku tjetër. Tabela e thjeshtë mund të duket krejt e arsyeshme ndërsa zgjedhja e vërtetë bëhet mbi të.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Lexoni rregullat e politikës dhe tabelat ku ato drejtojnë. Pastaj konfirmoni cili rregull përputhet me rrymën tuaj testuese. Një rregull që referon një ndërfaqe që nuk mbart më lidhjen ngjitëse të synuar është gjetje, jo detaj. Kërkimi i rrugës në fund tregon përgjigjen shumë më shpejt sesa leximi i një tabele dhe hamendja.

Kontrolloni shenjën dhe përkthimin së bashku

Rrugëtimi sipas politikës mbështetet në një shenjë pakete të vendosur më herët në zinxhir. Nëse rregulli i shënjimit humb trafikun tuaj, rryma bie në tabelën kryesore dhe del përmes asaj që është e parazgjedhur atje. Paketat e përcjella shpesh anashkalojnë zinxhirë të shkruar për trafik të krijuar lokalisht.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Përkthimi duhet të pajtohet me lidhjen ngjitëse që mbart rrymën. Një rregull që përkthen drejt adresës primare ndërsa paketa del përmes linjës rezervë prodhon përgjigje të adresuara drejt një ndërfaqeje që rryma nuk e përdori kurrë. Kontrolloni kushtin e ndërfaqes të vetë rregullit të përkthimit. Një rregull pa kusht funksionon derisa të përdoret lidhja e dytë ngjitëse, dhe pastaj dështon në një mënyrë që duket e ndërprerë.

Vini re cila ndërfaqe mbart përgjigjen

Kapni në të dyja lidhjet ngjitëse ndërsa ekzekutohet një kërkesë. Shënoni cila ndërfaqe mbart kërkesën dhe cila përgjigjen. Rrugët asimetrike janë shumë më të lehta për t’u parë sesa për t’u parashikuar.

Nëse përgjigja vjen përmes lidhjes ngjitëse të gabuar, problemi është zhvendosur nga WireGuard te gjurmimi i lidhjeve ose përkthimi. Asnjë ndryshim në konfigurimin e peer-it nuk do ta rregullojë.

Ndryshoni një gjë me një rrugë kthimi

Mbani akses konsol ose jashtë brezit përpara se të redaktoni rregulla politike në një portë. Bëni një ndryshim, provoni të njëjtin destinacion të autorizuar, pastaj rilidhuni dhe konfirmoni që shtrëngimi i duarve përdor ende rrugën e synuar drejt pikës fundore. Shtoni një test numerik në familjen e dytë të adresave, sepse një politikë vetëm për v4 lë të njëjtin gabim të disponueshëm.

Shënoni cilën lidhje ngjitëse përdori çdo rrymë. Ai regjistrim e kthen raportin e ardhshëm në një kontroll dy minutash në vend të një pasditeje të tërë. shënimet e WireGuard për hapësirat e emrave dhe rrugëtimin përshkruajnë si të ndahet me qëllim rruga drejt pikës fundore nga trafiku i tunelizuar, gjë që zakonisht është më e pastër sesa kopjimi i një zgjidhjeje anashkaluese me rrugë të parazgjedhur.

Artikuj të ngjashëm