VPN se připojí, ale zařízení v LAN nejsou dostupná: co zkontrolovat

Provoz vstupuje do tunelu, brána odpovídá na vlastní adresu a nic za ní neodpovídá. Tento vzorec je běžný a není to rozpor: odpověď od brány dokazuje, že tunel skončil, a nedokazuje nic o tom, co se děje s paketem adresovaným za ni. Oba testy využívají různé cesty kódu na stejném stroji.

Od teď testujte něco na druhé straně brány. Vlastní adresa brány bude odpovídat dál, ať je přesměrování jakkoli rozbité.

Brána odpovídá ze svého vlastního zásobníku

Paket adresovaný bráně se doručí do její lokální vstupní cesty, kde jádro rozhodne, zda jej přijme naslouchající socket. Paket adresovaný hostiteli za bránou se místo toho doručí do cesty přesměrování, kde platí jiná sada kontrol. Přesměrování lze zcela vypnout, nebo je jádro zapne a pak jej odmítne pravidlo filtru, které tunel vůbec nezmiňuje. Nic z toho neovlivní vlastní odpověď brány, a proto symptom tak spolehlivě mate.

Administrativní stránky dosažené tunelem patří také do první kategorie. Jsou důkazem o tunelu, ne o síti za ním.

Sledujte tok k první hranici, která jej zahodí

Začněte u klienta a potvrďte trasu a zdrojovou adresu, kterou tok použije. Pak na bráně sledujte příchod právě tohoto toku a znovu stejný tok odcházející k LAN. Pokud nikdy nepřijde, problém je na straně klienta nebo v povolených prefixech tunelu. Pokud přijde a nikdy neodejde, problém je v přesměrování nebo ve filtru dopředné cesty, a zachytávání už řeklo, který z nich.

Provádění stejného testu z brány skrývá zajímavou polovinu, protože paket vzniklý na bráně má jiný zdroj a jiný požadavek na návrat. Používejte tok klienta s jeho vlastní zdrojovou adresou v každém kroku. Zachytávání na špatném rozhraní dává sebevědomé nesmysly.

Zpětné trasy a firewally hostitelů selhávají odděleně

Jakmile paket dorazí k hostiteli, musí platit ještě tři věci. Služba musí naslouchat na adrese, na kterou byl paket odeslán, firewall hostitele jej musí přijmout a odpověď musí mít trasu zpět k pulu klientů. Ta poslední často selhává, protože výchozí trasa hostitele ukazuje na router, který o rozsahu tunelu nikdy neslyšel. Výsledkem je spojení, které se z pohledu hostitele naváže a v opačném směru tiše zemře.

Otestujte zpětnou cestu záměrně: odešlete z klienta a sledujte návrat. Jednosměrné zachytávání vyřeší v sekundách to, co hodina spekulací nevyřeší.

Potvrďte každý skok zdrojovou adresou klienta

Proveďte kontroly v pořadí a uchovejte každý výstup, protože hodnota je ve srovnání, ne v jediném řádku. Příkazy níže zafixují zdrojovou adresu, ukážou zvolenou trasu a zachytí obě strany přesměrování. Nahraďte svého hostitele v LAN a rozhraní tunelu.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Dotaz na trasu ukáže, zda by klient tento paket vůbec poslal do tunelu, a ping ukáže, zda se od hostitele něco vrátilo. Porovnání obou zachytávání odděluje příchod od odchodu, protože rámec na rozhraní tunelu bez protějšku na rozhraní LAN je rozhodnutí o přesměrování, ne selhání služby. Když obě zachytávání ukazují požadavek a jen jedno ukazuje odpověď, zbývajícím podezřelým je zpětná trasa.

Zapište, která adresa odpověděla a která přesměrovaná destinace selhala. Tato věta dělá zprávu použitelnou místo tvrzení, že server je nedostupný.