Encaminhar o tráfego entre duas filiais por um gateway VPN do Azure
Duas conexões site a site num gateway VPN do Azure podem passar o tráfego das filiais, mas só quando as duas pontas aprendem o prefixo e existe o caminho de retorno na LAN.
Duas filiais podem trocar tráfego por um gateway VPN do Azure sem qualquer túnel direto entre elas. Cada filial abre uma conexão site a site para o mesmo gateway, e o gateway passa os prefixos aprendidos entre as duas conexões. O que faz isto funcionar não é o segundo túnel, mas a troca de rotas: a filial A tem de aprender o prefixo da filial B, e a B o da A. Percorra as verificações abaixo por ordem e pare na primeira que falhar, porque cada passo seguinte depende dela.
Pré-requisitos, antes de configurar qualquer coisa
Quatro condições decidem se este desenho pode funcionar. O gateway tem de ser baseado em rotas e num SKU que suporte BGP, ambas as conexões têm de ter BGP ativado, os espaços de endereços das filiais não podem sobrepor-se, e nenhum lado pode depender de NAT para esconder o prefixo real.
Planeie os ASN com cuidado. O valor predefinido documentado do Azure é 65515, e cada router de filial precisa do seu próprio ASN privado que não colida com o gateway nem com a outra filial. Reutilizar um valor predefinido sem verificar uma configuração de gateway existente é como um caminho AS acaba por ser rejeitado mais tarde.
Confirme também que não espera o comportamento de peering de VNet. O gateway troca rotas entre as duas conexões que configurou; não torna transitivos peerings arbitrários. Se uma terceira rede tiver de chegar às duas filiais, precisa da sua própria conexão ou do seu próprio caminho de rota, não da suposição de que o gateway vai repartir o tráfego. Anote esse limite antes da primeira janela de alteração, porque é a decisão de desenho a que as pessoas voltam quando mais tarde é adicionado um site.
Configure por esta ordem
Cada passo tem um resultado observável, por isso não avance até ele aparecer.
- Ative o BGP no gateway de rede virtual e anote o ASN e o endereço de par.
- Crie um gateway de rede local por filial com o espaço de endereços real dessa filial, o seu ASN e o seu endereço de par BGP.
- Crie cada conexão site a site e ative o BGP na própria conexão.
- Configure o router da filial para emparelhar com o endereço de gateway atribuído pelo Azure, não com o endpoint IKE público do gateway por suposição.
O quarto passo é onde a maioria das tentativas encrava. O endereço de par BGP que o Azure reporta é o que o router da filial tem de usar como vizinho, e nem sempre é o endereço que as pessoas esperam do diagrama do túnel.
Anuncie o próprio prefixo da filial, por exemplo 10.10.0.0/16 a partir de A e 10.20.0.0/16 a partir de B. Não anuncie uma rota predefinida nem um agregado amplo para cobrir uma rede específica em falta; a lacuna volta mais tarde como um buraco negro silencioso.
Verifique a troca de rotas nas duas pontas
O estado da conexão não é a verificação. O IPsec pode estar ativo nas duas conexões sem que nenhum prefixo atravesse entre elas. Leia os pares BGP do gateway e as suas rotas aprendidas, e depois confirme que a rota para a outra filial aparece como um caminho utilizável.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Um prefixo presente numa tabela BGP ainda pode perder a decisão de encaminhamento para uma rota estática ou um prefixo mais específico. Verifique a rota selecionada, não apenas a recebida.
Siga o caminho de retorno do lado da LAN
Esta é a parte que parece correta no Azure e falha no local. Um anfitrião da filial A só envia o seu pacote para o router VPN de A se esse router for o seu gateway predefinido, ou se o anfitrião ou o seu gateway tiver uma rota para o prefixo de B. O mesmo tem de ser verdade no sentido oposto.
Se um comutador central separado for o gateway predefinido da LAN, precisa da rota para a outra filial a apontar para o router VPN. Sem ela o pedido chega e a resposta sai pelo caminho da Internet, e o utilizador vê uma ligação que abre e depois fica pendurada.
Não recorra a um grupo de segurança de rede na sub-rede do gateway para corrigir isto. Essa sub-rede tem os seus próprios requisitos e um NSG ali não é um substituto suportado da política do lado da filial. A filtragem pertence às firewalls das filiais e às próprias cargas de trabalho, onde as regras podem ser revistas pelas pessoas que as possuem. Mover essas regras para um NSG de sub-rede também as esconde da equipa que vai depurar a próxima falha.
Admita a operação e depois prove-a com um teste negado
Uma rota aprendida não é uma autorização. Permita a origem, o destino e o serviço de que realmente precisa através das firewalls das filiais e da política do endpoint, e deixe o resto negado.
Teste a partir de uma carga de trabalho comum da filial A para um serviço real da filial B, confirme a resposta, e depois tente uma operação que deve continuar proibida. O tráfego gerado pelo próprio dispositivo VPN pode usar outro endereço de origem e saltar a etapa de encaminhamento da LAN, por isso um ping bem-sucedido a partir do router prova menos do que parece.
Termine anotando quatro factos: os prefixos trocados, os ASN em uso, o caminho de retorno LAN de cada lado e a política que admite o serviço. Se faltar um deles, a configuração funciona até à primeira alteração, e depois ninguém sabe explicar porquê.