Por que o enderezo do teu túnel VPN non abre un porto de entrada
Un enderezo de túnel identifica o teu cliente ante os pares que poden encamiñar cara a el, e nunca crea un oínte. Comproba a vinculación, a ruta de volta e despois a política.
Conéctate á VPN da oficina, inicia un servizo pequeno no porto 8443, envía o enderezo do túnel a un compañeiro e observa como a conexión falla mentres o cliente segue informando de que está conectado. No túnel non hai nada roto: o enderezo foi asignado, a sesión está activa e os paquetes que levarían a resposta simplemente nunca se admiten. Fai as tres comprobacións seguintes en orde e detente na que falle, porque cada unha ten unha corrección distinta e só unha delas ten que ver coa VPN.
Comeza por onde está realmente vinculado o socket
Antes de que algo se encamiñe, algo ten que estar escoitando nun enderezo que o chamador poida acadar. Os servidores de desenvolvemento son o culpable habitual, porque moitos se vinculan por defecto a loopback e só aceptan conexións que se orixinan na mesma máquina. Un enderezo de túnel non cambia esa vinculación, e o sistema operativo rexeitará a conexión moito antes de que a VPN interveña.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Le a columna do enderezo local no canto do estado. 127.0.0.1:8443 significa só loopback, e a corrección é unha vinculación a 0.0.0.0 ou ao propio enderezo do túnel. 0.0.0.0:8443 acepta en todas as interfaces, o que é máis amplo do que a maioría pretende cando a máquina tamén ten un enderezo público; 10.64.7.15:8443 é a versión estreita que só escoita onde o compañeiro pode chegar. Fixa tamén no nome do proceso na mesma saída, porque unha instancia perdida dunha proba anterior é unha causa habitual de que o porto pareza aberto e responda co contido equivocado.
Despois pregunta se algo pode encamiñar cara a ese enderezo
Un enderezo de túnel só ten sentido para os pares configurados para enviar ese prefixo dentro do túnel. A máquina do compañeiro ten a súa propia táboa e, se non ten unha ruta para a subrede do túnel, o paquete vai á pasarela predeterminada e morre nun lugar que non ten nin idea de que o enderezo existe. É unha cuestión de encamiñamento do lado do chamador, non un permiso do teu.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
O servidor entre os dous clientes importa igual. No deseño habitual de acceso remoto, cada cliente abre unha conexión saínte cara á pasarela e esta mantén o estado deses fluxos, de xeito que as respostas volven por un camiño que xa coñece. Unha conexión dun cliente a outro é un fluxo novo que a pasarela debe aceptar e reenviar, e moitos despregamentos desactívano deliberadamente para manter os clientes illados entre si. Os servizos VPN de consumo adoitan illar por defecto; as pasarelas corporativas ás veces permíteno por grupo.
Comproba a dirección antes de cambiar nada no host. Se o enderezo do túnel responde desde a propia pasarela pero non desde un par, a diferenza é o axuste de cliente a cliente da pasarela, e ningunha edición do cortalumes local pode substituílo.
Por último, atopa a política que permite o fluxo
Tres capas de política sitúanse entre un paquete encamiñado e un servizo que responde: a decisión de reenvío do servidor VPN, o cortalumes do host e calquera grupo de seguridade da nube diante da instancia. As tres teñen que coincidir e fallan de maneiras distintas, por iso o síntoma da táboa anterior é máis útil ca a mensaxe de erro do navegador.
O cortalumes do host é a capa que a xente esquece despois dunha vinculación correcta, porque unha regra que permite o porto na interface LAN non o permite automaticamente na interface do túnel. As regras limitadas por interface son un deseño correcto e tamén a causa habitual dun servizo que funciona desde a oficina e non desde a casa. Le o alcance da regra, non o seu número de porto.
A filtraxe con estado explica o caso inverso. Unha conexión saínte do teu portátil crea estado, e as respostas a ela admítense sen unha regra de entrada. A conexión do compañeiro é un fluxo completamente novo sen estado detrás, así que necesita unha autorización explícita. Esa asimetría é toda a razón pola que unha sesión de navegador que funciona na túa propia máquina non di nada sobre se o servizo é accesible desde fóra.
Cando falla unha comprobación, cambia o deseño e non o túnel
Se o requisito é que un compañeiro abra o teu servizo local, a resposta honesta adoita ser un mecanismo pensado para o acceso de entrada. Un túnel SSH inverso é o máis pequeno: a túa máquina conéctase cara a fóra a un host que o compañeiro xa pode acadar, e o oínte existe nese host.
ssh -N -R 8443:127.0.0.1:8443 [email protected]O relé necesita GatewayPorts clientspecified na configuración do seu servidor SSH, se non o oínte reenviado vincúlase a loopback no relé e o compañeiro atopa o mesmo rexeitamento ca antes. Para calquera cousa que dure máis dunha tarde, un balanceador de carga ou un ingress con comprobación de saúde e certificado para o nome publicado é o mellor instrumento, e un túnel de sitio a sitio con rutas para as dúas subredes é a resposta correcta cando dúas redes de verdade necesitan falar.
Cada un deses deseños fai explícita a exposición, e ese é o punto. Unha VPN move paquetes entre redes para as que xa estabas autorizado; non publica un servizo nin converte un portátil nun host aberto a internet. Decidir cal das tres capas cambiar é a tarefa, e o túnel raramente é unha delas.