OpenVPN za stunnelom: preposielajte obal, nie port 1194

Postavte TLS obal pred OpenVPN a nasadenie získa druhý poslucháč, z ktorých iba jeden by mal niekedy čeliť internetu. Keď tunel funguje z toho istého stroja a zlyháva zvonku, presmerovanie zvyčajne mieri na nesprávny z tých dvoch. Zhodovať sa musí reťaz: verejné pravidlo dosiahne obal a vlastné backendové spojenie obalu dosiahne skutočný VPN socket. Štyri skoky nesú tento reťaz a ktorýkoľvek z nich môže vyšetrovanie ukončiť predčasne.

Dva sockety, dvaja vlastníci, jeden verejný

Obal ukončuje TLS pre vonkajšie spojenie a odovzdáva dešifrovaný bajtový tok obyčajnému OpenVPN TCP poslucháču. Sú to oddelené sockety s oddelenými konfiguračnými súbormi, takže úprava jedného nechá druhý nedotknutý a stále zdanlivo zdravý. Znamená to aj to, že sa oba môžu rozísť, kedykoľvek sa jeden zmení bez druhého.

Práca zo samotného stroja preto dokazuje o verejnej ceste veľmi málo. Priame spojenie na natívny port obal preskočí, spojenie na obal na jeho adrese LAN preskočí preklad a iba kompletné usporiadanie na strane klienta precvičuje to, čo robí vonkajší používateľ. Aj mená treba čítať pozorne, pretože localhost znamená hostiteľa, na ktorom beží práve tento komponent, a nie hostiteľa, na ktorom práve píšete. Držte tento rozdiel vo svojich poznámkach, pretože test zaznamenaný bez skoku, ktorý pokrýval, vyzýva na porovnanie dvoch rôznych vecí.

Kam presmerovanie skutočne dopadá

Reťaz je ľahšie držať ako štyri skoky než ako tri čísla portov, pretože to isté číslo môže na každom konci znamenať niečo iné. Čítajte tabuľku riadok po riadku: každý riadok je jeden socket, ktorý musí prijať spojenie a potom otvoriť ďalšie. Keď riadok mieri na nesprávneho partnera, príznak v poslednom stĺpci je to, čo používateľ hlási.

Pravidlo, ktoré mieri na natívny port VPN namiesto obalu, úplne preskočí ukončenie TLS, a to je najčastejšia podoba tejto chyby: klient otvorí handshake s poslucháčom, ktorý očakáva OpenVPN rámovanie, takže spojenie sa môže otvoriť a potom zaseknúť. Overte preložený port proti konfiguračnému súboru obalu, nie proti pamäti, pretože ďalší človek, ktorý bude ten súbor upravovať, si mohol vybrať iné číslo. Dva príkazy nižšie ukazujú obe strany tejto otázky naraz.

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

Adresa naviazania, ktorá vás odmieta

Riadok accept naviazaný na 127.0.0.1 odpovedá len samotnému hostiteľovi, takže presmerovanie prichádzajúce na adresu LAN sa nemôže pripojiť a klient vidí odmietnutie, ktoré znie ako problém paketového filtra. Pozrite sa na socket skôr, než sa dotknete firewallu, pretože socket je lacnejšia odpoveď. Buď naviažte obal na rozhranie, na ktoré presmerovanie mieri, alebo ho ponechajte na loopbacku a zabezpečte, aby presmerovanie dosiahlo loopback cez niečo, čo naozaj funguje. To sú dva návrhy a každý potrebuje svoje vlastné pravidlo.

Ich miešanie je spôsob, akým sa funkčný obal stane zvonku nedostupným, zatiaľ čo každý súbor vyzerá správne. Kontrola nižšie je jeden príkaz a odpovedá na otázku, na ktorú revízia pravidiel firewallu nedokáže. Ak výstup ukazuje adresu loopback, zatiaľ čo presmerovanie mieri na adresu LAN, oprava patrí do riadku accept a nie do paketového filtra.

ss -lntp '( sport = :8443 )'

Čo lokálny test skutočne dokázal

Úspech zaznamenaný bez skoku, ktorý pokrýval, nie je dôkazom o ostatných skokoch. Poznamenajte si, ktorú adresu test použil a ktorý proces odpovedal. Potom to zopakujte mimo siete, a nie z telefónu v tej istej Wi-Fi, pretože správanie vlásenky sa medzi routermi líši a spojenie, ktoré nikdy neopustilo LAN, môže uspokojiť klienta bez toho, aby sa presmerovanie vôbec zúčastnilo. Iba ten druhý pokus precvičuje cestu, ktorou ide cudzí človek.

Keď pokus zlyhá, sledujte jedno spojenie v oboch logoch: riadky prijatia a pripojenia obalu, potom vlastný log relácie VPN démona. Prvá hranica, ktorá nič nezaznamená, je miesto ďalšej zmeny. Keď OpenVPN začne porovnávať voľby partnera, posudzujte tie správy podľa pravidiel tej implementácie. Varovanie o nekonzistencii link-mtu nie je automaticky fatálne, pripnutie link-mtu na 1500 nepreukazuje, že fragmentácia ustala, a vyjednávanie šifry patrí do vnútornej konfigurácie OpenVPN, nie do presmerovania routera.

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

Tie sondy pokrývajú backendový socket a log obalu, čo oddeľuje odmietnutý backend od odmietnutého handshake. Spúšťajte ich, kým je jeden pokus v behu, a nie potom. Práve časové značky z jedného pokusu robia porovnanie dôveryhodným.

Dve identity, dve poradia zlyhania

Vonkajší certifikát patrí obalu a vnútorná identita patrí OpenVPN, a môžu pochádzať od rôznych autorít. Vypnutie ktorejkoľvek z dvoch kontrol, aby cesta vyzerala zdravo, vymieňa skutočnú ochranu za kozmetický výsledok. Zachovajte obe overenia a ladte ich v poradí, pretože sled správ pomenúva vrstvu: problém s certifikátom obalu sa objaví pred vyjednaním akejkoľvek voľby VPN, zatiaľ čo zlyhanie vnútornej identity sa objaví až po vytvorení toku.

príručka stunnel presne definuje accept, connect a klientsky režim a tieto kapitoly odpovedajú na otázku socketu rýchlejšie než hádanie. Keď stále neviete povedať, ktorá vrstva odpovedala, prečítajte certifikát, ktorý predkladá verejný port, príkazom nižšie. Certifikát obalu vo výstupe znamená, že presmerovanie dosiahlo obal, a ticho alebo chyba protokolu znamená, že nie. Ten jediný rozdiel ušetrí viac času než ktorákoľvek iná kontrola tu.

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