Por qué una VM de Azure con un dispositivo VPN pierde el camino de vuelta
Un dispositivo VPN en una VM de Azure necesita que la UDR, el indicador de reenvío de la NIC y la política del invitado coincidan. Siga una petición de sucursal a través de las tres.
Una VM de Azure que ejecuta un dispositivo VPN se encuentra dentro de dos sistemas de decisión independientes. Azure decide por dónde sale un paquete de una subred, usando tablas de rutas y el ajuste de reenvío de la NIC. El sistema operativo del propio dispositivo decide si reenvía el paquete descifrado. Un túnel que sube perfectamente puede fallar igualmente en el segundo sistema, y ahí es donde se detienen la mayoría de estos despliegues.
Tres dueños de un mismo camino
Tome una red de sucursal 192.168.50.0/24 y una subred de carga de trabajo 10.0.10.0/24, con el dispositivo en 10.0.0.4 en su propia subred. Una sola petición toca tres configuraciones separadas.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Cada fila la posee un equipo distinto en la mayoría de las organizaciones, y por eso este fallo suele llegar como tres tickets en lugar de uno.
La ruta que apunta al dispositivo
Asocie una tabla de rutas a la subred de carga de trabajo y dé al prefijo de sucursal un siguiente salto de tipo Virtual appliance con 10.0.0.4 como dirección. Use la dirección privada accesible del dispositivo, nunca su punto de entrada público de VPN. El siguiente salto tiene que ser una dirección que la subred de carga de trabajo ya pueda alcanzar. Deje el resto del enrutamiento de la carga de trabajo como está, salvo que haya decidido a propósito reemplazar la ruta predeterminada.
Mantenga el dispositivo en su propia subred y asegúrese de que la ruta que envía el tráfico de sucursal al dispositivo no capture también el camino de salida del propio dispositivo. Ese bucle parece un túnel sano con cero respuestas, y es algo muy desagradable de depurar a las 2 de la madrugada.
El indicador de la NIC que todos olvidan
Azure tiene un ajuste de reenvío de IP por NIC, y está desactivado por defecto. Existe porque una NIC que reenvía recibe paquetes dirigidos a otra cosa, y descartarlos en silencio es el valor seguro por defecto para todos los demás.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true lo activa para una interfaz. La guía de Microsoft sobre el reenvío en la NIC exige el ajuste en cada NIC conectada que reenvíe tráfico, así que un dispositivo de una sola NIC todavía lo necesita en esa NIC.
El indicador no es una ruta ni una regla de firewall. Activarlo concede permiso y nada más.
Qué hace el invitado con el paquete descifrado
Cuando el túnel termina, la pila del propio dispositivo toma la siguiente decisión. En un invitado Linux, el reenvío de IPv4 es un ajuste de ejecución, y sysctl -w net.ipv4.ip_forward=1 dura hasta el siguiente arranque. Guárdelo en un archivo bajo /etc/sysctl.d/ en su lugar. Un dispositivo de proveedor tiene su propio equivalente, y las instrucciones de Linux pegadas en una plataforma de proveedor normalmente no hacen absolutamente nada.
La política de firewall del invitado vuelve a ser aparte, y también el grupo de seguridad de red de la carga de trabajo. Permitir UDP 500 y 4500 hacia la dirección pública de la VM protege el túnel; no dice nada sobre si una petición de sucursal descifrada puede llegar a un puerto de la carga de trabajo.
Siga una petición y su respuesta
Elija un flujo permitido y rastréelo de extremo a extremo. La sucursal necesita una ruta para 10.0.10.0/24 a través de la conexión de sitio, el dispositivo necesita un camino de entrega hacia la subred de carga de trabajo, y la subred de carga de trabajo necesita una ruta de vuelta hacia la sucursal.
Decida pronto si el diseño conserva la dirección de origen de la sucursal o la traduce. El NAT cambia lo que ve la carga de trabajo, así que sus reglas de acceso deberían describir el modelo que realmente eligió y no una dirección de puerta de enlace supuesta.
Un apretón de manos correcto demuestra un eslabón de esa cadena. El camino está completo cuando la respuesta vuelve por el mismo dispositivo y la política de la propia carga de trabajo lo permite.