VPN klienti se připojí, ale internet nefunguje: tři chybějící díly

Klient dostane adresu, server odpovídá na ping a každá stránka přesto vyprší. Většina lidí v tomto bodě začne upravovat profil klienta, což je obvykle zbytečná práce: jakmile tunel stojí, server se musí chovat jako router. Tři podmínky musí platit současně, než paket odejde a vrátí se odpověď, a příznak je stejný, ať chybí kterákoli z nich.

Proč funkční tunel stále nemá cestu ven

Jádro musí předávat pakety mezi rozhraními, což je u většiny distribucí Linuxu ve výchozím stavu vypnuté. Provoz musí být přeložen na adresu, na kterou dokáže vnější svět odpovědět, pokud každý nadřazený router už nezná zpáteční cestu do podsítě tunelu. Forwardovací cesta firewallu musí propouštět provoz oběma směry, včetně odpovědí.

Každou z nich lze opravit samostatně, a v tom je past. Zapnutí forwardingu bez pravidla překladu nechá pakety odcházet se soukromým zdrojem a bez zpáteční cesty. Přidání překladu bez forwardovacího pravidla nechá jádro paket zahodit o krok později.

Proto testujte tři vrstvy místo klienta a měňte po jedné, aby výsledek něco znamenal.

Forwarding je přepínač jádra, který musíte trvale nastavit

Před změnou zkontrolujte aktuální hodnotu, pak ji nastavte a potvrďte, že změna nabyla účinku.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

První příkaz hlásí aktuální hodnotu, druhý ji nastaví za běhu a třetí dokazuje, že zápis prošel. Hodnota za běhu zmizí při dalším restartu, a proto se funkční sezení může po údržbě rozbít bez jakékoli změny konfigurace.

Nastavte ji trvale v souboru pod /etc/sysctl.d/ a pak tento soubor aplikujte, místo abyste restartovali, abyste to zjistili. Na FreeBSD je ekvivalentem net.inet.ip.forwarding, pro trvalost gateway_enable=YES v rc.conf. Zařízení, které hlásí vypnutý forwarding, vysvětluje celou třídu hlášení „pakety dorazí a nic se nevrátí“. Nastavení kontrolujte i po každé aktualizaci, protože přestavěné jádro nebo vyměněný obraz zařízení jej mohou resetovat, aniž by to někomu řekly.

Zvolte masquerade, nebo jednu pevnou překladovou adresu

S dynamickou vnější adresou je masquerading nejjednodušší správná forma. Jako zdroj uveďte podsíť tunelu a jako výstup vnější rozhraní.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Se statickou veřejnou adresou je překlad zdroje na přesně tuto adresu předvídatelnější a snáze auditovatelný.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Druhá forma nese past údržby: pevně zapsaná adresa, která se později změní, drží tunel funkční, zatímco přístup k internetu tiše přestane. Buď použijte masquerade, nebo pravidlo aktualizujte, kdykoli vás poskytovatel přesune. Rozhraní je také důležité, protože router, který sdílí svůj vlastní nadřazený tunel, musí překládat přes tento tunel, ne přes fyzický WAN.

Filtrovací tabulka je třetí branou

Forwarding i překlad mohou být správné, a paket přesto umírá ve filtrovací tabulce. ufw je častý viník: jeho forwardovací politika se dodává jako DROP a zbytek nastavení může vypadat naprosto správně, zatímco to jedno nastavení zabíjí provoz. Zvednout ji je vědomé bezpečnostní rozhodnutí, ne zaškrtávací políčko.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

První pravidlo povoluje nový provoz z tunelu ven, druhé jen odpovědi zpět. Zúžte obě na podsíť tunelu a zamýšlený cíl, protože plošné povolení na rozhraní tunelu mění VPN v otevřený výstupní bod pro každého, kdo se umí autentizovat.

Přemostěný tunel potřebuje jinou odpověď. Adresa patří mostu, ne fyzickému portu, takže podřízení rozhraní mostu odebere adresu, kterou dříve mělo, a hostitel vypadá nedostupný, dokud samotný most nedostane adresu, což může dodat dhclient br0. Ta porucha vypadá jako problém VPN a je to problém druhé vrstvy. Zkontrolujte vlastní adresu mostu, než sáhnete na firewall, protože změna filtru neopraví hostitele, který už nemá adresu, ze které by odesílal.

Kam se dívat, když se stránka nikdy nenačte

Pingněte adresu tunelu serveru, abyste dokázali, že tunel existuje. Pak spusťte traceroute z klienta na veřejnou adresu a čtěte, kde se zastaví: na serveru paket dorazí, ale není předán ani přeložen; za serverem je problém výš a mimo vaše ruce.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

První příkaz dokazuje, že tunel nese provoz k samotnému serveru, a druhý ukazuje, jak daleko se paket dostane ven. Trasa, která končí na adrese tunelu, ukazuje na forwarding nebo překlad na serveru, zatímco trasa, která se zastaví o jeden skok dál, ukazuje na poskytovatele nebo zpáteční cestu nadřazeného routeru.

Na serveru sledujte vnější rozhraní, zatímco klient načítá stránku. Provoz odcházející se soukromou zdrojovou adresou znamená, že chybí překlad, a úplná absence odpovědi znamená, že jej zahazuje forwardovací cesta nebo nadřazená zpáteční trasa.

Pokud se vzdálení klienti musí dostat i na hostitele v LAN serveru, pamatujte, že LAN potřebuje zpáteční trasu do podsítě tunelu. To je směrování, ne překlad, a je to krok, na který se nejčastěji zapomíná, když cesta do internetu konečně funguje.