Porque é que adicionar um prefixo Azure VPN corta a ligação

Um prefixo adicionado ao objeto Azure errado produz uma ligação que reporta Connected e não reencaminha nada, e esse é o tipo de erro mais caro nesta pilha. Estão envolvidos três recursos e apenas um deles possui o espaço de endereços remoto: o gateway de rede virtual, o gateway de rede local que descreve o lado remoto e a ligação que os une. O prefixo pertence ao gateway de rede local, a ligação tem de ser reconstruída para a alteração produzir efeito, e o gateway em si costuma ficar intacto. A ordem não é negociável, e o portal só mostra parte dela.

Três objetos, um dos quais guarda o prefixo

O espaço de endereços da rede virtual responde a outra pergunta: o que vive dentro do Azure. Adicionar ali um prefixo remoto não encaminha tráfego para ele, apenas alarga o espaço que a plataforma julga possuir, o que pode colidir com o intervalo remoto real. O gateway de rede local é o objeto que guarda os prefixos remotos, e a ligação referencia os dois gateways mais uma chave partilhada previamente.

Há uma terceira reserva a ter em conta. GatewaySubnet aloja as instâncias geridas do gateway, tem de ter exatamente esse nome, e para SKUs que não são Basic espera-se que seja pelo menos /27.

Nada mais pertence a essa sub-rede, e uma alteração de prefixo não tem motivo para lhe tocar. Um prefixo em falta no gateway de rede local é inalcançável diga o que disser o estado da ligação, porque o gateway só oferece os prefixos que lhe foram comunicados ao negociar o túnel. É por isso que o sintoma é assimétrico: o túnel está em cima, a associação de segurança está bem e uma sub-rede nunca aparece nos seletores de tráfego. Se faltar um único intervalo remoto enquanto os vizinhos funcionam, deixe de olhar para o túnel e leia o gateway de rede local.

Porque é que é a ligação que é removida

O objeto de ligação fixa a configuração negociada durante toda a sua vida. Por isso o procedimento documentado remove primeiro a ligação, atualiza o gateway de rede local e depois recria a ligação com a mesma chave partilhada. As instâncias do gateway não são reconstruídas para uma alteração apenas de prefixo, o que limita a interrupção ao desmantelamento da ligação em vez de uma reimplantação do gateway.

Essa eliminação é a interrupção, por isso trate-a como uma alteração planeada com início e fim esperados em vez de uma edição rápida. No PowerShell a sequência é curta: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, depois Set-AzLocalNetworkGateway com o novo -AddressPrefix matriz, depois New-AzVirtualNetworkGatewayConnection com a mesma -SharedKey e os mesmos gateways. Reutilizar a chave é importante, porque o lado remoto não é reconfigurado e uma chave nova significa coordenação com quem possui o dispositivo remoto. Se for outra equipa a gerir esse dispositivo, combine a janela com ela antes de remover seja o que for.

Quando o próprio gateway tem de ser reconstruído

Uma segunda resposta que circula sobre este problema diz que o gateway tem de ser recriado e a chave trocada de novo. Isso está correto para outro conjunto de operações: alterar o tipo de gateway ou o SKU, passar entre ponto a site e site a site, ou reparar um gateway cuja própria configuração está errada. Essas alterações mudam de facto o recurso do gateway, pelo que a reconstrução é realmente necessária.

Um gateway criado para ponto a site não pode simplesmente receber uma ligação site a site. A configuração de ponto a site tem de ser removida e o gateway recriado, o que também produz uma nova chave partilhada e um novo pacote de cliente.

O pacote de ponto a site merece uma nota própria porque expira. O portal gera um ficheiro de vida curta, por isso a abordagem prática é descarregá-lo uma vez e distribuí-lo juntamente com o certificado de cliente em vez de enviar aos utilizadores uma ligação do portal que estará morta quando clicarem. Para a questão do prefixo, nada disto se aplica. Manter os dois procedimentos separados é toda a disciplina: os prefixos são uma alteração ao nível da ligação, e as propriedades do gateway são uma alteração ao nível do gateway.

Leia o estado, não o distintivo do portal

Leia o estado a partir do recurso em vez do distintivo no portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 devolve ConnectionStatus juntamente com contadores de bytes de entrada e saída, e são os contadores que separam um túnel ligado que não transporta nada de um que nunca foi estabelecido.

Os contadores que deixam de aumentar a meio de uma transferência apontam para o caminho e não para a autenticação. Os contadores que não se movem de todo apontam para o conjunto de prefixos ou para a chave partilhada.

Os temporizadores explicam uma classe de desconexões atribuídas erradamente à VPN. O balanceador de carga do Azure fecha os fluxos inativos após o tempo limite configurado, quatro minutos por omissão quando estas notas foram escritas e configurável para cima, por isso um servidor OpenVPN numa VM sem keepalive pode cair a cada poucos minutos enquanto tudo o resto parece saudável. Um gateway que a plataforma reinicia ciclicamente também pode interromper uma ligação VNet a uma Web App, e essa falha está do lado da plataforma e não numa configuração de cliente. A pista é se a desconexão segue um intervalo fixo ou uma alteração que fez.

Mantenha os três objetos e os seus valores num único registo: o espaço de endereços da rede virtual, a lista de prefixos do gateway de rede local e a referência à chave partilhada da ligação. artigo de PowerShell de site a site documenta os comandos do gateway de rede local e a ordem a que pertencem. Comparar uma alteração de prefixo com a memória é como se reconstrói duas vezes um túnel que funciona.

Depois verifique pela ordem em que alterou: o gateway de rede local mostra a nova lista de prefixos, a ligação volta a Connected e os contadores mexem-se quando envia tráfego para um anfitrião no novo intervalo. Se o terceiro passo falhar enquanto os dois primeiros passam, o lado remoto não aceitou o novo seletor de tráfego e o dispositivo remoto precisa da entrada de fase 2 correspondente. Isso é uma conversa com o outro extremo do túnel, não outra alteração no Azure.