Sem internet numa VPN Windows? O pool de endereços é o suspeito

O Windows mostra o túnel como conectado e rotula-o Sem acesso à Internet, o que as pessoas leem como uma esquisitice do Windows. É uma afirmação sobre o que o cliente recebeu: nenhum gateway predefinido utilizável, nenhum resolvedor a funcionar ou nenhum caminho de volta para os endereços dentro do túnel. Quando o servidor é uma Incoming Connection do Windows, uma única configuração explica a maioria desses relatos. O rótulo não é um diagnóstico, mas reduz a busca a três locais.

Leia a concessão antes de a alterar

Execute ipconfig /all no cliente e localize o adaptador VPN entre as entradas. O endereço, o gateway predefinido e o servidor DNS que lista são os factos de que precisa, e muitas vezes diferem do que o administrador assume que foi entregue.

Três padrões correspondem a três falhas. Um endereço em 169.254.0.0/16 significa que o cliente não recebeu nada e atribuiu a si mesmo um endereço link-local. Um endereço plausível sem gateway significa que o pool foi servido sem a opção que dá ao cliente uma rota predefinida. Uma concessão completa que mesmo assim não chega a nada aponta para reencaminhamento ou tradução do lado do servidor.

Anote os valores antes de tocar no servidor. O passo seguinte compara-os com o intervalo que o servidor pensa estar a distribuir, e a memória é um mau substituto de uma concessão.

Porque é que a atribuição automática pode deixar sem gateway

A entrada Incoming Connections tem as suas próprias propriedades IPv4, separadas do adaptador físico. A predefinição ali oferece atribuir endereços automaticamente, o que depende do alocador incorporado da ligação para fornecer endereço, máscara, gateway e DNS.

Numa estação de trabalho isolada esse alocador não tem âmbito de onde tirar, a menos que outra coisa na máquina forneça um, pelo que o cliente pode ficar com um endereço link-local ou com um endereço mas sem gateway. A ligação parece estabelecida porque o link subiu, enquanto a configuração por trás está incompleta.

É por isso que mudar para um intervalo especificado corrige tantos destes relatos. Deixa de pedir a um serviço que pode não estar a correr para inventar uma concessão e começa a declarar a concessão você mesmo.

A mesma confusão aparece quando alguém espera que o servidor DHCP do router da LAN sirva os clientes do túnel. A descoberta por difusão não atravessa um túnel encaminhado, pelo que esse servidor nunca vê o pedido. Assumir o contrário é a razão mais comum para culpar um pool por um cliente que nunca lhe pediu nada.

Defina um intervalo explícito que o servidor possa encaminhar

Escolha um bloco pequeno dentro de uma sub-rede que o servidor alcance, fora do intervalo que o router da LAN distribui e fora de qualquer outro pool na rede. Se o servidor está em 172.20.10.0/24 e o router tem 172.20.10.1, um bloco curto perto do topo dessa sub-rede, digamos de 172.20.10.201 a 172.20.10.209, mantém as concessões do túnel longe da distribuição que o router já gere.

Introduza-o nas propriedades IPv4 da Incoming Connection, volte a ligar o cliente e leia o adaptador outra vez antes de alterar mais alguma coisa. Uma segunda leitura é o que lhe diz se o pool era a falha ou apenas uma falha entre várias.

Estes comandos imprimem a configuração resultante e as rotas que o cliente tem agora:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

O gateway na concessão deve ser um endereço que o servidor possua, e a rota predefinida do cliente deve apontar para ele. Se a concessão está completa mas não existe rota, o servidor atribuiu sem empurrar um gateway, e as definições do pool continuam a ser o local a ver.

Um endereço não é um caminho para a internet

Receber uma concessão apenas move pacotes do cliente para o servidor. Para acesso à internet o servidor tem de reencaminhar esses pacotes e traduzi-los para o seu próprio uplink, e isso é uma configuração separada com os seus próprios modos de falha.

O Internet Connection Sharing é o atalho. Transforma o adaptador virado para a internet num gateway partilhado e corre o seu próprio endereçamento, o que pode reescrever o endereço desse adaptador e deixar uma regra NAT existente a apontar para um valor que já não existe. Registe as definições originais antes de o ativar.

A alternativa encaminhada mantém o endereçamento estável e pede-lhe que configure reencaminhamento e tradução de forma explícita. Nenhuma abordagem está errada; misturá-las a meio produz um túnel com concessão e sem saída, que é exatamente o sintoma com que começou. Escolha um modelo e conclua-o antes de acrescentar o outro.

Exclua primeiro o caminho exterior

Nenhum pool ajuda se o túnel nunca se formar. O protocolo decide o que o caminho tem de transportar: o PPTP quer TCP 1723 e GRE, que é o protocolo IP 47 e não uma porta; o L2TP/IPsec quer UDP 1701 mais 500 e 4500; o SSTP quer TCP 443.

Um router que reencaminha a porta mas não o protocolo produz uma tentativa de ligação que nunca se autentica. É uma falha diferente de um túnel que se forma e depois não chega a nada, e os dois não devem ser depurados em conjunto.

Teste a partir da mesma LAN e da rede remota. Se a tentativa na LAN funcionar e a remota nunca chegar à autenticação, o caminho exterior é o problema. Se ambas se autenticarem e apenas o cliente remoto não tiver internet, volte ao pool e à saída.