Por que uma VM do Azure com appliance VPN perde o caminho de volta
Um appliance VPN numa VM do Azure precisa que a UDR, o sinalizador de encaminhamento da NIC e a política do convidado coincidam. Siga um pedido de filial pelos três.
Uma VM do Azure que executa um appliance VPN está dentro de dois sistemas de decisão independentes. O Azure decide por onde um pacote sai de uma sub-rede, usando tabelas de rotas e a definição de encaminhamento da NIC. O sistema operacional do próprio appliance decide se encaminha o pacote desencriptado. Um túnel que sobe perfeitamente pode ainda falhar no segundo sistema, e é aí que a maioria destas implementações para.
Três donos de um só caminho
Considere uma rede de filial de 192.168.50.0/24 e uma sub-rede de carga de trabalho de 10.0.10.0/24, com o appliance em 10.0.0.4 na sua própria sub-rede. Um único pedido toca em três configurações separadas.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Cada linha pertence a uma equipa diferente na maioria das organizações, e é por isso que esta falha costuma chegar como três pedidos de suporte em vez de um.
A rota que aponta para o appliance
Associe uma tabela de rotas à sub-rede de carga de trabalho e dê ao prefixo da filial um salto seguinte do tipo Virtual appliance com 10.0.0.4 como endereço. Use o endereço privado acessível do appliance, nunca o seu ponto de entrada público de VPN. O salto seguinte tem de ser um endereço que a sub-rede de carga de trabalho já consiga alcançar. Deixe o resto do encaminhamento da carga de trabalho em paz, a menos que tenha decidido deliberadamente substituir a rota predefinida.
Mantenha o appliance na sua própria sub-rede e certifique-se de que a rota que envia o tráfego da filial para o appliance não captura também o caminho de saída do próprio appliance. Um laço assim parece um túnel saudável sem respostas, e é algo muito desagradável de depurar às 2 da manhã.
O sinalizador da NIC que todos esquecem
O Azure tem uma definição de encaminhamento de IP por NIC, e está desativada por predefinição. Existe porque uma NIC que encaminha recebe pacotes endereçados a outra coisa, e descartá-los em silêncio é a predefinição segura para todos os outros.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true ativa-a para uma interface. As orientações da Microsoft sobre o encaminhamento na NIC exigem a definição em cada NIC ligada que encaminhe tráfego, por isso um appliance de uma só NIC continua a precisar dela nessa NIC.
O sinalizador não é uma rota nem uma regra de firewall. Ativá-lo concede permissão e nada mais.
O que o convidado faz com o pacote desencriptado
Quando o túnel termina, a pilha do próprio appliance toma a decisão seguinte. Num convidado Linux, o encaminhamento IPv4 é uma definição de execução, e sysctl -w net.ipv4.ip_forward=1 dura até ao próximo arranque. Guarde-a num ficheiro em /etc/sysctl.d/ em vez disso. Um appliance de fornecedor tem o seu equivalente, e as instruções de Linux coladas numa plataforma de fornecedor normalmente não fazem absolutamente nada.
A política de firewall do convidado é novamente separada, tal como o grupo de segurança de rede da carga de trabalho. Permitir UDP 500 e 4500 para o endereço público da VM protege o túnel; não diz nada sobre se um pedido de filial desencriptado pode alcançar uma porta da carga de trabalho.
Siga um pedido e a sua resposta
Escolha um fluxo permitido e siga-o de ponta a ponta. A filial precisa de uma rota para 10.0.10.0/24 através da ligação ao site, o appliance precisa de um caminho de entrega para a sub-rede de carga de trabalho, e a sub-rede de carga de trabalho precisa de uma rota de regresso à filial.
Decida cedo se o desenho preserva o endereço de origem da filial ou o traduz. O NAT altera o que a carga de trabalho vê, por isso as suas regras de acesso devem descrever o modelo que realmente escolheu e não um endereço de gateway suposto.
Um aperto de mão bem-sucedido prova um elo dessa cadeia. O caminho está completo quando a resposta regressa pelo mesmo appliance e a política da própria carga de trabalho o permite.