VPN site a site no Azure com um par atrás de NAT: lista de verificação

Faça estas verificações em ordem e pare na primeira que falhar. A maioria dos relatos de que o Azure não suporta um dispositivo atrás de NAT acaba sendo um endereço de par que o Azure não alcança, ou um túnel que nunca é iniciado do lado correto. O transporte externo e o encaminhamento interno são dois problemas diferentes, e misturá-los desperdiça uma tarde. Cada passo abaixo produz uma observação que você pode entregar a outra pessoa.

Passo 1: confirme que o par está mesmo atrás de NAT

Compare o endereço na interface WAN do dispositivo com o endereço que o Azure vê para ele. Se forem diferentes, algo está traduzindo, e esse tradutor agora faz parte do seu desenho de VPN. Pergunte ao provedor se o mapeamento é estático ou compartilhado, porque um mapeamento compartilhado muda aquilo com que você pode contar. Um dispositivo com endereço WAN privado e sem encaminhamento é um caso diferente de um atrás de um NAT de nível de operadora com um mapeamento público estável.

Se os dois endereços coincidirem, pare aqui: o NAT não é o seu problema e o resto desta lista não vai ajudar.

Anote os dois endereços e o modelo do tradutor no tíquete. Essa única linha evita a próxima rodada de perguntas sobre por que o par configurado não responde.

Passo 2: combine quem inicia

As perguntas frequentes do Azure VPN Gateway indicam suporte a NAT-T e acrescentam que o dispositivo local deve iniciar o túnel IPsec quando estiver atrás de NAT. Isso corresponde ao funcionamento da tradução com estado, já que o tradutor mantém um mapeamento porque o dispositivo interno enviou o primeiro pacote. Se se espera que o Azure inicie e nada chega para criar esse mapeamento, o túnel nunca começa.

Configure o par de modo que um erro de apenas respondedor seja evidente, e verifique se o dispositivo tenta novamente sozinho ou precisa de um gatilho. Alguns dispositivos só levantam um túnel quando aparece tráfego interessante, o que está bem até que o tráfego interessante seja uma sonda de saúde que nunca chega.

Observe a troca IKE no dispositivo durante uma iniciação manual; o silêncio ali é uma resposta de encaminhamento ou de firewall, não uma resposta do Azure.

Passo 3: acerte o endereço do par

O Azure precisa de um endereço público alcançável para o par no objeto de gateway de rede local, normalmente o endereço público do tradutor em vez do endereço interno do dispositivo. A identidade com que o dispositivo se autentica é um campo separado e pode legitimamente diferir do endereço que o Azure disca. Mantenha os dois separados, porque trocá-los produz uma falha de autenticação que parece exatamente um problema de NAT.

Se o endereço público mudar, esse objeto tem de mudar com ele. Um nome que resolve para um endereço desatualizado é pior do que um endereço estático que você tem de atualizar à mão.

Anote os três valores: endereço local do dispositivo, endereço público traduzido e identidade do par configurada.

Passo 4: abra apenas as portas de que o NAT-T precisa

O NAT-T transporta ESP dentro do UDP, e o RFC 3948 descreve essa encapsulação com a porta 4500 usada após a negociação inicial na porta 500. O seu firewall e o tradutor têm ambos de permitir a troca e o tráfego de retorno. Permitir uma porta TCP não relacionada não prova nada sobre este caminho, e uma regra que permite a saída mas não a resposta ainda vai falhar.

Um encaminhamento estático de porta de entrada não é automaticamente necessário quando o par inicia e o tradutor mantém estado. Torna-se necessário quando o mapeamento é instável ou quando algo no caminho expira o estado de forma agressiva.

Capture uma vez dos dois lados do tradutor; a diferença de encapsulação é imediatamente visível.

Passo 5: separe o transporte externo do encaminhamento interno

Um túnel que se estabelece e não transporta nada é um problema de encaminhamento, não de NAT-T. Os locais ainda precisam de seletores de tráfego compatíveis, espaços de endereços coincidentes, regras de acesso e um caminho de retorno para as redes de aplicações. Nada disso é fornecido por uma troca IKE bem-sucedida.

Se os dois locais usam faixas privadas sobrepostas, a tradução dentro do túnel é um desenho separado com as suas próprias regras. Não renumerar uma sub-rede só porque o gateway externo está atrás de um router doméstico.

Classifique a falha por etapa antes de mudar qualquer coisa, e mantenha essa classificação no tíquete para que a próxima pessoa comece onde você parou.