Enrutar el tráfico entre dos sucursales a través de una puerta de enlace VPN de Azure

Dos sucursales pueden intercambiar tráfico a través de una puerta de enlace VPN de Azure sin ningún túnel directo entre ellas. Cada sucursal abre una conexión de sitio a sitio a la misma puerta de enlace, y la puerta de enlace transmite los prefijos aprendidos entre las dos conexiones. Lo que hace que esto funcione no es el segundo túnel, sino el intercambio de rutas: la sucursal A tiene que aprender el prefijo de la B, y la B el de la A. Recorra las comprobaciones siguientes en orden y deténgase en la primera que falle, porque cada paso posterior depende de ella.

Requisitos previos, antes de configurar nada

Cuatro condiciones deciden si este diseño puede funcionar siquiera. La puerta de enlace debe estar basada en rutas y en una SKU que admita BGP, ambas conexiones deben tener BGP habilitado, los espacios de direcciones de las sucursales no deben solaparse, y ningún lado puede depender de NAT para ocultar su prefijo real.

Planifique los ASN con cuidado. El valor predeterminado documentado de Azure es 65515, y cada enrutador de sucursal necesita su propio ASN privado que no colisione con la puerta de enlace ni con la otra sucursal. Reutilizar un valor predeterminado sin comprobar una configuración de puerta de enlace existente es como una ruta AS acaba siendo rechazada más adelante.

Confirme también que no espera el comportamiento del emparejamiento de VNet. La puerta de enlace intercambia rutas entre las dos conexiones que ha configurado; no hace transitivos los emparejamientos arbitrarios. Si una tercera red tiene que llegar a ambas sucursales, necesita su propia conexión o su propia ruta, no la suposición de que la puerta de enlace repartirá el tráfico. Anote ese límite antes de la primera ventana de cambio, porque es la decisión de diseño a la que la gente vuelve cuando más adelante se añade un sitio.

Configure en este orden

Cada paso tiene un resultado observable, así que no continúe hasta que aparezca.

1. Habilite BGP en la puerta de enlace de red virtual y anote su ASN y su dirección de par.
2. Cree una puerta de enlace de red local por sucursal con el espacio de direcciones real de esa sucursal, su ASN y su dirección de par BGP.
3. Cree cada conexión de sitio a sitio y habilite BGP en la propia conexión.
4. Configure el enrutador de la sucursal para emparejarse con la dirección de puerta de enlace que asignó Azure, no con el punto de conexión IKE público de la puerta de enlace por suposición.

El cuarto paso es donde se atascan la mayoría de los intentos. La dirección de par BGP que Azure informa es la que debe usar el enrutador de la sucursal como vecino, y no siempre es la dirección que la gente espera del diagrama del túnel.

Anuncie el prefijo de la sucursal mismo, por ejemplo 10.10.0.0/16 desde A y 10.20.0.0/16 desde B. No anuncie una ruta predeterminada ni un agregado amplio para cubrir una red específica que falta; el hueco vuelve más adelante como un agujero negro silencioso.

Verifique el intercambio de rutas en ambos extremos

El estado de la conexión no es la comprobación. IPsec puede estar activo en ambas conexiones mientras ningún prefijo cruza entre ellas. Lea los pares BGP de la puerta de enlace y sus rutas aprendidas, y luego confirme que la ruta hacia la otra sucursal aparece como un camino utilizable.

Un prefijo presente en una tabla BGP todavía puede perder la decisión de reenvío frente a una ruta estática o un prefijo más específico. Compruebe la ruta seleccionada, no solo la recibida.

Siga la ruta de retorno en el lado de la LAN

Esta es la parte que parece correcta en Azure y falla en el sitio. Un host de la sucursal A envía su paquete al enrutador VPN de A solo si ese enrutador es su puerta de enlace predeterminada, o si el host o su puerta de enlace tiene una ruta para el prefijo de B. Lo mismo debe ser cierto en la otra dirección.

Si un conmutador central separado es la puerta de enlace predeterminada de la LAN, necesita la ruta hacia la otra sucursal apuntando al enrutador VPN. Sin ella, la solicitud llega y la respuesta sale por la ruta de Internet, y el usuario ve una conexión que se abre y luego se cuelga.

No recurra a un grupo de seguridad de red en la subred de la puerta de enlace para arreglar esto. Esa subred tiene sus propios requisitos y un NSG allí no es un sustituto admitido de la política del lado de la sucursal. El filtrado corresponde a los cortafuegos de las sucursales y a las cargas de trabajo mismas, donde las reglas pueden ser revisadas por las personas que las poseen. Mover esas reglas a un NSG de subred también las oculta del equipo que depurará la próxima caída.

Admita la operación y luego demuéstrela con una prueba denegada

Una ruta aprendida no es un permiso. Permita el origen, el destino y el servicio que realmente necesita a través de los cortafuegos de las sucursales y de la política del punto de conexión, y deje el resto denegado.

Pruebe desde una carga de trabajo normal de la sucursal A hacia un servicio real de la sucursal B, confirme la respuesta y luego intente una operación que deba seguir prohibida. El tráfico generado por el propio dispositivo VPN puede usar otra dirección de origen y saltarse la etapa de enrutamiento de la LAN, así que un ping correcto desde el enrutador demuestra menos de lo que parece.

Termine anotando cuatro hechos: los prefijos intercambiados, los ASN en uso, la ruta de retorno de la LAN de cada lado y la política que admite el servicio. Si falta uno de ellos, la configuración funciona hasta el primer cambio, y entonces nadie sabe explicar por qué.