Pripojené k OpenVPN, ale nič sa nenačítava: postup od klienta von

Okno klienta hlási Connected, adresa tunela je tu a prehliadač sa stále točí. Táto kombinácia je normálna, pretože úspešný handshake dokazuje len to, že tunel bol postavený; nehovorí nič o tom, či server bude vaše pakety preposielať, prepisovať ich zdroj alebo odpovedať na vaše DNS otázky. Chyba, ktorú robí väčšina, je otvoriť najprv konfiguráciu servera. Choďte namiesto toho od klienta von, pretože každý krok nižšie vám povie, či má ten ďalší vôbec zmysel kontrolovať.

Začnite na klientovi a choďte von

Urobte tri testy v tomto poradí a zapíšte, kde prvý zlyhá. Pingnite adresu tunela na serveri, čo dokazuje, že tunel sám prenáša prevádzku. Pingnite verejnú adresu podľa čísla, čo dokazuje preposielanie a preklad bez zapojenia prekladu mien. Potom skúste preložiť meno hostiteľa, čo je jediný test, ktorý zamestná DNS. Každý výsledok odoberie celú vrstvu z podozrenia.

Nepreskakujte na tretí test preto, že sa prehliadač zdá rýchlejší. Neúspešné načítanie stránky pokrýva všetky tri vrstvy naraz, a práve tam ľudia začínajú a potom prestavujú tunel, ktorý fungoval. Zlyhávajúca stránka vám nepovie, ktorá z troch vrstiev sa pokazila.

Dva odpočty ukážu, kde sa pakety zastavia

Keď z klienta beží ping na verejnú adresu, urobte jeden odpočet na rozhraní tunela a jeden na uplinku, ktorý má dosiahnuť internet. Spustite oba súčasne, aby časové pečiatky sedeli.

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

Ak sa požiadavky objavia na tuneli a nikdy na uplinku, server ich zahodil medzi tunelom a káblom a príčinou je preposielanie alebo politika firewallu pre preposielanie, nie NAT. Ak sa objavia na oboch, server urobil svoju časť a odpoveď chýba ďalej, čo ukazuje na preklad, filter vyššie alebo obmedzenie zo strany poskytovateľa.

Meno uplinku vezmite z routovacej tabuľky, nie z návodu. Cloudové obrazy a premenované adaptéry sa málokedy zhodujú s ukážkovým rozhraním v príručke a odpočet na nesprávnom zariadení vyzerá presne ako server, ktorý nepreposiela:

ip -4 route get 9.9.9.9

Pole dev v tom výstupe je meno, ktoré bude pravidlo NAT neskôr potrebovať, tak si ho nechajte.

Preposielanie je prepínač v jadre a politika firewallu

Jadro musí vôbec súhlasiť s preposielaním. Prečítajte aktuálnu hodnotu a potom nastavenie urobte trvalým, namiesto toho, aby ste ho zapísali len do bežiaceho jadra:

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

Preposielanie je len polovica. Na hostiteľovi s UFW sa politika preposielania nastavuje v /etc/default/ufw a musí byť ACCEPT, kým sa opätovné načítanie prejaví. Predvolené zahadzovanie na ceste preposielania nechá handshake úplne zdravý, ale ticho zahodí každý paket, ktorý sa pokúsi odísť tunelom, a to je presne ten príznak, s ktorým ste začali.

Hostitelia, ktorí spravujú nftables priamo, majú tú istú otázku v inej syntaxi. Sledujte počítadlá na reťazi preposielania, kým beží test z klienta, pretože reťaz, na ktorú sa dotazuje, a reťaz, ktorá zahadzuje, vyzerajú v konfiguračnom súbore rovnako.

Pomenujte skutočné výstupné rozhranie v pravidle NAT

Preklad zdroja patrí na rozhranie, ktoré hostiteľa skutočne opúšťa, s poolom, ktorý server prideľuje. Obe polovice tohto pravidla musia opisovať realitu a ani jedna nie je voliteľná.

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

Klasické zlyhanie je pravidlo skopírované z príručky, ktoré hovorí -o eth0 na stroji, ktorého adaptér sa volá inak. Pravidlo sa nainštaluje bez varovania, na nič nesedí a klient stále nemá internet. Pool je druhá polovica tej istej chyby: ak server prideľuje 10.44.0.0/24 a pravidlo pokrýva 10.8.0.0/24, nikdy nič nesedí.

Sledujte počítadlá, namiesto toho, aby ste verili textu pravidla. Výpis uvádza pakety na pravidlo a pravidlo, ktoré nikdy nesedí, zostane na nule, nech vyzerá akokoľvek správne. Dajte mu minútu skutočnej prevádzky klienta, kým z toho čísla niečo vyvodíte:

iptables -t nat -L POSTROUTING -v -n

Nulový počet paketov po skutočnom teste z klienta znamená, že zhoda je nesprávna, nie že je tunel pokazený. Keď začne sedieť, uložte sadu pravidiel, aby prežila reštart; oprava, ktorá žije len v histórii vášho shellu, zmizne pri prvom reštarte.

Ak je server aj cloudová inštancia NAT, platforma má tiež slovo. Inštancia, ktorá prekladá adresy, zvyčajne potrebuje vypnutú kontrolu zdroja a cieľa tam, kde poskytovateľ túto možnosť ponúka, a samotný port VPN musí byť dostupný zvonku.

DNS je druhé zlyhanie za prvým

Ping na adresu, ktorý funguje, kým mená zlyhávajú, je problém resolvera, a má svoju vlastnú príčinu. Klient, ktorý si ponechá miestny resolver, posiela tie otázky do plného tunela a čaká na odpoveď, ktorá nikdy nepríde, pretože miestny resolver je teraz na nesprávnej strane trasy.

Pošlite resolver zo servera, aby klient vedel, kde sa pýtať. Dva záznamy dajú klientovi zálohu, ak prvý nie je dostupný, a oba by mali byť resolvery, ktoré tunel skutočne dovoľuje.

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

Klienti Windows potom môžu aj tak spadnúť späť na miestny resolver, a práve tomu má block-outside-dns zabrániť, za cenu straty mien, ktoré dokáže preložiť len miestna sieť. Linuxoví klienti so systemd-resolved často poslaný resolver ignorujú, kým ho nenainštaluje skript, takže pred záverom, že bol push ignorovaný, skontrolujte resolvectl status pre zariadenie tunela.

Dokončite postup tak, ako ho zažíva používateľ. Načítajte z klienta skutočnú stránku, overte adresu, z ktorej vychádza, reštartujte server, pripojte sa znova a zopakujte tri testy. Len tento druhý prechod dokazuje, že uložené pravidlá, politika firewallu aj poslaný resolver prežili všetky spolu.