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

Realice estas comprobaciones en orden y deténgase en la primera que falle. La mayoría de los informes de que Azure no admite un dispositivo detrás de NAT resultan ser una dirección de par a la que Azure no puede llegar, o un túnel que nunca se inicia desde el lado correcto. El transporte externo y el enrutamiento interno son dos problemas distintos, y mezclarlos hace perder una tarde. Cada paso siguiente produce una observación que puede entregar a otra persona.

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

Compare la dirección de la interfaz WAN del dispositivo con la dirección que Azure ve para él. Si difieren, algo está traduciendo, y ese traductor ya forma parte de su diseño de VPN. Pregunte al proveedor si la asignación es estática o compartida, porque una asignación compartida cambia aquello en lo que puede confiar. Un dispositivo con dirección WAN privada y sin reenvío es un caso distinto de uno detrás de un NAT de nivel de operador con una asignación pública estable.

Si las dos direcciones coinciden, deténgase aquí: NAT no es su problema y el resto de esta lista no ayudará.

Anote ambas direcciones y el modelo del traductor en el ticket. Esa sola línea evita la siguiente ronda de preguntas sobre por qué el par configurado no responde.

Paso 2: acuerde quién inicia

Las preguntas frecuentes de Azure VPN Gateway indican compatibilidad con NAT-T y añaden que el dispositivo local debe iniciar el túnel IPsec cuando está detrás de NAT. Eso encaja con cómo funciona la traducción con estado, ya que el traductor mantiene una asignación porque el dispositivo interno envió el primer paquete. Si se espera que Azure inicie y no llega nada que cree esa asignación, el túnel nunca arranca.

Configure el par para que un error de solo respondedor sea evidente, y compruebe si el dispositivo reintenta por sí solo o necesita un disparador. Algunos dispositivos solo levantan un túnel cuando aparece tráfico interesante, lo cual está bien hasta que el tráfico interesante es una sonda de estado que nunca llega.

Observe el intercambio IKE en el dispositivo durante un inicio manual; el silencio ahí es una respuesta de enrutamiento o de firewall, no una respuesta de Azure.

Paso 3: acierte con la dirección del par

Azure necesita una dirección pública accesible para el par en su objeto de puerta de enlace de red local, normalmente la dirección pública del traductor en lugar de la dirección interna del dispositivo. La identidad con la que se autentica el dispositivo es un campo aparte y puede diferir legítimamente de la dirección a la que Azure marca. Mantenga ambas separadas, porque intercambiarlas produce un fallo de autenticación que parece exactamente un problema de NAT.

Si la dirección pública cambia, ese objeto tiene que cambiar con ella. Un nombre que resuelve a una dirección obsoleta es peor que una dirección estática que deba actualizar a mano.

Anote los tres valores: dirección local del dispositivo, dirección pública traducida e identidad del par configurada.

Paso 4: abra solo los puertos que NAT-T necesita

NAT-T transporta ESP dentro de UDP, y el RFC 3948 describe esa encapsulación con el puerto 4500 usado tras la negociación inicial en el puerto 500. Su firewall y el traductor deben permitir el intercambio y su tráfico de retorno. Permitir un puerto TCP no relacionado no demuestra nada sobre esta ruta, y una regla que permite la salida pero no la respuesta seguirá fallando.

Un reenvío de puerto entrante estático no es obligatorio automáticamente cuando el par inicia y el traductor mantiene estado. Se vuelve necesario cuando la asignación es inestable o cuando algo en la ruta caduca el estado de forma agresiva.

Capture una vez en ambos lados del traductor; la diferencia de encapsulación se ve de inmediato.

Paso 5: separe el transporte externo del enrutamiento interno

Un túnel que se establece y no transporta nada es un problema de enrutamiento, no de NAT-T. Los sitios siguen necesitando selectores de tráfico compatibles, espacios de direcciones coincidentes, reglas de acceso y una ruta de retorno para las redes de aplicaciones. Nada de eso lo aporta un intercambio IKE correcto.

Si los dos sitios usan rangos privados solapados, la traducción dentro del túnel es un diseño aparte con sus propias reglas. No renumere una subred solo porque la puerta de enlace externa esté detrás de un router doméstico.

Clasifique el fallo por etapa antes de cambiar nada, y mantenga esa clasificación en el ticket para que la siguiente persona empiece donde usted se detuvo.