NAT no servidor VPN ou no router? As duas opções podem funcionar

Marcar uma ligação como rota padrão num portátil é o passo de que todos se lembram, e é justamente o que não muda nada no gateway. O cliente passa agora a enviar os pedidos de Internet para o túnel; se saem do edifício depende do encaminhamento, de um ponto de tradução e de um caminho de regresso que alcance o endereço privado do cliente. Duas disposições podem fornecer as três coisas, colocam o trabalho em locais diferentes, e ambas falham da mesma forma silenciosa quando ninguém é responsável pela direção da resposta. Escolher entre elas é uma questão de quem deve ver o pool de clientes.

O mito: uma rota de cliente constrói a saída

O túnel forçado é uma política do lado do cliente: decide que o tráfego vai para o adaptador VPN em vez do físico. A documentação da Microsoft sobre encaminhamento VPN descreve essa separação e esse comportamento forçado, e é uma afirmação sobre a tabela de rotas do cliente, não sobre as regras de encaminhamento do servidor. Do ponto de vista do cliente, o túnel é onde vive a Internet; do ponto de vista do gateway, chegou um pacote de um endereço de que ninguém a montante alguma vez ouviu falar. Nenhum dos lados está mal configurado por si só, e é por isso que a falha parece um servidor avariado para a pessoa junto ao portátil.

Esse desajuste é todo o problema que o resto deste artigo resolve. Algo tem de tornar o endereço privado do cliente devolvível, e a escolha é onde.

Desenhe primeiro o caminho de regresso

Escreva o caminho com endereços reais antes de tocar em qualquer definição, e marque nele os dois pontos de tradução candidatos. Este laboratório usa um pool VPN de 10.70.0.0/24 com um cliente em 10.70.0.37, um endereço LAN do servidor de 172.16.40.10, um router em 172.16.40.1 e uma saída pública de 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

O servidor que já navega na Internet prova apenas o seu próprio caminho. Um pacote encaminhado em nome de um cliente é uma decisão diferente, tomada pela política de encaminhamento na mesma máquina, e é essa que normalmente falta. Marcar os três pontos de decisão no diagrama mantém a conversa sobre um deles de cada vez.

Opção A: traduzir no servidor VPN

Aqui o servidor traduz a origem do cliente para o seu próprio endereço LAN antes de entregar o pacote ao router, e o router aplica a sua tradução habitual na saída. Na resposta, o mapeamento do router restaura o endereço do servidor e o mapeamento do servidor restaura o endereço do cliente. Duas traduções com estado em série são normais e exequíveis, desde que ambas sejam registadas; o router nunca precisa de uma rota para o pool, e é esse o atrativo desta disposição.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Use estas leituras para ver o que o servidor já tem em vez de assumir que existe um NAT. Uma regra de masquerade de Linux copiada de um blog não é uma configuração de Windows, e uma permissão na firewall do anfitrião para o ouvinte VPN não é a mesma política que a permissão para encaminhar o pedido de um cliente. Confirme o papel de encaminhamento do servidor a partir da sua própria superfície de gestão, e depois olhe para a tradução em separado, porque as duas coisas são muitas vezes ativadas por partes diferentes de uma implementação.

Opção B: levar o pool ao router

Na segunda disposição o servidor encaminha o verdadeiro endereço de origem do cliente, e o router tradu-lo. Isso mantém o pool de clientes visível na periferia, o que ajuda se o router for o local onde vivem a política de tráfego, o registo ou a inspeção. Também significa que o router precisa de uma rota de regresso para 10.70.0.0/24 que aponte para 172.16.40.10, além de uma política de Internet que inclua realmente esse prefixo; uma regra escrita para a sub-rede LAN não se estende em silêncio ao pool.

Escolha esta opção quando o equipamento de periferia for o responsável previsto pela política e puder aceitar outro prefixo nas suas tabelas de encaminhamento e tradução. Escolha a tradução do lado do servidor quando o pool tiver de ficar invisível a montante e o router não for administrado pela mesma equipa. Nenhuma das opções é implicada por qualquer caixa de seleção no cliente, e nenhuma é mais segura em geral; colocam a visibilidade e a manutenção em locais diferentes.

Torne explícitos o DNS, o IPv6 e a aceitação

A tradução de endereços não corrige a resolução de nomes. O cliente pode usar um resolvedor fornecido com o perfil VPN, um resolvedor privado para espaços de nomes específicos, ou um público aprovado, e um resolvedor inacessível sob essa política continuará a falhar depois de o encaminhamento funcionar. Teste um nome e um endereço em separado, para que as duas falhas nunca se fundam num único relatório.

O IPv6 precisa do seu próprio parágrafo no desenho. Uma tradução IPv4 a funcionar não diz nada sobre se os clientes IPv6 têm rota, uma origem pública válida ou uma política que os bloqueia quando o túnel cai. Deixar isso sem dizer significa que metade dos clientes contorna o gateway em silêncio enquanto a outra metade funciona.

Para a aceitação, siga um pedido de cliente permitido e a sua resposta pelas duas fronteiras, e anote que endereço cada fronteira deveria ver nesse momento. Esse registo é o que torna a próxima alteração do pool numa edição de cinco minutos em vez de uma discussão sobre quem é dono da rota de regresso em falta. Guarde o registo com o perfil do cliente e não num ticket, porque o perfil é o que o próximo engenheiro vai encontrar primeiro.