VPN sa pripojí, ale zariadenia v LAN nie sú dostupné: čo skontrolovať

Prevádzka vstupuje do tunela, brána odpovedá na vlastnú adresu a nič za ňou neodpovedá. Tento vzor je bežný a nie je to rozpor: odpoveď od brány dokazuje, že tunel sa skončil, a nedokazuje nič o tom, čo sa deje s paketom adresovaným za ňu. Oba testy využívajú rôzne cesty kódu na tom istom stroji.

Odteraz testujte niečo na druhej strane brány. Vlastná adresa brány bude odpovedať ďalej, nech je presmerovanie akokoľvek pokazené.

Brána odpovedá zo svojho vlastného zásobníka

Paket adresovaný bráne sa doručí do jej lokálnej vstupnej cesty, kde jadro rozhodne, či ho prijme počúvajúci socket. Paket adresovaný hostiteľovi za bránou sa namiesto toho doručí do cesty presmerovania, kde platí iná sada kontrol. Presmerovanie možno úplne vypnúť, alebo ho jadro zapne a potom ho odmietne pravidlo filtra, ktoré tunel vôbec nespomína. Nič z toho neovplyvní vlastnú odpoveď brány, a preto symptóm tak spoľahlivo zavádza.

Administratívne stránky dosiahnuté tunelom patria tiež do prvej kategórie. Sú dôkazom o tuneli, nie o sieti za ním.

Sledujte tok k prvej hranici, ktorá ho zahodí

Začnite u klienta a potvrďte trasu a zdrojovú adresu, ktorú tok použije. Potom na bráne sledujte príchod práve tohto toku a znova ten istý tok odchádzajúci k LAN. Ak nikdy nepríde, problém je na strane klienta alebo v povolených prefixoch tunela. Ak príde a nikdy neodíde, problém je v presmerovaní alebo vo filtri doprednej cesty, a záznam už povedal, ktorý z nich.

Vykonanie toho istého testu z brány skrýva zaujímavú polovicu, pretože paket vzniknutý na bráne má iný zdroj a inú požiadavku na návrat. V každom kroku používajte tok klienta s jeho vlastnou zdrojovou adresou. Záznam urobený na nesprávnom rozhraní dáva sebavedomé nezmysly.

Spätné trasy a firewally hostiteľov zlyhávajú oddelene

Keď paket dorazí k hostiteľovi, musia platiť ešte tri veci. Služba musí počúvať na adrese, na ktorú bol paket odoslaný, firewall hostiteľa ho musí prijať, a odpoveď musí mať trasu späť k fondu klientov. Posledná často zlyháva, pretože predvolená trasa hostiteľa ukazuje na router, ktorý o rozsahu tunela nikdy nepočul. Výsledkom je spojenie, ktoré sa nadviaže z pohľadu hostiteľa a v opačnom smere ticho zomrie.

Otestujte spätnú cestu zámerne: odošlite z klienta a sledujte návrat. Jednosmerný záznam vyrieši v sekundách to, čo hodina špekulácií nevyrieši.

Potvrďte každý skok zdrojovou adresou klienta

Vykonajte kontroly v poradí a uchovajte každý výstup, pretože hodnota je v porovnaní, nie v jedinom riadku. Príkazy nižšie zafixujú zdrojovú adresu, ukážu zvolenú trasu a zachytia obe strany presmerovania. Nahraďte svojho hostiteľa v LAN a rozhranie tunela.

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, či by klient tento paket vôbec poslal do tunela, a ping ukáže, či sa od hostiteľa niečo vrátilo. Porovnanie oboch záznamov oddeľuje príchod od odchodu, pretože rámec na rozhraní tunela bez náprotivku na rozhraní LAN je rozhodnutie o presmerovaní, nie zlyhanie služby. Keď oba záznamy ukazujú požiadavku a iba jeden ukazuje odpoveď, zostávajúcim podozrivým je spätná trasa.

Zapíšte, ktorá adresa odpovedala a ktorá presmerovaná destinácia zlyhala. Tá veta robí správu použiteľnou namiesto tvrdenia, že server je nedostupný.