Porque é que o endereço do seu túnel VPN não abre uma porta de entrada
Um endereço de túnel identifica o seu cliente perante os pares que lhe podem encaminhar tráfego e nunca cria um ouvinte. Verifique a ligação, a rota de retorno e depois a política.
Ligue-se à VPN do escritório, inicie um serviço pequeno na porta 8443, envie o endereço do túnel a um colega e veja a ligação falhar enquanto o cliente continua a reportar que está ligado. Nada está avariado no túnel: o endereço foi atribuído, a sessão está ativa e os pacotes que levariam a resposta simplesmente nunca são admitidos. Faça as três verificações abaixo por ordem e pare na que falhar, porque cada uma tem uma correção diferente e só uma delas diz respeito à VPN.
Comece por onde o socket está realmente associado
Antes de algo ser encaminhado, algo tem de estar à escuta num endereço que o chamador consiga alcançar. Os servidores de desenvolvimento são o culpado habitual, porque muitos associam-se por predefinição a loopback e só aceitam ligações originadas na mesma máquina. Um endereço de túnel não altera essa associação, e o sistema operativo recusará a ligação muito antes de a VPN entrar em jogo.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Leia a coluna do endereço local em vez do estado. 127.0.0.1:8443 significa apenas loopback, e a correção é uma associação a 0.0.0.0 ou ao próprio endereço do túnel. 0.0.0.0:8443 aceita em todas as interfaces, o que é mais amplo do que a maioria pretende quando a máquina também tem um endereço público; 10.64.7.15:8443 é a versão estreita que só escuta onde o colega consegue chegar. Repare também no nome do processo na mesma saída, porque uma instância perdida de um teste anterior é uma causa comum de a porta parecer aberta e responder com o conteúdo errado.
Depois pergunte se algo consegue encaminhar para esse endereço
Um endereço de túnel só faz sentido para os pares configurados para enviar esse prefixo para dentro do túnel. A máquina do colega tem a sua própria tabela e, sem uma rota para a sub-rede do túnel, o pacote vai para o gateway predefinido e morre num local que não faz ideia de que o endereço existe. É uma questão de encaminhamento do lado de quem chama, não uma permissão do seu lado.
| 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 dois clientes importa tanto como isso. No desenho habitual de acesso remoto, cada cliente abre uma ligação de saída para o gateway e o gateway guarda o estado desses fluxos, pelo que as respostas voltam por um caminho que já conhece. Uma ligação de um cliente para outro é um fluxo novo que o gateway tem de aceitar e reencaminhar, e muitas instalações desativam isso deliberadamente para manter os clientes isolados uns dos outros. Os serviços VPN de consumo isolam normalmente por predefinição; os gateways empresariais às vezes permitem-no por grupo.
Verifique a direção antes de mudar algo no anfitrião. Se o endereço do túnel responde a partir do próprio gateway mas não de um par, a diferença é a definição de cliente-para-cliente do gateway, e nenhuma edição da firewall local a pode substituir.
Por fim, encontre a política que permite o fluxo
Três camadas de política estão entre um pacote encaminhado e um serviço que responde: a decisão de reencaminhamento do servidor VPN, a firewall do anfitrião e qualquer grupo de segurança da nuvem à frente da instância. As três têm de concordar, e falham de formas diferentes, por isso o sintoma da tabela acima é mais útil do que a mensagem de erro no navegador.
A firewall do anfitrião é a camada de que as pessoas se esquecem depois de uma associação bem-sucedida, porque uma regra que permite a porta na interface LAN não a permite automaticamente na interface do túnel. As regras limitadas à interface são o desenho correto e também a causa habitual de um serviço que funciona a partir do escritório e não de casa. Leia o âmbito da regra, não o número da porta.
A filtragem com estado explica o caso inverso. Uma ligação de saída do seu portátil cria estado, e as respostas são admitidas sem uma regra de entrada. A ligação do colega é um fluxo completamente novo sem estado por trás, por isso precisa de uma autorização explícita. Essa assimetria é toda a razão pela qual uma sessão de navegador a funcionar na sua própria máquina não diz nada sobre se o serviço é acessível de fora.
Quando uma verificação falha, mude o desenho e não o túnel
Se o requisito é que um colega abra o seu serviço local, a resposta honesta costuma ser um mecanismo concebido para o acesso de entrada. Um túnel SSH inverso é o mais pequeno: a sua máquina liga-se para fora a um anfitrião que o colega já consegue alcançar, e o ouvinte existe nesse anfitrião.
ssh -N -R 8443:127.0.0.1:8443 [email protected]O relé precisa de GatewayPorts clientspecified na configuração do servidor SSH, caso contrário o ouvinte reencaminhado associa-se a loopback no relé e o colega depara-se com a mesma recusa de antes. Para tudo o que dure mais de uma tarde, um balanceador de carga ou um ingress com verificação de saúde e certificado para o nome publicado é o melhor instrumento, e um túnel de local para local com rotas para as duas sub-redes é a resposta certa quando duas redes precisam mesmo de falar.
Cada um desses desenhos torna a exposição explícita, e é esse o ponto. Uma VPN move pacotes entre redes para as quais já estava autorizado; não publica um serviço nem transforma um portátil num anfitrião exposto à internet. Decidir qual das três camadas mudar é a tarefa, e o túnel raramente é uma delas.