VPN lidhet, por pajisjet e LAN nuk arrihen: çfarë duhet kontrolluar

Trafiku hyn në tunel, porta përgjigjet në adresën e vet dhe asgjë pas saj nuk përgjigjet. Modeli është i zakonshëm dhe nuk është kundërshtim: një përgjigje nga porta provon se tuneli përfundoi dhe nuk provon asgjë për atë që ndodh me një paketë të adresuar përtej saj. Dy testet ushtrojnë rrugë kodi të ndryshme në të njëjtën makinë.

Tani e tutje testoni diçka në anën tjetër të portës. Adresa e vetë portës do të vazhdojë të përgjigjet, sado e prishur që është përcjellja.

Porta përgjigjet nga staku i vet

Një paketë e adresuar te porta dërgohet në rrugën e saj lokale të hyrjes, ku kerneli vendos nëse një socket që dëgjon e pranon atë. Një paketë e adresuar te një host pas portës dërgohet përkundrazi në rrugën e përcjelljes, ku zbatohet një grup tjetër kontrollesh. Përcjellja mund të jetë plotësisht e çaktivizuar, ose kerneli mund ta aktivizojë atë dhe pastaj një rregull filtri që nuk e përmend kurrë tunelin ta refuzojë. Asgjë nga kjo nuk ndikon në përgjigjen e vetë portës, prandaj simptoma mashtron kaq me besueshmëri.

Faqet e administrimit të arritura përmes tunelit i përkasin gjithashtu kategorisë së parë. Ato janë provë për tunelin, jo për rrjetin pas tij.

Ndiqni rrjedhën deri në kufirin e parë që e hedh

Filloni te klienti dhe konfirmoni rrugën dhe adresën burimore që do të përdorë rrjedha. Pastaj vëzhgoni portën për mbërritjen e pikërisht asaj rrjedhe, dhe përsëri të njëjtën rrjedhë që largohet drejt LAN. Nëse nuk mbërrin kurrë, problemi është në anën e klientit ose në prefikset e lejuara të tunelit. Nëse mbërrin dhe nuk largohet kurrë, problemi është në përcjellje ose në një filtër të rrugës përpara, dhe kapja tashmë ka thënë se cila.

Kryerja e të njëjtit test nga porta fsheh gjysmën interesante, sepse një paketë që buron nga porta ka një burim tjetër dhe një kërkesë tjetër për kthim. Përdorni rrjedhën e klientit, me adresën e vet burimore, në çdo hap. Një kapje e marrë në ndërfaqen e gabuar prodhon marrëzi me vetëbesim.

Rrugët e kthimit dhe muret e zjarrit të hosteve dështojnë veçmas

Pasi paketa arrin te hosti, duhet të plotësohen edhe tri gjëra. Shërbimi duhet të dëgjojë në adresën ku paketa u dërgua, muri i zjarrit i hostit duhet ta pranojë atë, dhe përgjigja duhet të ketë një rrugë kthimi drejt grupit të klientëve. E fundit dështon shpesh, sepse rruga e paracaktuar e hostit tregon drejt një routeri që nuk ka dëgjuar kurrë për gamën e tunelit. Rezultati është një lidhje që vendoset nga këndvështrimi i hostit dhe vdes në heshtje në drejtimin tjetër.

Testoni qëllimisht rrugën e kthimit duke dërguar nga klienti dhe duke vëzhguar kthimin. Një kapje njëdrejtimëshe zgjidh në sekonda atë që një orë hamendjeje nuk do ta zgjidhë.

Konfirmoni çdo hap me adresën burimore të klientit

Kryeni kontrollet me radhë dhe ruani çdo dalje, sepse vlera qëndron në krahasim dhe jo në një rresht të vetëm. Komandat më poshtë fiksojnë adresën burimore, tregojnë rrugën e zgjedhur dhe kapin të dyja anët e përcjelljes. Zëvendësoni hostin tuaj të LAN dhe ndërfaqen e tunelit.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Kërkesa e rrugës tregon nëse klienti do ta dërgonte fare atë paketë në tunel, dhe ping tregon nëse u kthye diçka nga hosti. Krahasimi i dy kapjeve ndan mbërritjen nga dalja, pasi një kornizë në ndërfaqen e tunelit pa homolog në ndërfaqen e LAN është vendim përcjelljeje, jo dështim shërbimi. Kur të dyja kapjet tregojnë kërkesën dhe vetëm njëra tregon përgjigjen, rruga e kthimit është i dyshuari i mbetur.

Shënoni cila adresë u përgjigj dhe cili destinacion i përcjellë dështoi. Ajo fjali e bën raportin të zbatueshëm në vend të pretendimit se serveri është i paarritshëm.