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

Un FortiGate detrás de NAT pode ter 10.0.0.2 na súa interface WAN mentres internet o presenta como 198.51.100.40, e ambos os números son reais. O enderezo ao que se vincula o dispositivo e a identidade que envía durante a autenticación IKE son decisións separadas, tomadas en campos separados, para audiencias separadas. NAT reescribe o direccionamento exterior ao pasar; non reescribe unha identidade autenticada no que espera o peer remoto. A maioría dos fallos de fase 1 nesta forma veñen de poñer o valor correcto no campo equivocado.

Tres valores, tres propietarios

Comece nomeando os tres valores e quen posúe cada un. local-gw é o enderezo que FortiGate usa como orixe de IKE na súa interface externa, e debe ser un enderezo que o dispositivo realmente teña. O extremo público é o enderezo do dispositivo NAT, e posúeo quen realiza a tradución. A identidade IKE é unha cadea que o peer compara coa súa propia configuración, e non é necesario que sexa un enderezo IP en absoluto.

Os nomes dos campos son o bastante parecidos como para invitar á substitución, e esa é a trampa. localid e localid-type describen a identificación; local-gw describe a vinculación local.

Un exemplo fai concreta a distinción. No FortiGate, abra config vpn ipsec phase1-interface, logo set interface "wan1" e set local-gw 10.0.0.2 — un enderezo que a caixa posúe, e iso é o que fai que o socket IKE se vincule correctamente. Deixe local-gw en 0.0.0.0 e úsase o enderezo da interface, que adoita ser o mesmo pero menos explícito. Non poña local-gw en 198.51.100.40, porque o dispositivo non posúe ese enderezo e o socket non se vinculará a el. Facer que dous valores parezan iguais sobre o papel non é unha configuración.

Paso 1: escolla a identidade que o peer aceptará

Agora a identidade, que é unha decisión distinta. set localid toma o valor que o peer comparará, e set localid-type dille ao FortiGate como interpretalo: un enderezo, un FQDN, un FQDN de usuario ou un ID de clave. Con auto o dispositivo derívaa, normalmente do enderezo da interface de saída, que é exactamente o valor que un dispositivo NAT está a piques de cambiar.

Esa derivación é a razón pola que unha identidade explícita importa nesta topoloxía. Se o peer espera unha identidade de enderezo, poña localid-type address e localid no enderezo público que o peer verá, e logo confirme que o peer acepta ese valor como identidade e non como destino de encamiñamento. Se o peer espera un FQDN, use localid-type fqdn e o nome co que se configurou. Verifique que se enviou realmente con diagnose vpn ike gateway list, que mostra o estado da pasarela e os identificadores en uso, non o que pensaba escribir. Non asuma que unha opción de tipo de identidade acepta un enderezo non local arbitrario; comprobe primeiro a semántica documentada da versión.

Paso 2: reenvíe UDP 500 e 4500 ao dispositivo

O terceiro valor pertence ao dispositivo NAT, e é o que a xente esquece comprobar. O extremo público debe reenviar UDP 500 e UDP 4500 ao FortiGate, porque a detección de NAT-T e o ESP encapsulado que segue dependen ambos de que cheguen eses portos. Este deseño asume unha correspondencia un a un; compartir un único enderezo público por portos entre varios peers é outra topoloxía con outros límites.

Confirme o reenvío cunha captura e non cunha esperanza: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 mostra se chegan paquetes e se saen respostas.

Google Cloud VPN documenta NAT un a un con NAT-T como a disposición admitida para un peer detrás de NAT, e esa é a restrición coa que hai que deseñar se o extremo remoto é unha pasarela de Cloud VPN. Compartir un a moitos ou por portos non é a mesma topoloxía admitida, e ningún axuste local de identidade o cambia. Se o lado remoto é outro dispositivo, a súa propia documentación define que aceptará como identidade e se tolera un enderezo de peer traducido. Léao antes de cambiar un campo local, porque o lado local non pode negociar unha regra que o lado remoto non implementa.

Paso 3: comprobe que non resolve a fase 1

O percorrido NAT levanta o túnel, o acordo de identidade decide se o peer o acepta, e o encamiñamento do prefixo interno decide que cruza realmente. Un ID local correcto non pode suplir unha ruta estática ausente nin un selector de tráfico ausente.

Así que verifique por capas. get vpn ipsec tunnel details mostra se o túnel está levantado e que selectores se negociaron, e unha discrepancia entre a subrede remota configurada e o selector negociado é un problema de encamiñamento con disfrace de fase 2. execute vpn ike gateway clear forza unha renegociación, así que proba a configuración actual e non unha sesión establecida antes do seu último cambio. Logo envíe tráfico a un host do prefixo remoto e confirme que os contadores se moven, porque un túnel levantado que non pasa nada é idéntico a un que funciona ata que o comproba.

Manteña os tres valores nun só lugar nas súas notas: o enderezo local que posúe o dispositivo, o extremo público que presenta o dispositivo NAT e a cadea de identidade que espera o peer. Cambian por motivos distintos e en momentos distintos.

Renumerar o dispositivo NAT non é motivo para tocar o local-gw do FortiGate, e un cambio de identidade non é motivo para renumerar nada. Mesturar as dúas cousas é como se reconstrúe un túnel que funciona durante unha ventá de mantemento non relacionada. A guía de NAT de Cloud VPN é a referencia para a topoloxía admitida nese lado.

A proba que o resolve é aburrida e rápida: capture na interface externa, confirme que UDP 500 e 4500 chegan do peer, confirme que a identidade no intercambio IKE coincide co que o peer estaba configurado para esperar, e logo confirme que os selectores negociados cobren as subredes que lle importan. Se a primeira comprobación falla, o sospeitoso é o dispositivo NAT. Se falla a segunda, son os campos de identidade. Se falla a terceira, nin NAT nin identidade foron nunca o problema.