VPN nga sajti në sajt punon vetëm në një drejtim: dy defekte të ndryshme

Sajti A arrin B, B nuk arrin A, dhe tuneli duket mirë në të dy drejtimet. Përpara se të prekni tunelin, përcaktoni cilin defekt keni vërtet. Një lidhje e re e nisur në B dhe e refuzuar dhe një përgjigje për një lidhje të nisur në A që nuk vjen kurrë prodhojnë ankesa të ngjashme dhe diagnoza krejt të ndryshme. Njëra është problem politike ose rruge në shteg; tjetra është problem i rrugës së kthimit ose i gjendjes për trafikun që ishte tashmë i lejuar.

Ky dallim vendos cilat komanda ia vlen të ekzekutohen.

Dy defekte që duken identike

Në rastin e parë hosti i B dërgon një SYN te A, dhe asgjë nuk kthehet. Në të dytin hosti i A hap me sukses një sesion dhe përgjigjja zhduket në rrugën e kthimit. Të dy përdoruesit thonë se lidhja është njëdrejtimëshe, dhe të dy përshkruajnë një paketë që u zhduk, prandaj përshkrimi i vetëm nuk mund t'i ndajë.

Pyetni cila anë e nisi përpjekjen që dështoi. Ky fakt i vetëm heq gjysmën e shkaqeve të mundshme.

Më pas verifikoni që testi përdori të njëjtat hoste dhe të njëjtin shërbim gjatë gjithë kohës. Një ping nga njëra anë dhe një lidhje me një dosje të përbashkët nga ana tjetër testojnë dy gjëra të ndryshme, dhe një diagnostikim i bërë nga porta mund të zgjedhë një adresë tuneli që asnjë trafik përdoruesi nuk e përdor.

Rasti i parë: mungon rruga e kthimit

Një server i largët që përgjigjet përmes një porte tjetër të paracaktuar mund ta marrë kërkesën dhe ta drejtojë përgjigjen diku tjetër. Atëherë muret e zjarrit që ndjekin gjendjen e hedhin poshtë përgjigjen asimetrike, sepse nuk përputhet me një rrjedhë të vendosur, gjë që duket saktësisht si një drejtim që nuk ka punuar kurrë. Përkthimi shton një variant tjetër: destinacioni sheh një burim të përkthyer dhe i përgjigjet atij, prandaj një rregull i shkruar për adresën origjinale nuk përputhet kurrë.

Verifikoni adresën që destinacioni vërtet vëzhgon pas përkthimit, dhe rrugën e kthimit për atë adresë në vend të nënrrjetit origjinal.

Rasti i dytë: politika nuk e lejoi kurrë

Rasti i kundërt është më i thjeshtë dhe më i zakonshëm sesa duket: një zyrë duhet të konsumojë një shërbim qendror dhe nuk duhet të nisë kurrë lidhje drejt qendrës. Kjo asimetri është një vendim i qëllimshëm aksesi, dhe tuneli punon siç është projektuar. Lexoni politikën e aksesit përpara se të ndryshoni çdo rregullim të tunelit. Dokumenti, jo kapja e paketave, tregon cili drejtim ishte i synuar. Një kapje mund të tregojë vetëm çfarë ndodhi, jo çfarë ishte e autorizuar.

Nëse nisja dykahëshe është vërtet e nevojshme, shtoni lejen për shërbimin konkret përmes grupit të rregullave të mbështetur nga platforma. Të bësh çdo nënrrjet reciprokisht të besuar për të rregulluar një aplikacion e kthen një kërkesë të ngushtë në një leje të gjerë, dhe ky shkëmbim rrallë rishikohet më pas.

Krahasoni përpara dhe pas në të njëjtat hoste

Vëzhgoni të dy skajet e së njëjtës përpjekje, jo dy përpjekje të ndara. Kapni në portën e hostit që nis dhe në destinacion, pastaj krahasoni çfarë hyri, çfarë doli dhe cilën adresë pa ana e largët.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Nëse kapja në destinacion e tregon kërkesën me një adresë burimore të papritur, përgjigjja qëndron në përkthim ose në rrugëtim, jo në politikën e sigurisë së tunelit. Nëse destinacioni nuk tregon fare kërkesë, paketa nuk e kaloi kurrë shtegun e mbrojtur.

Pas një korrigjimi, përsëritni të njëjtin test nga i njëjti host dhe konfirmoni që aksesi i palidhur vazhdon të refuzohet. Një status tuneli “established” nuk mbështet vetëm asnjë nga dy përfundimet.