OpenVPN tras stunnel: reenvía o envoltorio, non o porto 1194

Coloca un envoltorio TLS diante de OpenVPN e o despregamento gaña un segundo oínte, dos cales só un debería mirar nunca a internet. Cando o túnel funciona desde a mesma máquina e falla desde fóra, o reenvío adoita apuntar ao equivocado dos dous. O que debe encaixar é unha cadea: a regra pública chega ao envoltorio, e a propia conexión de backend do envoltorio chega ao socket VPN real. Catro saltos levan esa cadea, e calquera deles pode rematar a investigación antes de tempo.

Dous sockets, dous donos, un deles público

O envoltorio remata TLS para a conexión externa e pasa o fluxo de bytes descifrado a un oínte OpenVPN TCP simple. Son sockets separados con ficheiros de configuración separados, así que editar un deixa o outro intacto e aínda aparentemente san. Tamén significa que os dous poden separarse sempre que se cambie un sen o outro.

Traballar desde a propia máquina, por tanto, demostra moi pouco sobre a ruta pública. Unha conexión directa ao porto nativo salta o envoltorio, unha conexión ao envoltorio no seu enderezo LAN salta a tradución, e só a disposición completa do lado do cliente exercita o que fai un usuario externo. Os nomes tamén hai que lelos con coidado, porque localhost significa o host que executa ese compoñente concreto e non o host no que escribes por casualidade. Mantén esa distinción nas túas notas, porque unha proba rexistrada sen o salto que cubría invita a comparar dúas cousas distintas.

Onde aterra realmente o reenvío

A cadea é máis fácil de reter como catro saltos que como tres números de porto, porque o mesmo número pode significar cousas distintas en cada extremo. Le a táboa fila por fila: cada fila é un socket que debe aceptar unha conexión e despois abrir a seguinte. Cando unha fila apunta ao par equivocado, o síntoma da última columna é o que informa o usuario.

Unha regra que apunta ao porto VPN nativo en lugar de ao envoltorio salta por completo a terminación TLS, que é a versión máis común deste erro: o cliente abre un handshake cun oínte que espera o encadramento de OpenVPN, así que a conexión pode abrirse e despois atascarse. Confirma o porto traducido contra o ficheiro de configuración do envoltorio e non contra a memoria, porque a próxima persoa que edite ese ficheiro pode ter escollido outro número. Os dous comandos de abaixo mostran as dúas caras desa cuestión á vez.

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

O enderezo de ligazón que te rexeita

Unha liña accept ligada a 127.0.0.1 só responde ao propio host, así que un reenvío que chega ao enderezo LAN non pode conectar e o cliente ve un rexeitamento que soa a problema de filtro de paquetes. Mira o socket antes de tocar a devasa, porque o socket é a resposta máis barata. Ou ligas o envoltorio á interface á que apunta o reenvío, ou o mantés en loopback e fas que o reenvío chegue a loopback a través de algo que funcione de verdade. Son dous deseños, e cada un necesita a súa propia regra.

Mesturalos é como un envoltorio funcional acaba inalcanzable desde fóra mentres cada ficheiro parece correcto. A comprobación de abaixo é un só comando, e responde unha pregunta que unha revisión das regras da devasa non pode. Se a saída mostra un enderezo loopback mentres o reenvío apunta ao enderezo LAN, a corrección pertence á liña accept e non ao filtro de paquetes.

ss -lntp '( sport = :8443 )'

Que demostrou realmente a proba local

Un éxito rexistrado sen o salto que cubría non é evidencia sobre os outros saltos. Anota que enderezo usou a proba e que proceso respondeu. Despois repite desde fóra da rede en lugar de desde un teléfono na mesma Wi-Fi, porque o comportamento de forcada varía entre routers e unha conexión que nunca saíu da LAN pode satisfacer un cliente sen que o reenvío participe en absoluto. Só ese segundo intento exercita o camiño que toma un descoñecido.

Cando o intento falla, segue unha soa conexión por ambos os rexistros: as liñas de aceptación e conexión do envoltorio, logo o rexistro de sesión do daemon VPN. A primeira fronteira que non rexistra nada é onde pertence o seguinte cambio. Unha vez que OpenVPN compara opcións de par, xulga esas mensaxes polas regras desa implementación. Un aviso de inconsistencia de link-mtu non é automaticamente fatal, fixar link-mtu en 1500 non demostra que a fragmentación parase, e a negociación de cifrado pertence á configuración interna de OpenVPN e non ao reenvío do router.

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

Eses sinais cobren o socket de backend e o rexistro do envoltorio, o que separa un backend rexeitado dun handshake rexeitado. Execútaos mentres un único intento está en curso e non despois. As marcas de tempo dun único intento son o que fai fiable a comparación.

Dúas identidades, dúas ordes de fallo

O certificado externo pertence ao envoltorio e a identidade interna pertence a OpenVPN, e poden vir de autoridades distintas. Desactivar calquera das dúas comprobacións para que un camiño pareza san cambia unha protección real por un resultado cosmético. Mantén as dúas verificacións e depúraas en orde, porque a secuencia de mensaxes nomea a capa: un problema de certificado do envoltorio aparece antes de que se negocie calquera opción VPN, mentres que un fallo de identidade interna só aparece unha vez establecido o fluxo.

O manual de stunnel define accept, connect e o modo cliente con precisión, e esas seccións responden a pregunta do socket máis rápido que adiviñar. Cando aínda non podes dicir que capa respondeu, le o certificado que presenta o porto público co comando de abaixo. Un certificado de envoltorio na saída significa que o reenvío chegou ao envoltorio, e o silencio ou un erro de protocolo significa que non. Esa única distinción aforra máis tempo que calquera outra comprobación aquí.

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