Cómo llega una aplicación web de Azure al entorno local a través de una VPN

La solicitud saliente de la aplicación web deja a un trabajador que nunca ve, de una fuente que usted no eligió, y el firewall de la oficina tiene que aceptarla. Ése es todo el problema en una frase. La integración regional de VNet proporciona a la solicitud una ruta hacia una red virtual y la VPN de sitio a sitio la transporta desde allí. Todo lo que sale mal después tiene que ver con qué rango de origen y qué ruta utilizó realmente el paquete.

Lo que realmente envía el trabajador

App Service ejecuta su código en trabajadores que se encuentran fuera de la vista de red de su suscripción. Con la integración regional habilitada, el tráfico saliente se entrega a una subred delegada en una red virtual en la misma región y el paquete aparece allí antes de continuar. La integración no mueve la aplicación a la red virtual ni cambia su dirección de entrada. Solo les da a los flujos salientes un primer salto diferente.

De forma predeterminada, solo el espacio de direcciones privado toma esa ruta, por lo que los destinos de Internet comunes aún salen directamente del trabajador. Enrutar todo a través de la VNet es una configuración y una decisión separadas, porque también envía sus dependencias públicas a través del túnel.

El tráfico de configuración, como la extracción de una imagen de contenedor al inicio, sigue sus propias reglas de enrutamiento y puede fallar mientras las llamadas a la API se realizan correctamente.

La subred de integración es la fuente que debes permitir

La oficina ve el rango de direcciones de la subred de integración, o lo que sea que su dispositivo traduzca, no las direcciones salientes públicas de la aplicación. Coloque ese rango en los selectores de tráfico de la VPN del sitio y en la regla de firewall local. Si el túnel está basado en políticas, los selectores que lo omiten descartan el paquete incluso cuando existe una ruta.

No permita ninguna dirección de trabajador que haya observado. Las instancias cambian con el escalado y el mantenimiento de la plataforma, y una regla fijada a una dirección falla en el peor momento.

Mantenga el lado de destino estrecho: un servicio, un puerto, una dirección, con la ruta de regreso permitida explícitamente.

El peering y el tránsito de puerta de enlace son explícitos

Si la puerta de enlace VPN se encuentra en una red virtual central y la subred de integración en un radio, la ruta necesita que se permita el tránsito de la puerta de enlace en el emparejamiento del concentrador y se permita el uso de la puerta de enlace remota en el emparejamiento radial. El emparejamiento por sí solo transporta tráfico entre las dos redes virtuales y nada más. Las rutas efectivas en la subred de integración son donde usted confirma que el siguiente salto de la puerta de enlace realmente está allí.

Un diseño hub-and-spoke cuya tabla de rutas envía 0.0.0.0/0 a un firewall es una variante común, y ese firewall necesita su propia regla para el prefijo local.

Dibuje el camino en papel antes de abrir un ticket con el equipo de la red, porque le ahorra un día de adivinanzas. Incluya la dirección de retorno en el dibujo, ya que esa es la mitad que la gente olvida.

El punto final privado entrante es la otra dirección

Un punto final privado hace que se pueda acceder a la aplicación desde dentro de una red virtual. No hace nada con la llamada saliente de la aplicación a la oficina, y los equipos configuran una periódicamente, aunque el requisito real era el contrario.

La documentación anterior describe la integración requerida por puerta de enlace basada en VPN de punto a sitio, una característica diferente con sus propios requisitos. Microsoft programa la retirada de esa característica para el 31 de marzo de 2027 y, en su lugar, recomienda la integración regional.

No copie una configuración de punto a sitio heredada sólo porque la utilizó un ejemplo antiguo.

Verificar con el contexto propio de la aplicación

Pruebe desde la aplicación implementada, no desde su computadora portátil ni desde una máquina virtual en la misma red virtual. Registre la dirección resuelta, el resultado de la conexión y la respuesta a nivel de aplicación por separado, debido a una falla de DNS, un tiempo de espera de TCP y un punto de rechazo de autenticación en tres propietarios diferentes. Si la resolución del nombre falla, corrija el DNS privado para la VNet antes de tocar el túnel.

El estado de un túnel verde solo demuestra que la puerta de enlace está activa. No dice nada sobre selectores, reglas de firewall o DNS.

Cuando la solicitud finalmente funcione, escriba el rango de origen, el puerto de destino y la zona DNS en el runbook de la aplicación. La próxima persona que depure esto comenzará desde su nota en lugar de desde la página de estado de la puerta de enlace.