VPN de sitio a sitio en Azure cun par detrás de NAT: lista de comprobación

Realice estas comprobacións en orde e detéñase na primeira que falle. A maioría dos informes de que Azure non admite un dispositivo detrás de NAT resultan ser un enderezo de par ao que Azure non pode chegar, ou un túnel que nunca se inicia desde o lado correcto. O transporte externo e o encamiñamento interno son dous problemas distintos, e mesturalos fai perder unha tarde. Cada paso seguinte produce unha observación que pode entregar a outra persoa.

Paso 1: confirme que o par está realmente detrás de NAT

Compare o enderezo da interface WAN do dispositivo co enderezo que Azure ve para el. Se difiren, algo está a traducir, e ese tradutor xa forma parte do seu deseño de VPN. Pregunte ao provedor se a asignación é estática ou compartida, porque unha asignación compartida cambia aquilo en que pode confiar. Un dispositivo con enderezo WAN privado e sen reenvío é un caso distinto dun detrás dun NAT de nivel de operador cunha asignación pública estable.

Se os dous enderezos coinciden, detéñase aquí: NAT non é o seu problema e o resto desta lista non axudará.

Anote ambos os enderezos e o modelo do tradutor no ticket. Esa soa liña evita a seguinte rolda de preguntas sobre por que o par configurado non responde.

Paso 2: acorde quen inicia

As preguntas frecuentes de Azure VPN Gateway indican compatibilidade con NAT-T e engaden que o dispositivo local debe iniciar o túnel IPsec cando está detrás de NAT. Iso encaixa con como funciona a tradución con estado, xa que o tradutor mantén unha asignación porque o dispositivo interno enviou o primeiro paquete. Se se espera que Azure inicie e non chega nada que cree esa asignación, o túnel nunca arrinca.

Configure o par para que un erro de só respondente sexa evidente, e comprobe se o dispositivo reintenta por si mesmo ou necesita un disparador. Algúns dispositivos só levantan un túnel cando aparece tráfico interesante, o cal está ben ata que o tráfico interesante é unha sonda de saúde que nunca chega.

Observe o intercambio IKE no dispositivo durante un inicio manual; o silencio alí é unha resposta de encamiñamento ou de firewall, non unha resposta de Azure.

Paso 3: acerte co enderezo do par

Azure necesita un enderezo público accesible para o par no seu obxecto de pasarela de rede local, normalmente o enderezo público do tradutor en lugar do enderezo interno do dispositivo. A identidade coa que se autentica o dispositivo é un campo aparte e pode diferir lexitimamente do enderezo ao que Azure marca. Manteña ambos separados, porque intercambialos produce un fallo de autenticación que parece exactamente un problema de NAT.

Se o enderezo público cambia, ese obxecto ten que cambiar con el. Un nome que resolve a un enderezo obsoleto é peor que un enderezo estático que deba actualizar a man.

Anote os tres valores: enderezo local do dispositivo, enderezo público traducido e identidade do par configurada.

Paso 4: abra só os portos que NAT-T necesita

NAT-T transporta ESP dentro de UDP, e o RFC 3948 describe esa encapsulación co porto 4500 usado tras a negociación inicial no porto 500. O seu firewall e o tradutor deben permitir o intercambio e o seu tráfico de retorno. Permitir un porto TCP non relacionado non demostra nada sobre esta ruta, e unha regra que permite a saída pero non a resposta seguirá fallando.

Un reenvío de porto entrante estático non é obrigatorio automaticamente cando o par inicia e o tradutor mantén estado. Tórnase necesario cando a asignación é inestable ou cando algo na ruta caduca o estado de forma agresiva.

Capture unha vez nos dous lados do tradutor; a diferenza de encapsulación vese de inmediato.

Paso 5: separe o transporte externo do encamiñamento interno

Un túnel que se establece e non transporta nada é un problema de encamiñamento, non de NAT-T. Os sitios seguen necesitando selectores de tráfico compatibles, espazos de enderezos coincidentes, regras de acceso e unha ruta de retorno para as redes de aplicacións. Nada diso o achega un intercambio IKE correcto.

Se os dous sitios usan rangos privados solapados, a tradución dentro do túnel é un deseño aparte coas súas propias regras. Non renumere unha subrede só porque a pasarela externa estea detrás dun router doméstico.

Clasifique o fallo por etapa antes de cambiar nada, e manteña esa clasificación no ticket para que a seguinte persoa comece onde vostede se detivo.