OpenVPN și HTTPS pe portul 443: al cui este listenerul?
TCP și UDP 443 sunt socketuri separate. Partajarea unui singur listener TCP cere un proprietar, iar partajarea portului OpenVPN este o înțelegere îngustă, nu un truc de proxy.
Două servicii pot răspunde amândouă pe portul 443 fără să concureze vreodată, pentru că un listener este determinat de transport, adresă și port împreună, nu doar de număr. Pune un server web și OpenVPN pe aceeași mașină, iar singura întrebare care merită un răspuns mai întâi este ce socket cere fiecare proces nucleului. Notează acea listă înainte de a edita o configurație, iar majoritatea erorilor „adresa este deja folosită” se explică singure. Tot ce urmează listei este o alegere între un listener UDP, un socket TCP partajat sau un front-end care rutează după protocol.
Începe cu socketul pe care îl cere fiecare proces
Un bind reușește sau eșuează pe acel triplu, așa că două daemon-uri se ciocnesc doar când toate trei părțile coincid. De aceea un site pe TCP 443 coexistă nelimitat cu un listener OpenVPN pe UDP 443, și de aceea mutarea unuia dintre ele pe o a doua adresă locală pe același host încheie și ea discuția. Citește listenerii activi, nu fișierele care ar fi trebuit să-i creeze, pentru că un include învechit sau un fișier unit uitat supraviețuiește editării pe care îți amintești că ai făcut-o.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Rulează ss -lntup ca root și citește fiecare linie care menționează 443, inclusiv intrările IPv6. Un listener v6 wildcard acceptă de obicei și trafic v4, și astfel un listener uitat ține portul ocupat după ce schimbi fișierul pe care îl credeai responsabil. Dacă un nume de proces te surprinde, restrânge ieșirea cu ss -lntup 'sport = :443' înainte de a atinge ceva.
Treci tunelul pe UDP când rețeaua permite
Un listener UDP ocolește complet coliziunea și este de obicei cea mai scurtă reparație, fiindcă nu se partajează niciun socket și niciun produs suplimentar nu intră pe cale. Dar nu este gratuit. Unele rețele de clienți aruncă UDP 443 fără să trimită un reset, așa că tunelul încetează să se stabilească în loc să eșueze la bind, iar utilizatorul raportează că VPN-ul este căzut fără nicio eroare de citit. Un listener UDP supraviețuiește și unei reporniri a stratului web, ceea ce contează pe o mașină al cărei site este reimplementat des. Testează din rețeaua în care stau utilizatorii, pentru că un shell pe server dovedește doar că serverul se atinge pe sine.
Schimbă transportul în configurația serverului și în profilul clientului simultan. Un profil care cere încă TCP va intra în bucle de reconectare împotriva unui listener doar UDP, iar asta arată ca o defecțiune de rețea până când compari cele două fișiere.
Lasă procesul VPN să dețină TCP 443 și transmite restul
Community OpenVPN în modul server TCP citește primii octeți ai unei conexiuni de intrare și transmite tot ce nu este propriul său protocol către un backend HTTPS, iar pentru asta există directiva port-share. Backendul este un server web obișnuit cu TLS activat, numit prin host și port în acea directivă, nu printr-un URL.
port-share 10.0.0.5 8080
Pe o mașină unde site-ul are o a doua adresă privată, acea linie trimite traficul non-VPN către 10.0.0.5:8080, așa că gazda virtuală HTTPS trebuie să fie legată acolo, iar firewallul trebuie să permită saltul local. Serverul web trebuie să încheie singur TLS, pentru că octeții care sosesc sunt handshake-ul original al browserului și nimic pe drum nu i-a decriptat. Îndreaptă directiva către un listener HTTP simplu și browserul primește o eroare de metodă invalidă, care se citește ca un site stricat și nu ca un backend plasat greșit. Directiva există doar în modul server TCP, iar un listener UDP nu are niciun flux de inspectat.
Fiindcă procesul VPN acceptă fiecare conexiune, aplicația web vede cererea transmisă sosind dintr-una din adresele proprii ale gazdei în loc de la vizitator. Tot ce are nevoie de adresa reală a clientului depinde de suportul protocolului PROXY în backend sau de un front-end care îl adaugă. Mutarea backendului pe altă adresă locală nu readuce adresa vizitatorului; schimbă doar care dintre adresele gazdei este înregistrată de site. Notează această limitare în notele de implementare înainte ca un raport de analiză să ridice întrebarea.
Un proxy invers este instrumentul greșit; un router de strat patru nu
Un proxy invers HTTP încheie TLS ca să poată citi cererile, ceea ce înseamnă că nu poate lăsa un flux OpenVPN să treacă neatins. Un router de strat patru care transmite după SNI sau după inspecția primului pachet poate sta în fața ambelor, cu condiția să nu încheie sesiunea de care depinde VPN-ul. Cele două dispozitive arată la fel într-o diagramă și se comportă complet diferit la socket.
Access Server-ul comercial vine cu propriile setări de partajare a portului, iar acestea nu corespund unu-la-unu directivei comunității. Identifică produsul și versiunea înainte de a adapta un ghid scris pentru celălalt. O setare copiată și ignorată în tăcere este mai rea decât nicio setare, pentru că lista listenerilor arată în continuare plauzibil după aceea.
Testează site-ul și tunelul ca două căi separate
Încarcă site-ul și conectează tunelul, apoi citește din nou lista listenerilor ca să vezi ce proces deține 443 acum. O pagină care se încarcă nu dovedește nimic despre VPN, iar un tunel care se conectează nu dovedește nimic despre site, deși ambele folosesc același număr. Cele trei comenzi de mai jos verifică socketul partajat, calea web și serviciul VPN în această ordine.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Compară adresa clientului din jurnalul de acces al backendului cu cea din jurnalul VPN pentru același moment. Dacă site-ul înregistrează fiecare vizitator ca gazda însăși, transmiterea funcționează, iar tratarea adresei nu. Dacă ambele jurnale tac, front-end-ul nu a predat niciodată conexiunea. În orice caz, lista listenerilor decide cine acceptă socketul, iar acesta este faptul de confirmat înainte de a schimba alt fișier.
Lasă acea hartă a listenerilor lângă configurație, ca următoarea persoană care atinge 443 să știe ce proces acceptă și unde a ajuns celălalt protocol. Confirmă proprietatea după schimbare în loc să te bazezi pe ce trebuia să facă editarea.