Por que engadir un prefixo de Azure VPN corta a conexión

Un prefixo engadido ao obxecto de Azure equivocado produce unha conexión que informa de Connected e non reenvía nada, e ese é o tipo de erro máis caro nesta pila. Interveñen tres recursos e só un deles posúe o espazo de enderezos remoto: a pasarela de rede virtual, a pasarela de rede local que describe o lado remoto e a conexión que as une. O prefixo pertence á pasarela de rede local, a conexión debe reconstruírse para que o cambio teña efecto, e a pasarela adoita deixarse intacta. A orde non é negociable, e o portal só mostra unha parte dela.

Tres obxectos, un dos cales contén o prefixo

O espazo de enderezos da rede virtual responde a outra pregunta: que vive dentro de Azure. Engadir alí un prefixo remoto non dirixe o tráfico cara a el, só amplía o espazo que a plataforma cre posuír, o que pode chocar co rango remoto real. A pasarela de rede local é o obxecto que contén os prefixos remotos, e a conexión fai referencia a ambas as pasarelas máis unha chave compartida previamente.

Hai unha terceira reserva que convén ter clara. GatewaySubnet aloxa as instancias xestionadas da pasarela, debe levar exactamente ese nome, e para as SKU que non son Basic espérase que sexa polo menos /27.

Nada máis pertence a esa subrede, e un cambio de prefixo non ten motivo para tocala. Un prefixo que falta na pasarela de rede local é inalcanzable diga o que diga o estado da conexión, porque a pasarela só ofrece os prefixos dos que foi informada ao negociar o túnel. Por iso o síntoma é asimétrico: o túnel está levantado, a asociación de seguridade está ben e unha subrede nunca aparece nos selectores de tráfico. Se falta un só rango remoto mentres os veciños funcionan, deixe de mirar o túnel e lea a pasarela de rede local.

Por que se elimina a conexión

O obxecto de conexión fixa a configuración negociada durante toda a súa vida. Por iso o procedemento documentado elimina primeiro a conexión, actualiza a pasarela de rede local e logo recrea a conexión coa mesma chave compartida. As instancias de pasarela non se reconstrúen para un cambio só de prefixo, o que limita a interrupción á desmontaxe da conexión en lugar dun redespregue da pasarela.

Esa eliminación é a interrupción, así que trátea como un cambio planificado cun inicio e un final esperado en lugar dunha edición rápida. En PowerShell a secuencia é curta: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, logo Set-AzLocalNetworkGateway co novo -AddressPrefix matriz, logo New-AzVirtualNetworkGatewayConnection coa mesma -SharedKey e as mesmas pasarelas. Reutilizar a chave importa, porque o lado remoto non se reconfigura e unha chave nova significa coordinar con quen posúe o dispositivo remoto. Se outro equipo xestiona ese dispositivo, acorde a xanela con eles antes de quitar nada.

Cando hai que reconstruír a propia pasarela

Unha segunda resposta que circula sobre este problema di que hai que recrear a pasarela e volver intercambiar a chave. Iso é correcto para outro conxunto de operacións: cambiar o tipo de pasarela ou a SKU, pasar entre punto a sitio e sitio a sitio, ou reparar unha pasarela cuxa propia configuración é incorrecta. Eses cambios si alteran o recurso de pasarela, así que a reconstrución é realmente necesaria.

Unha pasarela creada para punto a sitio non pode recibir sen máis unha conexión sitio a sitio. Hai que quitar a configuración de punto a sitio e recrear a pasarela, o que tamén produce unha chave compartida nova e un paquete de cliente novo.

O paquete de punto a sitio merece a súa propia nota porque caduca. O portal xera un ficheiro de vida curta, así que o enfoque práctico é descargalo unha vez e distribuílo xunto co certificado de cliente en lugar de enviar aos usuarios unha ligazón do portal que estará morta cando fagan clic. Para a cuestión do prefixo, nada diso se aplica. Manter os dous procedementos separados é toda a disciplina: os prefixos son un cambio a nivel de conexión, e as propiedades da pasarela son un cambio a nivel de pasarela.

Lea o estado, non a insignia do portal

Lea o estado do recurso en lugar da insignia do portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 devolve ConnectionStatus xunto con contadores de bytes de entrada e saída, e son os contadores o que separa un túnel conectado que non transporta nada dun que nunca se estableceu.

Os contadores que deixan de aumentar a metade dunha transferencia apuntan ao camiño e non á autenticación. Os contadores que non se moven en absoluto apuntan ao conxunto de prefixos ou á chave compartida.

Os temporizadores explican unha clase de desconexións que se atribúen erroneamente á VPN. O balanceador de carga de Azure pecha os fluxos inactivos tras o seu tempo de espera configurado, catro minutos por defecto cando se escribiron estas notas e configurable á alza, así que un servidor OpenVPN nunha VM sen keepalive pode caer cada poucos minutos mentres todo o demais parece san. Unha pasarela que a plataforma reinicia ciclicamente tamén pode interromper unha conexión de VNet cunha Web App, e ese fallo está do lado da plataforma e non nunha configuración de cliente. A pista é se a desconexión segue un intervalo fixo ou un cambio que vostede fixo.

Manteña os tres obxectos e os seus valores nun só rexistro: o espazo de enderezos da rede virtual, a lista de prefixos da pasarela de rede local e a referencia á chave compartida da conexión. artigo de PowerShell de sitio a sitio documenta os comandos da pasarela de rede local e a orde á que pertencen. Comparar un cambio de prefixo coa memoria é como se reconstrúe dúas veces un túnel que funciona.

Despois verifique na orde en que cambiou: a pasarela de rede local mostra a nova lista de prefixos, a conexión volve estar Connected e os contadores móvense cando envía tráfico a un host do novo rango. Se o terceiro paso falla mentres os dous primeiros pasan, o lado remoto non aceptou o novo selector de tráfico e o dispositivo remoto necesita a entrada de fase 2 correspondente. Iso é unha conversa co outro extremo do túnel, non outro cambio en Azure.