Pse një VPN mund të duket i lidhur kur asgjë nuk funksionon

Klienti juaj raporton i lidhur ndërsa ndërfaqja është lart dhe shfletuesi skadon, dhe asnjë nga këto tri pohime nuk është e rreme. I lidhur përshkruan një shtresë që nuk ka asnjë lidhje me faqen që kërkuat. Të vendosësh cila shtresë raporton kërkon një kërkesë të re dhe një vështrim te numëruesi që do të provonte se trafiku u zhvendos. Një rinisje e hedh atë provë dhe rindërton kushtet që po përpiqeshit të vëzhgonit.

Tri gjëra të ndryshme që quhen të lidhura

Në fund, i lidhur mund të nënkuptojë që një proces klienti po ekzekutohet dhe mban një soket drejt një partneri. Mbi atë, mund të nënkuptojë që ekziston një ndërfaqe me adresë, të cilën një pajisje e përhershme ose një rutinë rikuperimi mund ta krijojnë pa një sesion të gjallë pas saj. Në nivelin e kontrollit, mund të nënkuptojë që u negociua një asociacion, gjë që nuk thotë asgjë nëse një paketë e vetme ka kaluar nën të. Secila prej tyre i mbijeton dështimeve që të tjerat nuk u mbijetojnë, dhe një klient zakonisht shfaq më të fortën që mund të pretendojë.

Një ikonë e gjelbër dhe një tunel i vdekur janë pra të pajtueshme dhe jo kontradiktore; ato raportojnë për objekte të ndryshme. Kjo është e gjithë arsyeja pse ky defekt vazhdimisht diagnostikohet gabimisht si një bug i klientit.

Dërgoni një kërkesë të padëmshme drejt një destinacioni që ju nevojitet vërtet përpara se të prekni daemon-in, dhe mbani bllokun e kërkuar të trafikut të drejtpërdrejtë në vend ndërsa punoni. Një rinisje fshin rendin e ngjarjeve dhe pastaj i rikrijon ato mjaft afër për të fshehur shkakun, prandaj i njëjti tiket kthehet një javë më vonë pa asgjë të re në të. Një kërkesë, një lexim i numëruesit dhe shkaktari që prodhoi defektin janë prova minimale.

Cili numërues provon se paketat u zhvendosën

Në IPsec, asociacioni IKE dhe asociacioni CHILD janë objekte të veçanta, dhe vetëm child mban numëruesit që i përgjigjen kësaj pyetjeje. Listo child, vëzhgo nëse paketat rriten në të dy drejtimet, dhe krahaso me atë që aplikacioni po përpiqet të bëjë. Një asociacion i instaluar në zero është një gjetje tjetër nga ai që rritet ndërsa aplikacioni vazhdon të dështojë; i pari do të thotë se trafiku nuk po zgjidhet, i dyti se po lëviz dhe defekti është më tutje. Lexoni numëruesit dy herë, me disa sekonda distancë, sepse një mostër e vetme nuk mund të tregojë një tendencë.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Numëruesit zero tregojnë nga zgjedhja: rrugëtimi, politika, një hapësirë emrash nga e cila doli paketa, ose një ndërfaqe me të cilën klienti nuk u lidh kurrë. Numëruesit në rritje tregojnë larg tunelit, prandaj vazhdoni me përcjelljen në skajin e largët, zgjidhjen e emrave, rrugën e kthimit dhe shërbimin e destinacionit, në këtë rend. Një protokoll pa objekt child të veçantë e ekspozon të njëjtën provë në termat e vet, prandaj përdorni atë që raporton për gjendjen e partnerit dhe numrin e paketave në vend që të huazoni fjalorin e IPsec. Forma e leximit ka më shumë rëndësi sesa mjeti që e prodhoi.

Ku qëndron defekti pasi numëruesit lëvizin

Një portë që përgjigjet në adresën e vet të menaxhimit provon se porta funksionon, jo se diçka pas saj i shërben kërkesës tuaj, prandaj provoni anën e largët dhe jo kutinë në mes. Zgjidhja e emrave i fsheh më mirë defektet, sepse një zgjidhës që nuk arrihet përmes tunelit skadon po ashtu si një lidhje e vdekur. Dy kërkime i ndajnë ato raste, dhe të dyja janë të lira. Pyesni së pari zgjidhësin që tuneli imponon, pastaj pyesni një zgjidhës publik për të njëjtin emër.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Një emër që zgjidhet përmes zgjidhësit publik por jo përmes atij të tunelit do të thotë se rruga DNS është e thyer, ndërsa një emër që zgjidhet përmes të dyjave dhe prapë skadon në shfletues tregon rrugën e kthimit ose shërbimin. Nëse ping-u me adresë ka sukses dhe aplikacioni prapë refuzon, rrjeti e dorëzoi kërkesën dhe shërbimi e refuzoi atë, që është një fazë shumë më e vonë.

Regjistroni shkaktarin, pastaj ndryshoni një gjë

Regjistroni çfarë i parapriu defektit: një periudhë pasiviteti, një ndryshim rrjeti, një rinovim çelësi, një laptop i rifilluar ose një sistem i restauruar. Këto prodhojnë mekanizma të ndryshëm, dhe zakonisht vetëm sistemi i restauruar rregullohet vetë, që është pikërisht rasti që nuk ju mëson asgjë. Një rinisje heq rendin e ngjarjeve dhe pastaj rikrijon kushte mjaft të afërta për të fshehur shkakun. Shkruani shkaktarin ndërsa është ende i riprodhueshëm.

Pastaj bëni një korrigjim të mbështetur dhe përsëritni kërkesën origjinale bashkë me shkaktarin që prodhoi defektin. Pasiviteti është shkaktari më i lehtë për t'u riprodhuar, prandaj është konfirmimi më i shpejtë se korrigjimi trajtoi mekanizmin dhe jo simptomën.

Ajo që doni të raportoni është prova se trafiku që kishit ndërmend të dërgoni arriti në shërbimin ku kishit ndërmend të arrinit. Një ikonë që bëhet e gjelbër, një faqe e ruajtur në memorie që ngarkohet dhe një numërues që lëviz të gjitha provojnë më pak se një kërkesë e përfunduar drejt destinacionit të synuar. Mbani bashkë kërkesën, leximin e numëruesit dhe shkaktarin, që personi tjetër të mund të dallojë një korrigjim nga një rastësi.