Por qué añadir un prefijo de Azure VPN corta la conexión

Un prefijo añadido al objeto de Azure equivocado produce una conexión que informa de Connected y no reenvía nada, y ese es el tipo de error más caro en esta pila. Intervienen tres recursos y solo uno de ellos posee el espacio de direcciones remoto: la puerta de enlace de red virtual, la puerta de enlace de red local que describe el lado remoto y la conexión que las une. El prefijo pertenece a la puerta de enlace de red local, la conexión debe reconstruirse para que el cambio surta efecto, y la puerta de enlace suele dejarse intacta. El orden no es negociable, y el portal solo muestra una parte de él.

Tres objetos, uno de los cuales contiene el prefijo

El espacio de direcciones de la red virtual responde a otra pregunta: qué vive dentro de Azure. Añadir allí un prefijo remoto no dirige el tráfico hacia él, solo amplía el espacio que la plataforma cree poseer, lo que puede chocar con el rango remoto real. La puerta de enlace de red local es el objeto que contiene los prefijos remotos, y la conexión hace referencia a ambas puertas de enlace más una clave compartida previamente.

Hay una tercera reserva que conviene tener clara. GatewaySubnet aloja las instancias administradas de la puerta de enlace, debe llevar exactamente ese nombre, y para las SKU que no son Basic se espera que sea al menos /27.

Nada más pertenece a esa subred, y un cambio de prefijo no tiene motivo para tocarla. Un prefijo que falta en la puerta de enlace de red local es inalcanzable diga lo que diga el estado de la conexión, porque la puerta de enlace solo ofrece los prefijos de los que se le informó al negociar el túnel. Por eso el síntoma es asimétrico: el túnel está levantado, la asociación de seguridad está bien y una subred nunca aparece en los selectores de tráfico. Si falta un solo rango remoto mientras los vecinos funcionan, deje de mirar el túnel y lea la puerta de enlace de red local.

Por qué se elimina la conexión

El objeto de conexión fija la configuración negociada durante toda su vida. Por eso el procedimiento documentado elimina primero la conexión, actualiza la puerta de enlace de red local y luego recrea la conexión con la misma clave compartida. Las instancias de puerta de enlace no se reconstruyen para un cambio solo de prefijo, lo que limita la interrupción al desmontaje de la conexión en lugar de a un redespliegue de la puerta de enlace.

Esa eliminación es la interrupción, así que trátela como un cambio planificado con un inicio y un final esperado en lugar de una edición rápida. En PowerShell la secuencia es corta: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, luego Set-AzLocalNetworkGateway con el nuevo -AddressPrefix matriz, luego New-AzVirtualNetworkGatewayConnection con la misma -SharedKey y las mismas puertas de enlace. Reutilizar la clave importa, porque el lado remoto no se reconfigura y una clave nueva significa coordinar con quien posee el dispositivo remoto. Si otro equipo gestiona ese dispositivo, acuerde la ventana con ellos antes de quitar nada.

Cuándo hay que reconstruir la propia puerta de enlace

Una segunda respuesta que circula sobre este problema dice que hay que recrear la puerta de enlace y volver a intercambiar la clave. Eso es correcto para otro conjunto de operaciones: cambiar el tipo de puerta de enlace o la SKU, pasar entre punto a sitio y sitio a sitio, o reparar una puerta de enlace cuya propia configuración es incorrecta. Esos cambios sí alteran el recurso de puerta de enlace, así que la reconstrucción es realmente necesaria.

Una puerta de enlace creada para punto a sitio no puede recibir sin más una conexión sitio a sitio. Hay que quitar la configuración de punto a sitio y recrear la puerta de enlace, lo que también produce una clave compartida nueva y un paquete de cliente nuevo.

El paquete de punto a sitio merece su propia nota porque caduca. El portal genera un archivo de vida corta, así que el enfoque práctico es descargarlo una vez y distribuirlo junto con el certificado de cliente en lugar de enviar a los usuarios un enlace del portal que estará muerto cuando hagan clic. Para la cuestión del prefijo, nada de esto se aplica. Mantener los dos procedimientos separados es toda la disciplina: los prefijos son un cambio a nivel de conexión, y las propiedades de la puerta de enlace son un cambio a nivel de puerta de enlace.

Lea el estado, no la insignia del portal

Lea el estado del recurso en lugar de la insignia del portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 devuelve ConnectionStatus junto con contadores de bytes de entrada y salida, y son los contadores lo que separa un túnel conectado que no transporta nada de uno que nunca se estableció.

Los contadores que dejan de aumentar a mitad de una transferencia apuntan al camino y no a la autenticación. Los contadores que no se mueven en absoluto apuntan al conjunto de prefijos o a la clave compartida.

Los temporizadores explican una clase de desconexiones que se atribuyen erróneamente a la VPN. El balanceador de carga de Azure cierra los flujos inactivos tras su tiempo de espera configurado, cuatro minutos por defecto cuando se escribieron estas notas y configurable al alza, así que un servidor OpenVPN en una VM sin keepalive puede caer cada pocos minutos mientras todo lo demás parece sano. Una puerta de enlace que la plataforma reinicia cíclicamente también puede interrumpir una conexión de VNet con una Web App, y ese fallo está del lado de la plataforma y no en una configuración de cliente. La pista es si la desconexión sigue un intervalo fijo o un cambio que usted hizo.

Mantenga los tres objetos y sus valores en un solo registro: el espacio de direcciones de la red virtual, la lista de prefijos de la puerta de enlace de red local y la referencia a la clave compartida de la conexión. artículo de PowerShell de sitio a sitio documenta los comandos de la puerta de enlace de red local y el orden al que pertenecen. Comparar un cambio de prefijo con la memoria es cómo se reconstruye dos veces un túnel que funciona.

Después verifique en el orden en que cambió: la puerta de enlace de red local muestra la nueva lista de prefijos, la conexión vuelve a estar Connected y los contadores se mueven cuando envía tráfico a un host del nuevo rango. Si el tercer paso falla mientras los dos primeros pasan, el lado remoto no ha aceptado el nuevo selector de tráfico y el dispositivo remoto necesita la entrada de fase 2 correspondiente. Eso es una conversación con el otro extremo del túnel, no otro cambio en Azure.