¿Peering de Azure o VPN de VNet a VNet? Decida antes de enrutar

Azure le ofrece al menos dos formas de conectar dos redes virtuales, y no son ajustes intercambiables del mismo objeto. El peering une las VNet en la red troncal de Microsoft sin puerta de enlace; una VPN de VNet a VNet coloca una relación IPsec entre dos puertas de enlace que usted despliega, dimensiona y supervisa. La decisión se reduce a tres condiciones, y si no puede responder las tres antes de añadir una ruta, está a punto de construir un rodeo para un modelo que nunca eligió.

Tres condiciones que deciden el modelo

La primera es si algo del requisito necesita un límite IPsec que sea suyo y que pueda señalar. La segunda es si los espacios de direcciones están limpios y las dos VNet solo necesitan hablar entre sí. La tercera es quién es dueño de cualquier ruta transitiva y de la factura de la puerta de enlace. Respóndalas en ese orden, porque la primera puede eliminar el peering por atractiva que parezca la segunda.

Lo que comparten ambos modelos es una regla de direccionamiento dura: los espacios de direcciones de las VNet no deben solaparse. Ni el peering ni una VPN de VNet a VNet son una forma admitida de hacer inequívocos dos rangos idénticos, y un solapamiento exige un diseño de mapeo o un rediseño, no otro tipo de conexión.

Condición 1: ¿necesita un límite IPsec que sea suyo?

El peering transporta el tráfico por la red troncal privada de Azure y no requiere una puerta de enlace VPN para la propia conexión emparejada. Eso es una afirmación sobre el transporte, no una afirmación sobre cifrado que pueda entregar a un auditor como «usamos IPsec». Si el requisito nombra un túnel configurado por el cliente, una política IKE concreta o un límite que termina en equipo que usted controla, el peering no lo cumple, por privada que sea la red troncal.

Una VPN de VNet a VNet sí proporciona ese límite: dos puertas de enlace, una relación IPsec/IKE, claves compartidas y toda la superficie operativa que conlleva. Usted hereda el estado del túnel, la capacidad de la puerta de enlace, los límites de SKU y la supervisión que demuestra que el túnel está activo. Esa es la respuesta correcta cuando el requisito trata específicamente de ese límite, descrito en la visión general del peering como un tipo de conexión distinto del peering.

Sea igual de cuidadoso en la dirección contraria. «Necesitamos cifrado entre VNet» a menudo se satisface con el TLS propio de la carga de trabajo, y entonces una puerta de enlace es un costo sin requisito detrás. Escriba la frase que leerá el auditor antes de elegir el mecanismo.

Condición 2: ¿la topología es directa o algo necesita transitar?

El peering no es transitivo. Dos VNet emparejadas con un concentrador no quedan por ello conectadas entre sí, y una ruta que parece funcionar en una dirección suele ser un peering que alcanzó Connected solo en un lado. Ambos lados deben existir y ambos deben mostrar Connected, y eso es lo primero que hay que comprobar cuando el tráfico desaparece en silencio.

Si el requisito es alcanzar la red local a través de un concentrador, el tránsito de puerta de enlace es un diseño aparte con roles concretos: el concentrador posee la puerta de enlace, el peering del spoke permite el tránsito de puerta de enlace y el spoke debe permitir el tráfico reenviado. Son propiedades del peering, no consecuencias automáticas de conectar las VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

La tabla de rutas efectiva es la respuesta honesta a «¿existe el camino?». Muestra el tipo de siguiente salto que la plataforma usará realmente, así que un peering que parece configurado pero no está conectado aparece como una ruta ausente o incorrecta en lugar de como un misterio.

Condición 3: ¿quién es dueño del camino transitivo y de la factura?

Cada salto adicional tiene un dueño. Con peering, una VNet nueva significa un par de peering nuevo en ambos lados y, para el tránsito, un concentrador que sigue reenviando tráfico y una tabla de rutas que sigue apuntando a él. Con una VPN, una VNet nueva significa otra puerta de enlace u otra conexión sobre una existente, con su propio techo de capacidad que vigilar.

El costo sigue la misma forma pero no las mismas partidas: los cargos de peering son conexión y transferencia de datos, mientras que una VPN añade horas de puerta de enlace y sus propios cargos de transferencia. Compare el total para la topología que realmente ejecutará durante un año, incluido el segundo túnel y la supervisión, no el precio de una conexión hoy. Incluya el trabajo que nadie factura: alguien tiene que rotar claves, vigilar el estado del túnel y responder a la alerta a las tres de la madrugada cuando se reinicia una puerta de enlace. Esa partida suele decidir la discusión, porque es la única que nunca aparece en un presupuesto.

Elija lo que elija, pruebe tres flujos: el previsto, uno denegado que debe seguir denegado y el caso de recuperación en el que la puerta de enlace del concentrador o un peering está caído. Un modelo que solo explica el camino feliz no se ha verificado, se ha demostrado.

Verifique la elección contra su propia afirmación

Escriba una frase que nombre el modelo, el límite y el dueño, y luego compruebe que el estado desplegado encaja con ella. Para el peering eso significa ambos estados de peering en Connected, la ruta efectiva mostrando el siguiente salto de peering para el prefijo de destino y ninguna puerta de enlace en el camino. Para una VPN de VNet a VNet significa ambas conexiones en Connected, claves y directivas coincidentes en ambas puertas de enlace y una ruta cuyo siguiente salto es la puerta de enlace de red virtual.

Si las comprobaciones contradicen la frase, corrija primero la frase. La mayor parte de la confusión en estos diseños viene de un híbrido que nadie describió: un peering para la subred de la carga de trabajo, una VPN para un servicio heredado y una tabla de rutas que prefiere uno de ellos en silencio.