Proč traceroute umírá jedním směrem přes VPN tunel

Výstup traceroute, který se dokončí jedním směrem a ve druhém vypíše řady hvězdiček, vypadá jako asymetrické předávání a obvykle jím není. Každý zobrazený hop potřebuje, aby sonda dorazila, aby se router rozhodl odpovědět a aby se odpověď vrátila a spárovala se sondou. Přerušte kterýkoli z těchto článků a řádek se změní na hvězdičku, zatímco tunel dál přenáší data.

Trasa je důkazem o diagnostice dřív, než je důkazem o přenosu. Otázka, kterou stojí za to položit, je, který ze tří článků selhal, a odpověď přichází z paketů, ne z podoby výstupu.

Hvězdička je chybějící odpověď, ne chybějící hop

Traceroute postupuje ven vysíláním sond, jejichž TTL vyprší v každém kole o jeden router dál. Router, který vypršelou sondu zahodí, má vrátit zprávu ICMP Time Exceeded s vlastním jménem, a nástroj to jméno vypíše. Nástroj ve skutečnosti čeká, že ta zpráva dorazí v rámci časového limitu. Pokud router odpoví z jiné zdrojové adresy, omezí, jak často generuje chyby, nebo sondu bez slova zahodí, kolo nevydá nic k vytištění.

Žádný z těchto výsledků neříká, že je dopředná cesta rozbitá. Hvězdička je zpráva o nezodpovězené poště, ne o prázdné cestě.

Metoda sondy rozhoduje, na který filtr narazíte

Výchozí metoda na Linuxu bývá UDP cílový port s vysokým číslem, tracert ve Windows posílá ICMP ozvěny a Linuxu lze nařídit, aby místo toho použil ICMP nebo TCP. Každý z nich vypadá pro stavový firewall nebo cloudovou bezpečnostní skupinu jako jiný druh provozu. Porovnávat UDP trasu z jedné strany s ICMP trasou z druhé znamená porovnávat dva různé pokusy. Zafixujte metodu, rodinu adres, zdrojovou adresu a časový limit, než výsledky nazvete rozdílem.

Pro poctivé srovnání spouštějte trasu z hostitelů, které provoz skutečně nesou, ne z brány, která za ně předává. Trasa vytvořená routerem používá vlastní zdrojovou adresu a výstupní politiku routeru, které mohou být přísnější než cokoli, co vidí klient. Zaznamenejte přesný příkaz, aby ho příští člověk mohl zopakovat.

Hodnota časového limitu je druhá polovina pokusu a v poznámkách snadno chybí. Dvousekundové čekání na přetížené cestě hlásí hvězdičky tam, kde pětisekundové čekání hlásí hop. Udržujte hodnotu stejnou ve všech spuštěních, aby srovnání zůstalo o síti.

Zpětná cesta je vlastní trasa

Chyba ICMP je obyčejný paket s vlastním zdrojem a cílem a potřebuje cestu zpět ke trasovači. Pokud politika tunelu nese prefixy LAN, ale ne adresu routeru, který chybu vytvořil, zpráva odchází cestou, která k vám nedorazí. Filtrování odpovědí ji může zahodit, i když trasa existuje, protože paket přichází z neočekávané adresy na neočekávaném rozhraní. To je nesoulad v diagnostické rovině, ne selhání aplikace.

Rozšiřování každého selektoru, dokud se trasa nedokončí, dělá obrázek hezčím a politiku horší. Opravte konkrétní diagnostickou adresu, nebo hvězdičku přijměte a otestujte aplikaci jinak.

Potvrďte tunel skutečným požadavkem

TCP handshake na vlastním portu služby prověří předávání, zpětný routing i filtrování ve směru, na kterém záleží. Příkazy níže běží na obou koncích a porovnávají, co každá strana dokáže otevřít. Nahraďte port služby a název rozhraní tunelu podle svého nastavení.

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

Nejprve si přečtěte obě spuštění traceroute: pokud ICMP běh ukazuje hop a TCP běh ne, rozdíl je v metodě, ne v cestě. Potom vezměte výsledek curl jako odpověď na úrovni aplikace, protože dokončená výměna s rozumným stavovým kódem znamená, že dopředná i zpětná cesta fungují pro skutečný provoz. Výpis socketů ukazuje, zda je spojení vůbec navázáno, což vám žádná trasa neřekne.

Tunel, který obousměrně nese interaktivní relaci, zatímco jeden traceroute vypisuje hvězdičky, je zdravý a jen nefotogenický. Uchovejte výstup příkazů z každé strany jako záznam a chybějící hopy berte jako otevřenou otázku o diagnostice, ne jako verdikt o VPN.