OpenVPN în spatele stunnel: redirecționează învelișul, nu portul 1194

Pune un înveliș TLS în fața OpenVPN și implementarea câștigă un al doilea ascultător, dintre care doar unul ar trebui să privească vreodată spre internet. Când tunelul funcționează de pe aceeași mașină și eșuează din exterior, redirecționarea este de obicei îndreptată spre cel greșit dintre cele două. Ce trebuie să se alinieze este un lanț: regula publică ajunge la înveliș, iar conexiunea backend proprie a învelișului ajunge la socketul VPN real. Patru salturi poartă acest lanț, iar oricare dintre ele poate încheia investigația devreme.

Două socketuri, doi proprietari, unul public

Învelișul termină TLS pentru conexiunea exterioară și transmite fluxul de octeți decriptat unui ascultător OpenVPN TCP simplu. Acestea sunt socketuri separate cu fișiere de configurare separate, așa că editarea unuia îl lasă pe celălalt neatins și încă aparent sănătos. Înseamnă și că cele două pot diverge oricând unul este schimbat fără celălalt.

Lucrul de pe mașina însăși dovedește deci foarte puțin despre calea publică. O conexiune directă la portul nativ ocolește învelișul, o conexiune la înveliș pe adresa sa LAN ocolește traducerea, iar doar aranjamentul complet din partea clientului exersează ce face un utilizator din exterior. Și numele trebuie citite cu atenție, pentru că localhost înseamnă gazda care rulează exact acea componentă, nu gazda pe care tastezi din întâmplare. Ține această distincție în notițele tale, pentru că un test înregistrat fără saltul pe care l-a acoperit invită la o comparație între două lucruri diferite.

Unde ajunge de fapt redirecționarea

Lanțul este mai ușor de ținut ca patru salturi decât ca trei numere de port, deoarece același număr poate însemna lucruri diferite la fiecare capăt. Citește tabelul rând cu rând: fiecare rând este un socket care trebuie să accepte o conexiune și apoi să o deschidă pe următoarea. Când un rând este îndreptat spre partenerul greșit, simptomul din ultima coloană este ceea ce raportează utilizatorul.

O regulă care țintește portul VPN nativ în locul învelișului omite complet terminarea TLS, iar aceasta este cea mai comună formă a acestei erori: clientul deschide un handshake cu un ascultător care așteaptă încadrarea OpenVPN, așa că conexiunea se poate deschide și apoi bloca. Confirmă portul tradus în fișierul de configurare al învelișului, nu în memorie, pentru că următoarea persoană care editează acel fișier poate a ales alt număr. Cele două comenzi de mai jos arată ambele fețe ale acestei întrebări simultan.

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

Adresa de legare care te refuză

O linie accept legată de 127.0.0.1 răspunde doar gazdei înseși, așa că o redirecționare care sosește pe adresa LAN nu se poate conecta, iar clientul vede un refuz care sună ca o problemă de filtru de pachete. Privește socketul înainte de a atinge firewallul, pentru că socketul este răspunsul mai ieftin. Fie leagă învelișul de interfața către care țintește redirecționarea, fie ține-l pe loopback și fă ca redirecționarea să ajungă la loopback printr-un lucru care chiar funcționează. Acestea sunt două proiecte, iar fiecare are nevoie de propria regulă.

Amestecarea lor este modul în care un înveliș funcțional ajunge inaccesibil din exterior în timp ce fiecare fișier pare corect. Verificarea de mai jos este o singură comandă și răspunde la o întrebare la care o revizuire a regulilor firewallului nu poate. Dacă ieșirea arată o adresă loopback în timp ce redirecționarea țintește adresa LAN, corectarea aparține liniei accept și nu filtrului de pachete.

ss -lntp '( sport = :8443 )'

Ce a dovedit de fapt testul local

Un succes înregistrat fără saltul pe care l-a acoperit nu este dovadă despre celelalte salturi. Notează ce adresă a folosit testul și ce proces a răspuns. Apoi repetă din afara rețelei, nu de pe un telefon în aceeași rețea Wi-Fi, pentru că comportamentul de agrafă variază între routere, iar o conexiune care nu a părăsit niciodată LAN-ul poate satisface un client fără ca redirecționarea să fie deloc implicată. Doar a doua încercare exersează drumul pe care îl face un străin.

Când încercarea eșuează, urmărește o singură conexiune în ambele jurnale: liniile de acceptare și de conectare ale învelișului, apoi jurnalul de sesiune al demonului VPN. Prima graniță care nu înregistrează nimic este locul următoarei modificări. Odată ce OpenVPN compară opțiunile partenerului, judecă acele mesaje după regulile acelei implementări. Un avertisment de inconsistență link-mtu nu este automat fatal, fixarea link-mtu la 1500 nu dovedește că fragmentarea s-a oprit, iar negocierea cifrului aparține configurației interne a OpenVPN și nu redirecționării routerului.

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

Acele sonde acoperă socketul backend și jurnalul învelișului, ceea ce separă un backend refuzat de un handshake respins. Rulează-le în timp ce o singură încercare este în curs și nu după. Marcajele de timp dintr-o singură încercare sunt ceea ce face comparația de încredere.

Două identități, două ordini de eșec

Certificatul exterior aparține învelișului, iar identitatea interioară aparține OpenVPN, și pot veni de la autorități diferite. Dezactivarea oricăreia dintre cele două verificări pentru ca o cale să pară sănătoasă schimbă o protecție reală pe un rezultat cosmetic. Păstrează ambele verificări și depanează-le în ordine, pentru că succesiunea mesajelor numește stratul: o problemă de certificat al învelișului apare înainte de a fi negociată vreo opțiune VPN, în timp ce o defecțiune a identității interioare apare abia după ce fluxul este stabilit.

manualul stunnel definește precis accept, connect și modul client, iar acele secțiuni răspund la întrebarea despre socket mai repede decât ghicitul. Când încă nu poți spune ce strat a răspuns, citește certificatul pe care îl prezintă portul public cu comanda de mai jos. Un certificat al învelișului în ieșire înseamnă că redirecționarea a ajuns la înveliș, iar tăcerea sau o eroare de protocol înseamnă că nu a ajuns. Acea singură distincție economisește mai mult timp decât orice altă verificare de aici.

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