OpenVPN i HTTPS al port 443: de qui és l’escolta?
TCP i UDP 443 són sockets separats. Compartir un sol listener TCP requereix un propietari, i compartir el port d’OpenVPN és un acord estret, no un truc de proxy.
Dos serveis poden respondre tots dos al port 443 sense competir mai, perquè un listener es defineix pel transport, l’adreça i el port alhora, no només pel número. Posa un servidor web i OpenVPN en una màquina, i l’única pregunta que val la pena respondre primer és quin socket demana cada procés al nucli. Anota aquesta llista abans d’editar una configuració, i la majoria d’errors d’adreça en ús s’expliquen sols. Tot el que ve després de la llista és una tria entre un listener UDP, un socket TCP compartit o un frontal que encamina per protocol.
Comença pel socket que demana cada procés
Un bind té èxit o falla segons aquesta terna, així que dos dimonis només xoquen quan coincideixen les tres parts. Per això un lloc web a TCP 443 conviu indefinidament amb un listener d’OpenVPN a UDP 443, i per això moure’n un a una segona adreça local al mateix host també acaba la discussió. Llegeix els listeners vius en lloc dels fitxers que suposadament els havien de crear, perquè un include antic o un fitxer d’unitat oblidat sobreviu a l’edició que recordes haver fet.
| 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 |
Executa ss -lntup com a root i llegeix cada línia que esmenti 443, incloent-hi les entrades IPv6. Un listener v6 comodí normalment també accepta trànsit v4, i així és com un listener que havies oblidat manté el port ocupat després que canviïs el fitxer que creies responsable. Si un nom de procés et sorprèn, estreny la sortida amb ss -lntup 'sport = :443' abans de tocar res.
Canvia el túnel a UDP quan la xarxa ho permeti
Un listener UDP evita el xoc del tot i normalment és la reparació més curta, ja que no es comparteix cap socket ni s’afegeix cap producte extra al camí. Però no és gratuït. Algunes xarxes de clients descarten UDP 443 sense enviar un reset, així que el túnel deixa d’establir-se en lloc de fallar en el bind, i l’usuari informa que la VPN està caiguda sense cap error per llegir. Un listener UDP també sobreviu a un reinici de la capa web, cosa que compta en una màquina on el lloc es desplega sovint. Prova-ho des de la xarxa on són els usuaris, perquè un shell al servidor només demostra que el servidor es pot abastar a si mateix.
Canvia el transport a la configuració del servidor i al perfil del client alhora. Un perfil que encara demana TCP entrarà en un bucle de reconnexions contra un listener només UDP, i això sembla una fallada de xarxa fins que compares els dos fitxers.
Deixa que el procés de la VPN posseeixi TCP 443 i reenvia la resta
Community OpenVPN en mode servidor TCP llegeix els primers bytes d’una connexió entrant i reenvia tot el que no és el seu protocol a un backend HTTPS, que és per a què serveix la directiva port-share. El backend és un servidor web ordinari amb TLS activat, nomenat per host i port en aquesta directiva, no per una URL.
port-share 10.0.0.5 8080
En una màquina on el lloc té una segona adreça privada, aquella línia envia el trànsit que no és VPN a 10.0.0.5:8080, així que l’amfitrió virtual HTTPS ha d’estar vinculat allà i el tallafoc ha de permetre el salt local. El servidor web ha de terminar TLS ell mateix, perquè els bytes que arriben són el handshake original del navegador i res entremig els ha desxifrat. Apunta la directiva a un listener HTTP pla i el navegador rebrà un error de mètode no vàlid, que es llegeix com un lloc trencat més que com un backend mal col·locat. La directiva només existeix en mode servidor TCP, i un listener UDP no té cap flux per inspeccionar.
Com que el procés de la VPN accepta cada connexió, l’aplicació web veu la petició reenviada arribar des d’una de les adreces del propi host en lloc de des del visitant. Tot el que necessita l’adreça real del client depèn del suport del protocol PROXY al backend o d’un frontal que l’afegeixi. Moure el backend a una altra adreça local no recupera l’adreça del visitant; només canvia quina de les adreces de l’host registra el lloc. Anota aquesta limitació a les notes de desplegament abans que un informe d’analítica plantegi la pregunta.
Un proxy invers és l’eina equivocada; un encaminador de capa quatre no
Un proxy invers HTTP termina TLS per poder llegir les peticions, cosa que vol dir que no pot deixar passar un flux d’OpenVPN intacte. Un encaminador de capa quatre que reenvia per SNI o per inspecció del primer paquet pot quedar davant dels dos, sempre que no acabi la sessió de la qual depèn la VPN. Els dos dispositius semblen iguals en un diagrama i es comporten de manera ben diferent al socket.
L’Access Server comercial porta les seves pròpies opcions de compartició de port, i no es corresponen un a un amb la directiva de la comunitat. Identifica el producte i la versió abans d’adaptar una guia escrita per a l’altre. Una opció copiada que s’ignora silenciosament és pitjor que no tenir-ne cap, perquè la llista de listeners encara sembla plausible després.
Prova el lloc web i el túnel com dos camins separats
Carrega el lloc i connecta el túnel, després torna a llegir la llista de listeners per veure quin procés posseeix 443 ara. Una pàgina que carrega no demostra res sobre la VPN, i un túnel que connecta no demostra res sobre el lloc, tot i que tots dos fan servir el mateix número. Les tres ordres de sota comproven el socket compartit, el camí web i el servei de VPN en aquest ordre.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Compara l’adreça del client al registre d’accés del backend amb la del registre de la VPN en el mateix moment. Si el lloc registra cada visitant com el propi host, el reenviament funciona i el tractament de l’adreça no. Si tots dos registres callen, el frontal no va lliurar mai la connexió. De qualsevol manera, la llista de listeners decideix qui accepta el socket, i aquest és el fet que cal confirmar abans de canviar un altre fitxer.
Deixa aquest mapa de listeners al costat de la configuració perquè la propera persona que toqui 443 sàpiga quin procés accepta i on ha anat l’altre protocol. Confirma la propietat després del canvi en lloc de confiar en què volia fer l’edició.