Dos IP públicas en una sola VM VPN de Azure: qué hace cada una

Dos IP públicas en una sola VM VPN de Azure crean una expectativa que rara vez se cumple: la dirección a la que se conectan los clientes será también la dirección que ven los sitios web. Tres decisiones independientes producen ese resultado, y solo la primera trata del escucha del túnel. La segunda es el origen del invitado usado para el tráfico de cliente reenviado, y la tercera es el método de salida de Azure que se aplica a ese origen. Cambie una y las otras dos se quedan donde estaban, así que decida cada una explícitamente.

Decisión 1: dónde termina el túnel

Una IP pública de Azure se asocia a una configuración de IP privada en la NIC; no es una dirección que se añada dentro del sistema operativo invitado. Lea la correspondencia en lugar de suponerla: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Cualquier dirección privada que devuelva esa consulta es la que el invitado debe tener realmente.

Una NIC puede llevar varias configuraciones de IP, así que dos direcciones públicas no requieren dos NIC. Si el diseño sí usa dos NIC, cada una aporta sus propias rutas de invitado y saltos siguientes, y ha añadido una decisión de enrutamiento en lugar de simplificarla.

Para un servicio con un enlace local explícito, enlácelo a la dirección privada real del invitado, nunca al marcador público. Un escucha que acepta todas las direcciones recibe tráfico por cada configuración de IP que lo alcanza, así que restrinja la entrada con el grupo de seguridad de red y el cortafuegos del host en lugar de esperar que lo decida el orden de enlace.

Decisión 2: qué origen usa el cliente reenviado

Después de que la puerta de enlace descifra una solicitud del cliente, el paquete que reenvía es distinto del que llegó al escucha VPN. El invitado necesita el reenvío habilitado, una política de cortafuegos que permita el flujo y una dirección de origen que el diseño de la nube permita. Si traduce la dirección interna del cliente, ese origen traducido es el que Azure evaluará, no la dirección interna del cliente.

Una regla SNAT estrecha puede elegir un origen privado del invitado, pero no puede imponerse a una traducción posterior de Azure. Elija SNAT cuando necesite responsabilidad por cliente dentro de la VM; omítalo cuando el diseño de salida de la subred ya proporcione un origen público estable y una segunda traducción solo añadiría estado.

Decisión 3: qué método de salida de Azure gana

Microsoft documentael orden de precedencia de salida: una ruta aplicable hacia un dispositivo o puerta de enlace tiene prioridad, y la conectividad de la subred mediante NAT Gateway tiene prioridad sobre una IP pública a nivel de instancia en la ruta correspondiente. Ese orden es la razón por la que traducir a 10.20.0.5 no demuestra que un sitio web vaya a ver 198.51.100.20. Lea la tabla de rutas efectiva, la asociación de NAT Gateway y la IP pública de la NIC juntas antes de aceptar el diseño de salida.

Mantengael ajuste de reenvío de la NIC de Azureseparado del reenvío de Linux. El indicador de la nube permite paquetes cuyo origen o destino no está asignado a la NIC; no habilita net.ipv4.ip_forward, y el ajuste del invitado no concede el permiso de la nube.

El socket del túnel tiene su propia decisión de origen

Address de WireGuard en wg-quick asigna una dirección a la interfaz WireGuard; no es una instrucción de enlace UDP externa. El origen del socket cifrado sigue la tabla de enrutamiento, así que una ruta de política o una segunda ruta predeterminada puede moverlo sin tocar la dirección de la interfaz.OpenVPN: la opción local y UDP multihome se comportan igual: afectan al escucha y a sus respuestas, no al origen de internet de cada cliente reenviado.

Conserve la ruta de la capa inferior que transporta el túnel y confirme que el cliente sigue recibiendo respuestas autenticadas desde la disposición de entrada esperada. No confíe en el orden de la lista de direcciones como política permanente de selección de origen, porque la siguiente dirección añadida a la NIC puede cambiar cuál gana.

Qué aceptar y en qué orden

Acepte tres resultados por separado. Primero, un cliente externo alcanza la entrada VPN prevista. Segundo, una solicitud nueva permitida de ese cliente VPN sale por la salida de internet documentada. Tercero, las rutas no deseadas de escucha y reenvío siguen denegadas. Registre las correspondencias de público a privado y los responsables de invitado y de nube de cada decisión en el mismo lugar.

Un túnel correcto solo demuestra la primera parte. Pruebe la salida con un flujo nuevo, porque una conexión en caché puede seguir usando el origen antiguo mucho después de que cambie la ruta.