FortiGate atrás de NAT: local-gw, localid e o IP público

Um FortiGate atrás de NAT pode possuir 10.0.0.2 na sua interface WAN enquanto a internet o apresenta como 198.51.100.40, e ambos os números são reais. O endereço ao qual o equipamento se liga e a identidade que envia durante a autenticação IKE são escolhas separadas, feitas em campos separados, para públicos separados. O NAT reescreve o endereçamento externo à passagem; não reescreve uma identidade autenticada naquilo que o peer remoto espera. A maioria das falhas de fase 1 nesta forma vem de colocar o valor certo no campo errado.

Três valores, três proprietários

Comece por nomear os três valores e quem possui cada um. local-gw é o endereço que o FortiGate usa como origem de IKE na interface externa, e tem de ser um endereço que o equipamento realmente tenha. O endpoint público é o endereço do equipamento NAT, e pertence a quem realiza a tradução. A identidade IKE é uma cadeia que o peer compara com a sua própria configuração, e não precisa de ser um endereço IP.

Os nomes dos campos são suficientemente próximos para convidar à substituição, e essa é a armadilha. localid e localid-type descrevem a identificação; local-gw descreve a ligação local.

Um exemplo torna a distinção concreta. No FortiGate, abra config vpn ipsec phase1-interface, depois set interface "wan1" e set local-gw 10.0.0.2 — um endereço que a caixa possui, e é isso que faz o socket IKE ligar-se com sucesso. Deixe local-gw em 0.0.0.0 e é usado o endereço da interface, que costuma ser o mesmo mas menos explícito. Não defina local-gw para 198.51.100.40, porque o equipamento não possui esse endereço e o socket não se ligará a ele. Fazer dois valores parecerem iguais no papel não é uma configuração.

Passo 1: escolha a identidade que o peer aceitará

Agora a identidade, que é uma decisão diferente. set localid toma o valor que o peer comparará, e set localid-type diz ao FortiGate como interpretá-lo: um endereço, um FQDN, um FQDN de utilizador ou um ID de chave. Com auto o equipamento deriva-a, normalmente do endereço da interface de saída, que é exatamente o valor que um equipamento NAT está prestes a alterar.

Essa derivação é a razão pela qual uma identidade explícita importa nesta topologia. Se o peer espera uma identidade de endereço, defina localid-type address e localid para o endereço público que o peer verá, e depois confirme que o peer aceita esse valor como identidade e não como destino de encaminhamento. Se o peer espera um FQDN, use localid-type fqdn e o nome com que foi configurado. Verifique o que foi realmente enviado com diagnose vpn ike gateway list, que mostra o estado do gateway e os identificadores em uso, não o que pensava escrever. Não assuma que uma opção de tipo de identidade aceita um endereço não local arbitrário; verifique primeiro a semântica documentada da versão.

Passo 2: encaminhe UDP 500 e 4500 para o equipamento

O terceiro valor pertence ao equipamento NAT, e é aquele que as pessoas se esquecem de verificar. O endpoint público tem de encaminhar UDP 500 e UDP 4500 para o FortiGate, porque a deteção de NAT-T e o ESP encapsulado que se segue dependem ambos da chegada dessas portas. Este desenho assume um mapeamento um para um; partilhar um único endereço público por portas entre vários peers é outra topologia com outros limites.

Confirme o encaminhamento com uma captura e não com uma esperança: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 mostra se os pacotes chegam e se as respostas saem.

O Google Cloud VPN documenta NAT um para um com NAT-T como a disposição suportada para um peer atrás de NAT, e essa é a restrição a considerar se a extremidade remota for um gateway Cloud VPN. A partilha um para muitos ou por portas não é a mesma topologia suportada, e nenhum ajuste local de identidade o muda. Se o lado remoto for outro equipamento, a sua própria documentação define o que aceitará como identidade e se tolera um endereço de peer traduzido. Leia isso antes de alterar um campo local, porque o lado local não pode negociar uma regra que o lado remoto não implementa.

Passo 3: verifique o que a fase 1 não resolve

A travessia NAT levanta o túnel, o acordo de identidade decide se o peer o aceita, e o encaminhamento do prefixo interno decide o que passa realmente. Um ID local correto não consegue fornecer uma rota estática em falta nem um seletor de tráfego em falta.

Por isso, verifique por camadas. get vpn ipsec tunnel details mostra se o túnel está levantado e que seletores foram negociados, e uma divergência entre a sub-rede remota configurada e o seletor negociado é um problema de encaminhamento com fato de fase 2. execute vpn ike gateway clear força uma renegociação, por isso testa a configuração atual e não uma sessão estabelecida antes da sua última alteração. Depois envie tráfego para um host no prefixo remoto e confirme que os contadores se movem, porque um túnel levantado que não passa nada é idêntico a um funcional até verificar.

Mantenha os três valores num só lugar nas suas notas: o endereço local que o equipamento possui, o endpoint público que o equipamento NAT apresenta e a cadeia de identidade que o peer espera. Mudam por razões diferentes e em momentos diferentes.

Renumerar o equipamento NAT não é motivo para tocar no local-gw do FortiGate, e uma mudança de identidade não é motivo para renumerar nada. Misturar as duas coisas é como um túnel funcional é reconstruído durante uma janela de manutenção não relacionada. O guia de NAT do Cloud VPN é a referência para a topologia suportada desse lado.

O teste que resolve a questão é aborrecido e rápido: capture na interface externa, confirme que UDP 500 e 4500 chegam do peer, confirme que a identidade na troca IKE corresponde ao que o peer estava configurado para esperar, e depois confirme que os seletores negociados cobrem as sub-redes que lhe importam. Se a primeira verificação falhar, o suspeito é o equipamento NAT. Se falhar a segunda, são os campos de identidade. Se falhar a terceira, nem NAT nem identidade foram alguma vez o problema.