OpenVPN za stunelem: přeposílejte obal, ne port 1194

Postavte TLS obal před OpenVPN a nasazení získá druhý posluchač, z nichž jen jeden by měl kdy čelit internetu. Když tunel funguje ze stejného stroje a selhává zvenčí, přesměrování obvykle míří na špatný z těch dvou. Co musí ladit, je řetěz: veřejné pravidlo dosáhne obalu a vlastní backendové spojení obalu dosáhne skutečného VPN socketu. Čtyři skoky nesou tento řetěz a kterýkoli z nich může vyšetřování předčasně ukončit.

Dva sockety, dva vlastníci, jeden z nich veřejný

Obal ukončuje TLS pro vnější spojení a předává dešifrovaný bajtový proud obyčejnému OpenVPN TCP posluchači. Jsou to oddělené sockety s oddělenými konfiguračními soubory, takže úprava jednoho nechá druhý nedotčený a stále zdánlivě zdravý. Znamená to také, že se oba mohou rozejít, kdykoli se jeden změní bez druhého.

Práce ze samotného stroje proto dokazuje o veřejné cestě velmi málo. Přímé spojení na nativní port přeskakuje obal, spojení na obal na jeho adrese LAN přeskakuje překlad a jen kompletní uspořádání na straně klienta procvičuje to, co dělá vnější uživatel. Také názvy je třeba číst pozorně, protože localhost znamená hostitele, na kterém běží právě tato komponenta, a ne hostitele, na kterém zrovna píšete. Držte tento rozdíl ve svých poznámkách, protože test zaznamenaný bez skoku, který pokrýval, vybízí k porovnání dvou různých věcí.

Kam přesměrování skutečně dopadá

Řetěz je snazší držet jako čtyři skoky než jako tři čísla portů, protože stejné číslo může na každém konci znamenat něco jiného. Čtěte tabulku řádek po řádku: každý řádek je jeden socket, který musí přijmout spojení a pak otevřít další. Když řádek míří na špatného protějška, symptom v posledním sloupci je to, co hlásí uživatel.

Pravidlo, které míří na nativní VPN port místo na obal, úplně přeskakuje ukončení TLS, což je nejběžnější podoba této chyby: klient otevře handshake s posluchačem, který očekává OpenVPN rámování, takže spojení se může otevřít a pak se zaseknout. Ověřte přeložený port proti konfiguračnímu souboru obalu, ne proti paměti, protože další člověk, který bude tento soubor upravovat, mohl zvolit jiné číslo. Dva příkazy níže ukazují obě strany této otázky najednou.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Adresa navázání, která vás odmítá

Řádek accept svázaný s 127.0.0.1 odpovídá jen samotnému hostiteli, takže přesměrování přicházející na adresu LAN se nemůže připojit a klient vidí odmítnutí, které zní jako problém paketového filtru. Podívejte se na socket dřív, než sáhnete na firewall, protože socket je levnější odpověď. Buď obal svažte s rozhraním, na které přesměrování míří, nebo ho ponechte na loopbacku a zařiďte, aby přesměrování dosáhlo loopbacku přes něco, co skutečně funguje. To jsou dva návrhy a každý potřebuje své vlastní pravidlo.

Míchání obojího je způsob, jak se funkční obal stane zvenčí nedostupným, zatímco každý soubor vypadá správně. Kontrola níže je jeden příkaz a odpovídá na otázku, na kterou revize pravidel firewallu nedokáže. Pokud výstup ukazuje adresu loopback, zatímco přesměrování míří na adresu LAN, oprava patří do řádku accept, a ne do paketového filtru.

ss -lntp '( sport = :8443 )'

Co lokální test skutečně prokázal

Úspěch zaznamenaný bez skoku, který pokrýval, není důkazem o ostatních skocích. Poznamenejte si, kterou adresu test použil a který proces odpověděl. Potom to zopakujte mimo síť, a ne z telefonu na stejné Wi-Fi, protože chování vlásenky se mezi routery liší a spojení, které nikdy neopustilo LAN, může uspokojit klienta, aniž by se přesměrování vůbec účastnilo. Jen ten druhý pokus procvičuje cestu, kterou absolvuje cizí člověk.

Když pokus selže, sledujte jedno spojení oběma logy: řádky přijetí a připojení obalu, potom vlastní log relace VPN démona. První hranice, která nic nezaznamená, je místem další změny. Když OpenVPN začne porovnávat volby protějšku, posuzujte ty zprávy podle pravidel této implementace. Varování o nekonzistenci link-mtu není automaticky fatální, připnutí link-mtu na 1500 neprokazuje, že fragmentace ustala, a vyjednávání šifry patří do vnitřní konfigurace OpenVPN, ne do přesměrování routeru.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Tyto sondy pokrývají backendový socket a log obalu, což odděluje odmítnutý backend od odmítnutého handshake. Spouštějte je, dokud je jeden pokus v běhu, ne potom. Časová razítka z jednoho pokusu jsou to, co činí srovnání důvěryhodným.

Dvě identity, dvě pořadí selhání

Vnější certifikát patří obalu a vnitřní identita OpenVPN a mohou pocházet od různých autorit. Vypnutí kterékoli z kontrol, aby cesta vypadala zdravě, vyměňuje skutečnou ochranu za kosmetický výsledek. Zachovejte obě ověření a laďte je v pořadí, protože sled zpráv pojmenovává vrstvu: problém s certifikátem obalu se objeví před vyjednáním jakékoli volby VPN, zatímco selhání vnitřní identity se objeví až po navázání proudu.

Příručka stunnel přesně definuje accept, connect a klientský režim a tyto kapitoly odpovídají na otázku socketu rychleji než hádání. Když stále nemůžete říct, která vrstva odpověděla, přečtěte certifikát, který veřejný port předkládá, příkazem níže. Certifikát obalu na výstupu znamená, že přesměrování dosáhlo obalu, a ticho nebo chyba protokolu znamená, že ne. Tento jediný rozdíl ušetří více času než kterákoli jiná kontrola zde.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer