OpenVPN darrere d'stunnel: reenvieu l'embolcall, no el port 1194
Dos oients, tres ports. Comproveu on arriba el reenviament, on s'enllaça l'embolcall, on es connecta, què va saltar una prova local i les dues identitats.
Poseu un embolcall TLS davant d'OpenVPN i el desplegament guanya un segon oient, només un dels quals hauria d'afrontar mai internet. Quan el túnel funciona des de la mateixa màquina i falla des de fora, el reenviament sol apuntar a l'equivocat dels dos. El que ha de quadrar és una cadena: la regla pública arriba a l'embolcall, i la connexió de backend de l'embolcall arriba al sòcol VPN real. Quatre salts porten aquesta cadena, i qualsevol d'ells pot acabar la investigació abans d'hora.
Dos sòcols, dos propietaris, un de públic
L'embolcall acaba el TLS per a la connexió externa i passa el flux de bytes desxifrat a un oient OpenVPN TCP simple. Són sòcols separats amb fitxers de configuració separats, així que editar-ne un deixa l'altre intacte i encara aparentment sa. També significa que els dos poden divergir sempre que se'n canvia un sense l'altre.
Treballar des de la mateixa màquina, doncs, demostra molt poc sobre el camí públic. Una connexió directa al port natiu salta l'embolcall, una connexió a l'embolcall a la seva adreça LAN salta la traducció, i només la disposició completa del costat del client exerceix el que fa un usuari extern. Els noms també s'han de llegir amb cura, perquè localhost vol dir l'amfitrió que executa aquell component concret i no l'amfitrió on escriviu per casualitat. Manteniu aquesta distinció a les vostres notes, perquè una prova registrada sense el salt que cobria convida a comparar dues coses diferents.
On arriba realment el reenviament
La cadena és més fàcil de retenir com a quatre salts que com a tres nombres de port, perquè el mateix nombre pot significar coses diferents a cada extrem. Llegiu la taula fila per fila: cada fila és un sòcol que ha d'acceptar una connexió i després obrir la següent. Quan una fila apunta al company equivocat, el símptoma de l'última columna és el que reporta l'usuari.
| Hop | Listens on | Must reach | Symptom when it points elsewhere |
|---|---|---|---|
| Client machine | A local plaintext port | The wrapper's public TLS address | Plain text offered to a TLS endpoint |
| Router forward | Public TCP 443 | The wrapper host on its translated port | Wrapper records no connection at all |
| Wrapper, server mode | Its accepted port, 8443 here | The native VPN socket on loopback | Handshake completes, then silence |
| Native VPN listener | Loopback TCP port | Its peer, over TCP only | A UDP socket behind a byte-stream relay |
Una regla que apunta al port VPN natiu en lloc de a l'embolcall se salta completament la terminació TLS, que és la versió més comuna d'aquest error: el client obre un handshake amb un oient que espera l'enquadrament OpenVPN, així que la connexió pot obrir-se i després encallar-se. Confirmeu el port traduït contra el fitxer de configuració de l'embolcall i no contra la memòria, perquè la propera persona que editi aquest fitxer pot haver triat un nombre diferent. Les dues ordres de sota mostren les dues cares d'aquesta qüestió alhora.
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'L'adreça d'enllaç que us refusa
Una línia accept enllaçada a 127.0.0.1 només respon al mateix amfitrió, així que un reenviament que arriba a l'adreça LAN no es pot connectar i el client veu un rebuig que sona com un problema de filtre de paquets. Mireu el sòcol abans de tocar el tallafoc, perquè el sòcol és la resposta més barata. O bé enllaceu l'embolcall a la interfície a què apunta el reenviament, o bé el manteniu a loopback i feu que el reenviament arribi a loopback a través d'alguna cosa que realment funcioni. Són dos dissenys, i cadascun necessita la seva pròpia regla.
Barrejar-los és com un embolcall funcional acaba inaccessible des de fora mentre cada fitxer sembla correcte. La comprovació de sota és una ordre, i respon una pregunta que una revisió de les regles del tallafoc no pot. Si la sortida mostra una adreça de loopback mentre el reenviament apunta a l'adreça LAN, la correcció és a la línia accept i no al filtre de paquets.
ss -lntp '( sport = :8443 )'Què va demostrar realment la prova local
Un èxit registrat sense el salt que cobria no és evidència sobre els altres salts. Anoteu quina adreça va usar la prova i quin procés va respondre. Després repetiu-ho des de fora de la xarxa i no des d'un telèfon a la mateixa Wi-Fi, perquè el comportament de forqueta varia entre encaminadors i una connexió que mai va sortir de la LAN pot satisfer un client sense que el reenviament hi tingui res a veure. Només el segon intent exercita el camí que fa un desconegut.
Quan l'intent falla, seguiu una sola connexió pels dos registres: les línies d'acceptació i connexió de l'embolcall, i després el registre de sessió del dimoni VPN. La primera frontera que no registra res és on pertany el canvi següent. Quan OpenVPN compara opcions de parell, jutgeu aquests missatges per les regles d'aquesta implementació. Un avís d'inconsistència de link-mtu no és automàticament fatal, fixar link-mtu a 1500 no demostra que la fragmentació s'hagi aturat, i la negociació de xifrat pertany a la configuració interna d'OpenVPN i no al reenviament de l'encaminador.
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerAquestes sondes cobreixen el sòcol de backend i el registre de l'embolcall, cosa que separa un backend rebutjat d'un handshake rebutjat. Executeu-les mentre un sol intent és en curs i no després. Les marques de temps d'un sol intent són el que fa fiable la comparació.
Dues identitats, dos ordres de fallada
El certificat extern pertany a l'embolcall i la identitat interna pertany a OpenVPN, i poden venir d'autoritats diferents. Desactivar qualsevol de les comprovacions per fer que un camí sembli sa canvia una protecció real per un resultat cosmètic. Manteniu les dues verificacions i depureu-les en ordre, perquè la seqüència de missatges anomena la capa: un problema de certificat de l'embolcall apareix abans que es negociï cap opció VPN, mentre que una fallada d'identitat interna només apareix un cop el flux està establert.
El manual d'stunnel defineix amb precisió accept, connect i el mode client, i aquestes seccions responen la pregunta del sòcol més de pressa que endevinar. Quan encara no podeu dir quina capa ha respost, llegiu el certificat que presenta el port públic amb l'ordre de sota. Un certificat d'embolcall a la sortida significa que el reenviament va arribar a l'embolcall, i el silenci o un error de protocol significa que no. Aquesta única distinció estalvia més temps que qualsevol altra comprovació d'aquí.
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer