Waarom traceroute in één richting sterft door een VPN-tunnel

Traceroute-uitvoer die in één richting voltooit en in de andere rijen sterretjes afdrukt, ziet eruit als asymmetrische doorsturing, en dat is het meestal niet. Elke getoonde hop vereist dat de sonde aankomt, dat een router besluit te antwoorden en dat het antwoord terugreist en aan de sonde wordt gekoppeld. Breek één van die schakels en de rij wordt een sterretje, terwijl de tunnel data blijft dragen.

De trace is bewijs over diagnostiek voordat het bewijs over transport is. De vraag die de moeite waard is, is welke van de drie schakels faalde, en het antwoord komt uit de pakketten, niet uit de vorm van de uitvoer.

Een sterretje is een ontbrekend antwoord, geen ontbrekende hop

Traceroute loopt naar buiten door sondes te sturen waarvan de TTL elke ronde één router verder verloopt. Een router die een verlopen sonde weggooit, hoort een ICMP Time Exceeded-bericht terug te sturen dat zichzelf noemt, en het gereedschap drukt die naam af. Waar het gereedschap echt op wacht, is dat dat bericht binnen een time-out aankomt. Als de router antwoordt vanaf een ander bronadres, beperkt hoe vaak hij fouten genereert, of de sonde woordeloos laat vallen, levert de ronde niets afdrukbaars op.

Geen van die uitkomsten zegt dat de heenweg kapot is. Een sterretje is een rapport over onbeantwoorde post, niet over een lege weg.

De sondemethode bepaalt welk filter je tegenkomt

De standaardmethode op Linux is meestal een UDP-doelpoort met een hoog nummer, tracert op Windows stuurt ICMP-echo's, en Linux kan worden opgedragen in plaats daarvan ICMP of TCP te gebruiken. Elk daarvan ziet er voor een stateful firewall of een cloudbeveiligingsgroep als een ander soort verkeer uit. Een UDP-trace van de ene kant vergelijken met een ICMP-trace van de andere kant vergelijkt twee verschillende experimenten. Leg de methode, de adresfamilie, het bronadres en de time-out vast voordat je de resultaten een verschil noemt.

Voor een eerlijke vergelijking voer je de trace uit vanaf de hosts die het verkeer echt dragen, niet vanaf een gateway die namens hen doorstuurt. Een door de router gegenereerde trace gebruikt het eigen bronadres en uitvoerbeleid van de router, die strenger kunnen zijn dan alles wat een client ziet. Noteer de exacte opdracht zodat de volgende persoon die kan herhalen.

De time-outwaarde is de andere helft van het experiment, en die raakt makkelijk uit de notities. Een wachttijd van twee seconden op een overbelast pad rapporteert sterretjes waar een wachttijd van vijf seconden hops rapporteert. Houd de waarde identiek over alle runs zodat de vergelijking over het netwerk blijft gaan.

De terugweg is een eigen route

Een ICMP-fout is een gewoon pakket met zijn eigen bron en bestemming, en het heeft een route terug naar de tracer nodig. Als het tunnelbeleid de LAN-prefixen draagt maar niet het routeradres dat de fout genereerde, verlaat het bericht een pad dat jou niet kan bereiken. Antwoordfiltering kan het weggooien zelfs wanneer de route bestaat, omdat het pakket aankomt vanaf een onverwacht adres op een onverwachte interface. Dat is een mismatch in het diagnosevlak en geen toepassingsfout.

Elke selector verbreden tot de trace voltooit, maakt het beeld mooier en het beleid slechter. Repareer het specifieke diagnoseadres, of accepteer het sterretje en test de toepassing op een andere manier.

Bevestig de tunnel met een echt verzoek

Een TCP-handshake op de eigen poort van de dienst oefent doorsturing, terugroutering en filtering in de richting die ertoe doet. De opdrachten hieronder draaien aan beide uiteinden en vergelijken wat elke kant kan openen. Vervang de dienstpoort en de naam van de tunnelinterface door die van je eigen configuratie.

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

Lees eerst de twee traceroute-runs: als de ICMP-run hops toont en de TCP-run niet, is het verschil methode, niet pad. Neem daarna het curl-resultaat als het antwoord op toepassingsniveau, want een voltooide uitwisseling met een zinvolle statuscode betekent dat zowel de heen- als de terugweg werken voor echt verkeer. De socketlijst toont of de verbinding überhaupt tot stand is gekomen, wat geen enkele trace je kan vertellen.

Een tunnel die een interactieve sessie in beide richtingen draagt terwijl één traceroute sterretjes afdrukt, is gezond en alleen niet fotogeniek. Bewaar de opdrachtuitvoer van elke kant als het record, en behandel ontbrekende hops als een open vraag over diagnostiek in plaats van een oordeel over de VPN.