Ping nuk është provë: provoni rrugën mes dy lokacioneve

Tuneli është aktiv, portat i përgjigjen njëra-tjetrës, dhe përdoruesit në një lokacion ende nuk mund të hapin ndarjen e skedarëve në tjetrin. Dikush bën ping nga porta, merr përgjigje dhe e shpall rrjetin të shëndetshëm. Ajo përgjigje udhëtoi mes dy pajisjeve që nuk ishin kurrë problemi. Një test i dobishëm fillon në hostin që ka nevojë për shërbimin, përdor protokollin që përdor aplikacioni dhe riprodhon kushtin në të cilin dështon. Çdo gjë tjetër është dritë jeshile për një rrugë ku nuk është askush.

Filloni nga klienti që ka nevojë për shërbimin

Shkruani katër gjëra para se të testoni çdo gjë: adresën e klientit, adresën e destinacionit, emrin e hostit dhe portin e aplikacionit. Më pas konfirmoni se shërbimi funksionon lokalisht në lokacionin e vet, nga një host pranë tij. Pa këtë vijë bazë nuk mund të dalloni një tunel të prishur nga një shërbim i prishur, dhe gjysma e këtyre tiketave është i dyti.

Provoni emrin e dokumentuar të hostit dhe, ku shërbimi e lejon, një kontroll të drejtpërdrejtë të adresës së të njëjtit port. Një kërkim emri i dështuar dhe një adresë e zgjidhur e paarritshme ju çojnë në rrugë të ndryshme. Nëse zëvendësoni një emër hosti me një IP, mos çaktivizoni kontrollin e identitetit HTTPS që të funksionojë; një paralajmërim certifikate është informacion, jo pengesë.

Përshkoni rrugën në çdo skaj

Lexoni rrugën që zgjedh klienti, pastaj rrugën që zgjedh porta për atë destinacion, pastaj numëruesit ose një kapje të kufizuar në çdo skaj. Po kërkoni dy fakte: a arriti kërkesa në LAN-in e largët dhe a u kthye një përgjigje. Numëruesit e ndërfaqes përfshijnë çdo rrjedhë tjetër, prandaj lidhni sipas vulës kohore të saktë dhe çiftit të adresave, jo sipas formës së grafikut. Një kapje e marrë në skajin e gabuar është më keq se asnjë, sepse duket si provë.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Nëse kërkesa shfaqet në skajin e largët pa një përgjigje pas saj, problemi është në anën tjetër: një firewall, një rrugë kthimi që mungon ose një host që nuk e pranon burimin. Nëse kërkesa nuk shfaqet kurrë, rruga lokale ose përzgjedhësit e tunelit nuk e transportuan, dhe ana tjetër ende nuk meriton hetim.

Përdorni protokollin që përdor aplikacioni

ICMP është një sondë e dobët. Mund të filtrohet, të kufizohet në shpejtësi ose të trajtohet nga një politikë e ndryshme nga shërbimi, gjë që i bën të dyja, suksesin dhe dështimin, të paqarta. Testoni portin real dhe, kur mundeni, shtrëngimin real të duarve të protokollit.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Një shtrëngim duarsh TCP i përfunduar provon arritshmërinë dhe politikën për atë port. Nuk provon se aplikacioni funksionon: vërtetimi, një ngarkim ose një thirrje specifike API mund të dështojnë ende. Testoni operacionin që përdoruesit kryejnë vërtet, me një ekuivalent të padëmshëm në vend të dërgimit të përsëritur të një transaksioni real.

Riprodhoni kushtin në të cilin dështon

Dështimet që shfaqen vetëm me transferime të mëdha janë problem madhësie, jo lidhshmërie. Dërgoni një paketë të madhe me bitin don't-fragment të vendosur dhe shikoni ku ndalon. Nëse një kërkesë e vogël ka sukses dhe një e madhe ngec, MTU-ja e tunelit dhe trajtimi i MSS në porta janë të dyshuarit e radhës.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Nëse dështon vetëm një nënrrjetë, shikoni përzgjedhësit e trafikut, njoftimet e rrugëve dhe portën e kthimit të asaj nënrrjete. Nëse dështon vetëm emri i hostit, ndiqni DNS, duke përfshirë cilin zgjidhës përdori klienti dhe a është i dukshëm pamja e largët nga ai lokacion. Tri dështime të ndryshme, tri rregullime të ndryshme, dhe testi i ping nuk dallon asnjë prej tyre.

Pas rregullimit, përsëritni të njëjtin test

Ekzekutoni përsëri të njëjtin klient, destinacion, port dhe ngarkesë. Pastaj rilidhuni ose provoni rrugën e rezervë nëse dizajni ka një të tillë, sepse një rregullim që funksionon vetëm sa kohë instanca origjinale e tunelit është gjallë nuk është testuar. Mbani testin të lidhur me një burim real, një destinacion real dhe një operacion real në vend të një treguesi të gjelbër në një panel.

Regjistroni katër vlerat bazë dhe rezultatin. Raporti i ardhshëm për të njëjtin simptomë mund të fillojë atëherë nga provat, jo nga një ping.