De ce traceroute moare într-o singură direcție printr-un tunel VPN

Ieșirea traceroute care se completează într-o direcție și tipărește rânduri de steluțe în cealaltă pare o redirecționare asimetrică, și de obicei nu este. Fiecare salt afișat are nevoie ca sonda să ajungă, ca un router să decidă să răspundă și ca răspunsul să revină și să fie asociat sondei. Rupeți oricare dintre aceste verigi și rândul devine o steluță, în timp ce tunelul continuă să transporte date.

Urmărirea este o dovadă despre diagnosticare înainte de a fi o dovadă despre transport. Întrebarea care merită pusă este care dintre cele trei verigi a eșuat, iar răspunsul vine din pachete, nu din forma ieșirii.

O steluță este un răspuns lipsă, nu un salt lipsă

Traceroute înaintează spre exterior trimițând sonde al căror TTL expiră cu un router mai departe în fiecare rundă. Un router care aruncă o sondă expirată ar trebui să returneze un mesaj ICMP Time Exceeded care se numește pe sine, iar instrumentul tipărește acel nume. Ce așteaptă de fapt instrumentul este ca mesajul să sosească într-un interval de așteptare. Dacă routerul răspunde de la o altă adresă sursă, limitează cât de des generează erori sau aruncă sonda fără un cuvânt, runda nu produce nimic de tipărit.

Niciunul dintre aceste rezultate nu spune că drumul înainte este rupt. O steluță este un raport despre poștă fără răspuns, nu despre un drum gol.

Metoda sondei decide ce filtru întâlniți

Metoda implicită pe Linux este de obicei un port de destinație UDP cu număr mare, tracert din Windows trimite ecouri ICMP, iar Linux poate primi ordinul să folosească ICMP sau TCP în schimb. Fiecare dintre ele arată ca un alt tip de trafic pentru un firewall cu stare sau un grup de securitate din cloud. Compararea unei urmăriri UDP de pe o parte cu o urmărire ICMP de pe cealaltă compară două experimente diferite. Fixați metoda, familia de adrese, adresa sursă și intervalul de așteptare înainte de a numi rezultatele o diferență.

Pentru o comparație corectă, rulați urmărirea de pe gazdele care transportă efectiv traficul, nu de pe o poartă care redirecționează în numele lor. O urmărire generată de router folosește adresa sursă și politica de ieșire ale routerului, care pot fi mai stricte decât orice vede un client. Notați comanda exactă pentru ca următoarea persoană să o poată repeta.

Valoarea intervalului de așteptare este cealaltă jumătate a experimentului și este ușor de omis din notițe. O așteptare de două secunde pe un drum congestionat raportează steluțe acolo unde o așteptare de cinci secunde raportează salturi. Păstrați valoarea identică între rulări pentru ca comparația să rămână despre rețea.

Calea de întoarcere este o rută proprie

O eroare ICMP este un pachet obișnuit cu sursa și destinația lui, și are nevoie de o rută înapoi la trasor. Dacă politica tunelului transportă prefixele LAN dar nu adresa routerului care a generat eroarea, mesajul pleacă pe o cale care nu vă poate ajunge. Filtrarea răspunsurilor îl poate arunca chiar și când ruta există, pentru că pachetul sosește de la o adresă neașteptată pe o interfață neașteptată. Aceasta este o nepotrivire în planul de diagnosticare, nu o defecțiune a aplicației.

Lărgirea fiecărui selector până când urmărirea se completează face imaginea mai frumoasă și politica mai proastă. Reparați adresa de diagnosticare specifică sau acceptați steluța și testați aplicația în alt mod.

Confirmați tunelul cu o cerere reală

O strângere de mână TCP pe portul propriu al serviciului exersează redirecționarea, rutarea de întoarcere și filtrarea în direcția care contează. Comenzile de mai jos rulează la ambele capete și compară ce poate deschide fiecare parte. Înlocuiți portul serviciului și numele interfeței tunelului cu cele din configurația dumneavoastră.

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

Citiți mai întâi cele două rulări traceroute: dacă rularea ICMP arată salturi iar cea TCP nu, diferența este de metodă, nu de cale. Apoi luați rezultatul curl ca răspuns la nivel de aplicație, pentru că un schimb încheiat cu un cod de stare rezonabil înseamnă că ambele căi, înainte și înapoi, funcționează pentru trafic real. Lista de socketuri arată dacă conexiunea este stabilită, ceea ce nicio urmărire nu vă poate spune.

Un tunel care transportă o sesiune interactivă în ambele direcții în timp ce un traceroute tipărește steluțe este sănătos și doar nefotogenic. Păstrați ieșirea comenzilor de fiecare parte ca înregistrare și tratați salturile lipsă ca pe o întrebare deschisă despre diagnosticare, nu ca pe o sentință despre VPN.