Připojeno k OpenVPN, ale nic se nenačítá: postup od klienta

Okno klienta hlásí Connected, adresa tunelu je na místě a prohlížeč se pořád točí. Tahle kombinace je normální, protože úspěšný handshake dokazuje jen to, že tunel byl postaven; neříká nic o tom, jestli server bude vaše pakety předávat, přepisovat jejich zdroj nebo odpovídat na vaše DNS dotazy. Většina lidí dělá chybu, že nejdřív otevře konfiguraci serveru. Jděte místo toho od klienta ven, protože každý krok níž vám řekne, jestli má ten další vůbec cenu kontrolovat.

Začněte na klientovi a jděte ven

Proveďte tři testy v tomto pořadí a zapište si, kde první selže. Pingněte adresu tunelu na serveru, což dokazuje, že tunel sám přenáší provoz. Pingněte veřejnou adresu podle čísla, což dokazuje předávání a překlad bez zapojení překladu jmen. Pak zkuste přeložit jméno hostitele, což je jediný test, který zaměstná DNS. Každý výsledek odebere celou vrstvu z podezření.

Nepřeskakujte na třetí test proto, že se prohlížeč zdá rychlejší. Neúspěšné načtení stránky pokrývá všechny tři vrstvy najednou, a právě tam lidé začínají a pak přestavují tunel, který fungoval. Selhávající stránka vám neřekne, která ze tří vrstev se rozbila.

Dva odposlechy ukážou, kde se pakety zastaví

Když z klienta běží ping na veřejnou adresu, pořiďte jeden odposlech na rozhraní tunelu a jeden na uplinku, který má dosáhnout internetu. Spusťte oba současně, aby časová razítka seděla.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Pokud se požadavky objeví na tunelu a nikdy na uplinku, server je zahodil mezi tunelem a kabelem a příčinou je předávání nebo politika firewallu pro předávání, ne NAT. Pokud se objeví na obou, server udělal svou část a odpověď chybí dál, což ukazuje na překlad, filtr výš nebo omezení ze strany poskytovatele.

Jméno uplinku vezměte z routovací tabulky, ne z návodu. Cloudové obrazy a přejmenované adaptéry se málokdy shodují s ukázkovým rozhraním v příručce a odposlech na špatném zařízení vypadá přesně jako server, který nepředává:

ip -4 route get 9.9.9.9

Pole dev v tomto výstupu je jméno, které bude pravidlo NAT později potřebovat, tak si ho nechte.

Předávání je přepínač v jádru a politika firewallu

Jádro musí vůbec souhlasit s předáváním. Přečtěte aktuální hodnotu a pak nastavení udělejte trvalým, místo abyste ho zapsali jen do běžícího jádra:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Předávání je jen polovina. Na hostiteli s UFW se politika předávání nastavuje v /etc/default/ufw a musí být ACCEPT, než se znovunačtení projeví. Výchozí zahazování na cestě předávání nechá handshake naprosto zdravý, ale tiše zahodí každý paket, který se pokusí odejít tunelem, což je přesně ten příznak, se kterým jste začali.

Hostitelé, kteří spravují nftables přímo, mají stejnou otázku v jiné syntaxi. Sledujte čítače na řetězu předávání, dokud běží test z klienta, protože řetěz, na který se dotazuje, a řetěz, který zahazuje, vypadají v konfiguračním souboru stejně.

Pojmenujte skutečné výstupní rozhraní v pravidle NAT

Překlad zdroje patří na rozhraní, které hostitele skutečně opouští, s poolem, který server přiděluje. Obě poloviny tohoto pravidla musí popisovat realitu a ani jedna není volitelná.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Klasické selhání je pravidlo zkopírované z příručky, které říká -o eth0 na stroji, jehož adaptér se jmenuje jinak. Pravidlo se nainstaluje bez varování, na nic nesedí a klient pořád nemá internet. Pool je druhá polovina téže chyby: pokud server přiděluje 10.44.0.0/24 a pravidlo pokrývá 10.8.0.0/24, nikdy nic nesedne.

Sledujte čítače, místo abyste věřili textu pravidla. Výpis uvádí pakety na pravidlo a pravidlo, které nikdy nesedne, zůstane na nule, ať vypadá sebekorektněji. Dejte mu minutu skutečného provozu klienta, než z toho čísla cokoli vyvodíte:

iptables -t nat -L POSTROUTING -v -n

Nulový počet paketů po skutečném testu z klienta znamená, že shoda je špatná, ne že je tunel rozbitý. Jakmile sedne, uložte sadu pravidel, aby přežila restart; oprava, která žije jen v historii shellu, zmizí při prvním restartu.

Pokud je server také cloudová instance NAT, platforma má také slovo. Instance, která překládá adresy, obvykle potřebuje vypnutou kontrolu zdroje a cíle tam, kde poskytovatel toto nastavení nabízí, a samotný port VPN musí být dostupný zvenčí.

DNS je druhé selhání za prvním

Ping na adresu, který funguje, zatímco jména selhávají, je problém resolveru, a má svou vlastní příčinu. Klient, který si ponechá místní resolver, posílá ty dotazy do plného tunelu a čeká na odpověď, která nikdy nepřijde, protože místní resolver je teď na špatné straně trasy.

Pošlete resolver ze serveru, aby klient věděl, kde se ptát. Dva záznamy dají klientovi zálohu, pokud první není dostupný, a oba by měly být resolvery, které tunel skutečně dovoluje.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Klienti Windows pak mohou stejně spadnout zpět na místní resolver, což je přesně to, čemu block-outside-dns existuje zabránit, za cenu ztráty jmen, která umí přeložit jen místní síť. Linuxoví klienti se systemd-resolved často poslaný resolver ignorují, dokud ho nenainstaluje skript, takže před závěrem, že byl push ignorován, zkontrolujte resolvectl status pro zařízení tunelu.

Dokončete postup tak, jak ho zažívá uživatel. Načtěte z klienta skutečnou stránku, ověřte adresu, ze které vychází, restartujte server, připojte se znovu a zopakujte tři testy. Jen tento druhý průchod dokazuje, že uložená pravidla, politika firewallu i poslaný resolver přežily všechny společně.