Tunel je postavený, brány si navzájem odpovídají, a uživatelé na jedné lokalitě přesto nemohou otevřít sdílenou složku na druhé. Někdo pingne z brány, dostane odpověď a prohlásí síť za zdravou. Ta odpověď putovala mezi dvěma zařízeními, která nikdy nebyla problémem. Užitečný test začíná na hostiteli, který službu potřebuje, používá protokol, který používá aplikace, a zopakuje podmínku, za níž selhává. Všechno ostatní je zelená pro cestu, po které nikdo nejde.

Začněte u klienta, který službu potřebuje

Před jakýmkoli testem si zapište čtyři věci: adresu klienta, cílovou adresu, název hostitele a port aplikace. Pak potvrďte, že služba funguje lokálně na své vlastní lokalitě, z hostitele vedle ní. Bez této základní linie nerozlišíte rozbitý tunel od rozbité služby a polovina těchto požadavků je ta druhá.

Vyzkoušejte dokumentovaný název hostitele a tam, kde to služba dovolí, kontrolu přímé adresy stejného portu. Neúspěšné hledání názvu a nedostupná přeložená adresa vás vedou různými cestami. Pokud nahradíte název hostitele IP adresou, nevypínejte kontrolu identity HTTPS, aby to fungovalo; varování o certifikátu je informace, ne překážka.

Projděte cestu na každém okraji

Přečtěte trasu, kterou volí klient, pak trasu, kterou pro tento cíl volí brána, pak čítače nebo omezené zachycení na každém okraji. Hledáte dvě skutečnosti: dorazil požadavek na vzdálenou LAN a vrátila se odpověď. Čítače rozhraní zahrnují každý další tok, proto korelejte podle přesného času a dvojice adres, ne podle tvaru grafu. Zachycení na špatném okraji je horší než žádné, protože vypadá jako důkaz.

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

Pokud se požadavek objeví na vzdáleném okraji bez odpovědi za ním, problém je na druhé straně: firewall, chybějící zpětná trasa nebo hostitel, který nepřijímá zdroj. Pokud se požadavek neobjeví vůbec, lokální trasa nebo selektory tunelu ho nepřenesly a druhá strana ještě nestojí za vyšetřování.

Použijte protokol, který používá aplikace

ICMP je slabá sonda. Může být filtrován, omezen rychlostí nebo zpracován jinou politikou než služba, což činí nejednoznačným jak jeho úspěch, tak jeho selhání. Testujte skutečný port a, kde můžete, skutečné protokolové handshake.

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

Dokončený TCP handshake dokazuje dosažitelnost a politiku pro tento port. Nedokazuje, že aplikace funguje: autentizace, nahrání nebo konkrétní volání API může stále selhat. Testujte operaci, kterou uživatelé skutečně provádějí, pomocí neškodného ekvivalentu místo opakovaného odesílání skutečné transakce.

Zopakujte podmínku, za níž selhává

Selhání, která se objevují jen u velkých přenosů, jsou problém velikosti, ne konektivity. Pošlete velký paket s nastaveným bitem don't-fragment a sledujte, kde se zastaví. Pokud malý požadavek uspěje a velký visí, MTU tunelu a zpracování MSS na bránách jsou další podezřelí.

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

Pokud selhává jen jedna podsíť, podívejte se na selektory provozu, inzeráty tras a návratovou bránu této podsítě. Pokud selhává jen název hostitele, sledujte DNS, včetně toho, který resolver klient použil a zda je vzdálený pohled z této lokality viditelný. Tři různé poruchy, tři různé opravy a ping test nerozliší ani jednu z nich.

Po opravě zopakujte stejný test

Spusťte znovu stejného klienta, cíl, port i obsah. Potom se znovu připojte nebo vyzkoušejte cestu přepnutí, pokud ji návrh má, protože oprava, která funguje jen dokud je původní instance tunelu živá, nebyla otestována. Držte test svázaný se skutečným zdrojem, skutečným cílem a skutečnou operací, ne s jedním zeleným indikátorem na panelu.

Zaznamenejte čtyři základní hodnoty a výsledek. Příští zpráva o stejném symptomu pak může začít od důkazů, ne od pingu.

Související články