Ping nu este o dovadă: testați calea dintre două locații

Un ping de la gateway nu spune nimic despre serviciu. Parcurgeți calea de la un client real, folosiți protocolul aplicației și reproduceți dimensiunea sau numele care eșuează.

Tunelul este activ, gateway-urile își răspund, iar utilizatorii dintr-o locație tot nu pot deschide partajarea de fișiere din cealaltă. Cineva face ping de la gateway, primește un răspuns și declară rețeaua sănătoasă. Acel răspuns a călătorit între două dispozitive care nu au fost niciodată problema. Un test util începe pe gazda care are nevoie de serviciu, folosește protocolul pe care îl folosește aplicația și reproduce condiția în care eșuează. Tot restul este lumină verde pentru o cale pe care nu este nimeni.

Începeți cu clientul care are nevoie de serviciu

Notați patru lucruri înainte de a testa ceva: adresa clientului, adresa destinației, numele gazdei și portul aplicației. Apoi confirmați că serviciul funcționează local în propria locație, de pe o gazdă alăturată. Fără această linie de bază nu puteți distinge un tunel defect de un serviciu defect, iar jumătate dintre aceste tichete sunt al doilea caz.

Încercați numele de gazdă documentat și, unde serviciul permite, o verificare directă a adresei aceluiași port. O căutare de nume eșuată și o adresă rezolvată inaccesibilă vă duc pe căi diferite. Dacă înlocuiți un nume de gazdă cu un IP, nu dezactivați verificarea identității HTTPS pentru ca să funcționeze; un avertisment de certificat este informație, nu obstacol.

Parcurgeți calea la fiecare margine

Citiți ruta pe care o alege clientul, apoi ruta pe care o alege gateway-ul pentru acea destinație, apoi contoarele sau o captură limitată la fiecare margine. Căutați două fapte: dacă cererea a ajuns în LAN-ul îndepărtat și dacă s-a întors un răspuns. Contoarele de interfață includ orice alt flux, așa că corelați după marcajul de timp exact și perechea de adrese, nu după forma graficului. O captură făcută la marginea greșită este mai rea decât niciuna, pentru că arată ca o dovadă.

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

Dacă cererea apare la marginea îndepărtată fără un răspuns în spate, problema este de cealaltă parte: un firewall, o rută de întoarcere lipsă sau o gazdă care nu acceptă sursa. Dacă cererea nu apare niciodată, ruta locală sau selectorii tunelului nu au transportat-o, iar cealaltă parte încă nu merită investigată.

Folosiți protocolul pe care îl folosește aplicația

ICMP este o sondă slabă. Poate fi filtrat, limitat ca rată sau tratat de o politică diferită de cea a serviciului, ceea ce face ambigue atât succesul, cât și eșecul. Testați portul real și, unde puteți, strângerea de mână reală a protocolului.

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

O strângere de mână TCP finalizată dovedește accesibilitatea și politica pentru acel port. Nu dovedește că aplicația funcționează: autentificarea, o încărcare sau un apel API anume pot eșua în continuare. Testați operația pe care utilizatorii o fac efectiv, cu un echivalent inofensiv în loc să trimiteți repetat o tranzacție reală.

Reproduceți condiția în care eșuează

Eșecurile care apar doar la transferuri mari sunt o problemă de dimensiune, nu de conectivitate. Trimiteți un pachet mare cu bitul don't-fragment setat și urmăriți unde se oprește. Dacă o cerere mică reușește și una mare se blochează, MTU-ul tunelului și tratarea MSS la gateway-uri sunt următorii suspecți.

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

Dacă eșuează doar o subrețea, uitați-vă la selectorii de trafic, anunțurile de rutare și gateway-ul de întoarcere al acelei subrețele. Dacă eșuează doar numele gazdei, urmați DNS, inclusiv ce resolver a folosit clientul și dacă vizualizarea îndepărtată este vizibilă din acea locație. Trei eșecuri diferite, trei corecții diferite, iar testul ping nu distinge niciunul.

După corecție, repetați același test

Rulați din nou același client, destinație, port și încărcătură. Apoi reconectați sau exersați calea de comutare la eroare dacă proiectarea are una, pentru că o corecție care funcționează doar cât timp instanța originală a tunelului este vie nu a fost testată. Țineți testul legat de o sursă reală, o destinație reală și o operație reală, nu de un singur indicator verde pe un tablou de bord.

Notați cele patru valori de bază și rezultatul. Următorul raport despre același simptom va putea atunci începe cu dovezi, nu cu un ping.

Articole similare