OpenVPN e HTTPS no porto 443: quen posúe o socket de escoita?
TCP e UDP 443 son sockets distintos. Compartir un só listener TCP require un propietario, e o uso compartido do porto de OpenVPN é un acordo estreito, non un truco de proxy.
Dous servizos poden responder ambos no porto 443 sen competir nunca, porque un listener defínese polo transporte, o enderezo e o porto xuntos, non só polo número. Pon un servidor web e OpenVPN nunha máquina, e a única pregunta que merece resposta primeiro é que socket pide cada proceso ao núcleo. Anota esa lista antes de editar unha configuración, e a maioría dos erros de enderezo en uso explícanse sós. Todo o que segue a lista é unha escolla entre un listener UDP, un socket TCP compartido ou un frontal que encamiña por protocolo.
Comeza polo socket que pide cada proceso
Un bind ten éxito ou falla segundo esa terna, así que dous daemons só chocan cando coinciden as tres partes. Por iso un sitio web en TCP 443 convive indefinidamente cun listener de OpenVPN en UDP 443, e por iso mover un deles a un segundo enderezo local no mesmo host tamén remata a discusión. Le os listeners vivos en lugar dos ficheiros que supostamente os debían crear, porque un include obsoleto ou un ficheiro de unidade esquecido sobrevive á edición que recordas ter feito.
| 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 como root e le cada liña que mencione 443, incluídas as entradas IPv6. Un listener v6 comodín adoita aceptar tamén tráfico v4, e así é como un listener que esqueciches mantén o porto ocupado despois de que cambies o ficheiro que crías responsable. Se un nome de proceso te sorprende, estreita a saída con ss -lntup 'sport = :443' antes de tocar nada.
Cambia o túnel a UDP cando a rede o permita
Un listener UDP evita a colisión por completo e adoita ser a reparación máis curta, xa que non se comparte ningún socket e ningún produto extra entra no camiño. Non é gratis. Algunhas redes de clientes descartan UDP 443 sen enviar un reset, así que o túnel deixa de establecerse en lugar de fallar no bind, e o usuario informa que a VPN está caída sen ningún erro que ler. Un listener UDP tamén sobrevive a un reinicio da capa web, o que conta nunha máquina cuxo sitio se despregue a miúdo. Proba desde a rede onde están os usuarios, porque un shell no servidor só demostra que o servidor se alcanza a si mesmo.
Cambia o transporte na configuración do servidor e no perfil do cliente á vez. Un perfil que aínda pide TCP entrará nun bucle de reconexións contra un listener só UDP, e iso parece unha falla de rede ata que compares os dous ficheiros.
Deixa que o proceso da VPN posúa TCP 443 e reenvía o resto
Community OpenVPN en modo servidor TCP le os primeiros bytes dunha conexión entrante e reenvía todo o que non é o seu propio protocolo a un backend HTTPS, que é para o que serve a directiva port-share. O backend é un servidor web normal con TLS activado, nomeado por host e porto nesa directiva en lugar de por unha URL.
port-share 10.0.0.5 8080
Nunha máquina onde o sitio ten un segundo enderezo privado, esa liña envía o tráfico que non é VPN a 10.0.0.5:8080, así que o host virtual HTTPS debe estar vinculado alí e a devasa debe permitir o salto local. O servidor web debe terminar TLS por si mesmo, porque os bytes que chegan son o handshake orixinal do navegador e nada intermedio os descifrou. Apunta a directiva a un listener HTTP simple e o navegador recibirá un erro de método non válido, que se le como un sitio roto en lugar de como un backend mal colocado. A directiva só existe en modo servidor TCP, e un listener UDP non ten ningún fluxo que inspeccionar.
Como o proceso da VPN acepta cada conexión, a aplicación web ve a petición reenviada chegar desde un dos enderezos do propio host en lugar de desde o visitante. Todo o que necesita o enderezo real do cliente depende do soporte do protocolo PROXY no backend ou dun frontal que o engada. Mover o backend a outro enderezo local non devolve o enderezo do visitante; só cambia cal dos enderezos do host rexistra o sitio. Anota esa limitación nas notas de despregamento antes de que un informe de analítica plantexe a pregunta.
Un proxy inverso é a ferramenta equivocada; un encamiñador de capa catro non
Un proxy inverso HTTP termina TLS para poder ler peticións, o que significa que non pode deixar pasar un fluxo de OpenVPN intacto. Un encamiñador de capa catro que reenvía por SNI ou por inspección do primeiro paquete pode situarse diante de ambos, sempre que non termine a sesión da que depende a VPN. Os dous dispositivos parecen iguais nun diagrama e compórtanse de forma completamente distinta no socket.
O Access Server comercial trae os seus propios axustes de uso compartido de porto, e non se corresponden un a un coa directiva da comunidade. Identifica o produto e a versión antes de adaptar unha guía escrita para o outro. Un axuste copiado que se ignora en silencio é peor que non ter axuste, porque a lista de listeners segue parecendo plausible despois.
Proba o sitio web e o túnel como dous camiños separados
Carga o sitio e conecta o túnel, logo le de novo a lista de listeners para ver que proceso posúe 443 agora. Unha páxina que carga non demostra nada sobre a VPN, e un túnel que conecta non demostra nada sobre o sitio, aínda que ambos usan o mesmo número. Os tres comandos de abaixo comproban o socket compartido, o camiño web e o servizo VPN nesa orde.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Compara o enderezo do cliente no rexistro de acceso do backend co do rexistro da VPN no mesmo momento. Se o sitio rexistra cada visitante como o propio host, o reenvío funciona e o tratamento do enderezo non. Se ambos rexistros calan, o frontal nunca entregou a conexión. De calquera xeito, a lista de listeners decide quen acepta o socket, e ese é o feito que hai que confirmar antes de cambiar outro ficheiro.
Deixa ese mapa de listeners xunto á configuración para que a próxima persoa que toque 443 saiba que proceso acepta e a onde foi o outro protocolo. Confirma a propiedade despois do cambio en lugar de confiar no que a edición pretendía facer.