Dois IP públicos numa única VM VPN do Azure: qual faz o quê

Dois IP públicos numa única VM VPN do Azure criam uma expectativa que raramente se verifica: o endereço a que os clientes se ligam será também o endereço que os sites veem. Três decisões independentes produzem esse resultado, e apenas a primeira diz respeito ao ouvinte do túnel. A segunda é a origem do convidado usada para o tráfego de cliente reencaminhado, e a terceira é o método de saída do Azure aplicado a essa origem. Altere uma e as outras duas ficam onde estavam, por isso decida cada uma explicitamente.

Decisão 1: onde o túnel termina

Um IP público do Azure está associado a uma configuração de IP privado na NIC; não é um endereço que se adicione dentro do sistema operativo convidado. Leia a correspondência em vez de a assumir: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Qualquer endereço privado que essa consulta devolva é o que o convidado deve realmente ter.

Uma NIC pode transportar várias configurações de IP, por isso dois endereços públicos não exigem duas NIC. Se o desenho usar mesmo duas NIC, cada uma traz as suas próprias rotas de convidado e saltos seguintes, e acrescentou uma decisão de encaminhamento em vez de a simplificar.

Para um serviço com uma ligação local explícita, ligue ao endereço privado real do convidado, nunca ao marcador público. Um ouvinte que aceita todos os endereços recebe tráfego por cada configuração de IP que o alcança, por isso restrinja a entrada com o grupo de segurança de rede e a firewall do anfitrião em vez de esperar que a ordem de ligação decida.

Decisão 2: que origem usa o cliente reencaminhado

Depois de a gateway desencriptar um pedido do cliente, o pacote que reencaminha é diferente do que chegou ao ouvinte VPN. O convidado precisa de reencaminhamento ativo, de uma política de firewall que permita o fluxo e de um endereço de origem que o desenho da nuvem permita. Se traduzir o endereço interno do cliente, é essa origem traduzida que o Azure avaliará, não o endereço interno do cliente.

Uma regra SNAT estreita pode escolher uma origem privada do convidado, mas não pode sobrepor-se a uma tradução posterior do Azure. Escolha SNAT quando precisar de responsabilização por cliente dentro da VM; dispense-o quando o desenho de saída da sub-rede já proporciona uma origem pública estável e uma segunda tradução só acrescentaria estado.

Decisão 3: que método de saída do Azure vence

A Microsoft documentaa ordem de precedência de saída: uma rota aplicável para um dispositivo ou gateway tem prioridade, e a conectividade da sub-rede através do NAT Gateway tem prioridade sobre um IP público ao nível da instância no caminho relevante. Essa ordem é a razão pela qual traduzir para 10.20.0.5 não prova que um site verá 198.51.100.20. Leia a tabela de rotas efetiva, a associação do NAT Gateway e o IP público da NIC em conjunto antes de aceitar o desenho de saída.

Mantenhaa definição de reencaminhamento da NIC do Azureseparada do reencaminhamento no Linux. O indicador da nuvem permite pacotes cuja origem ou destino não está atribuído à NIC; não ativa net.ipv4.ip_forward, e a definição do convidado não concede a permissão da nuvem.

O socket do túnel tem a sua própria decisão de origem

O Address do WireGuard em wg-quick atribui um endereço à interface WireGuard; não é uma instrução de ligação UDP externa. A origem do socket cifrado segue a tabela de rotas, por isso uma rota de política ou uma segunda rota predefinida pode movê-la sem tocar no endereço da interface.OpenVPN: a opção local e o UDP multihome comportam-se da mesma forma: dizem respeito ao ouvinte e às suas respostas, não à origem de internet de cada cliente reencaminhado.

Preserve a rota da camada inferior que transporta o túnel e confirme que o cliente continua a receber respostas autenticadas a partir da disposição de entrada esperada. Não confie na ordem da lista de endereços como política permanente de seleção de origem, porque o próximo endereço acrescentado à NIC pode alterar qual vence.

O que aceitar, e por que ordem

Aceite três resultados em separado. Primeiro, um cliente externo alcança a entrada VPN pretendida. Segundo, um novo pedido permitido desse cliente VPN sai pela saída de internet documentada. Terceiro, os caminhos de escuta e reencaminhamento não pretendidos continuam negados. Registe as correspondências de público para privado e os responsáveis de convidado e de nuvem de cada decisão no mesmo local.

Um túnel bem-sucedido prova apenas a primeira parte. Teste a saída com um fluxo novo, porque uma ligação em cache pode continuar a usar a origem antiga muito depois de a rota mudar.