FortiGate darrere de NAT: local-gw, localid i la IP pública

Un FortiGate darrere de NAT pot tenir 10.0.0.2 a la seva interfície WAN mentre internet el presenta com a 198.51.100.40, i tots dos números són reals. L'adreça a la qual el dispositiu s'enllaça i la identitat que envia durant l'autenticació IKE són decisions separades, preses en camps separats, per a públics separats. NAT reescriu l'adreçament exterior en passar; no reescriu una identitat autenticada en allò que espera el peer remot. La majoria de fallades de fase 1 en aquesta forma venen de posar el valor correcte al camp equivocat.

Tres valors, tres propietaris

Comenceu nomenant els tres valors i qui posseeix cadascun. local-gw és l'adreça que el FortiGate fa servir com a origen d'IKE a la interfície externa, i ha de ser una adreça que el dispositiu realment tingui. L'extrem públic és l'adreça del dispositiu NAT, propietat de qui fa la traducció. La identitat IKE és una cadena que el peer compara amb la seva pròpia configuració, i no cal que sigui cap adreça IP.

Els noms dels camps són prou propers per convidar a la substitució, i aquesta és la trampa. localid i localid-type descriuen la identificació; local-gw descriu l'enllaç local.

Un exemple fa la distinció concreta. Al FortiGate, obriu config vpn ipsec phase1-interface, després set interface "wan1" i set local-gw 10.0.0.2 — una adreça que la caixa posseeix, i això és el que fa que el sòcol IKE s'enlli correctament. Deixeu local-gw a 0.0.0.0 i s'utilitza l'adreça de la interfície, que normalment és el mateix però menys explícit. No poseu local-gw a 198.51.100.40, perquè el dispositiu no posseeix aquesta adreça i el sòcol no s'hi enllaçarà. Fer que dos valors semblin iguals sobre el paper no és una configuració.

Pas 1: trieu la identitat que el peer acceptarà

Ara la identitat, que és una decisió diferent. set localid pren el valor que el peer compararà, i set localid-type diu al FortiGate com interpretar-lo: una adreça, un FQDN, un FQDN d'usuari o un ID de clau. Amb auto el dispositiu la deriva, normalment de l'adreça de la interfície de sortida, que és exactament el valor que un dispositiu NAT està a punt de canviar.

Aquesta derivació és la raó per la qual una identitat explícita importa en aquesta topologia. Si el peer espera una identitat d'adreça, poseu localid-type address i localid a l'adreça pública que el peer veurà, i després confirmeu que el peer accepta aquest valor com a identitat i no com a objectiu d'encaminament. Si el peer espera un FQDN, feu servir localid-type fqdn i el nom amb què es va configurar. Verifiqueu què s'ha enviat realment amb diagnose vpn ike gateway list, que mostra l'estat de la passarel·la i els identificadors en ús, no el que pensàveu escriure. No assumiu que una opció de tipus d'identitat accepta una adreça no local arbitrària; comproveu primer la semàntica documentada de la versió.

Pas 2: reenvieu UDP 500 i 4500 al dispositiu

El tercer valor pertany al dispositiu NAT, i és el que la gent oblida comprovar. L'extrem públic ha de reenviar UDP 500 i UDP 4500 al FortiGate, perquè la detecció de NAT-T i l'ESP encapsulat que segueix depenen tots dos que aquests ports arribin. Aquest disseny assumeix una correspondència un a un; compartir una única adreça pública per ports entre diversos peers és una topologia diferent amb límits diferents.

Confirmeu el reenviament amb una captura i no amb una esperança: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 mostra si els paquets arriben i si les respostes surten.

Google Cloud VPN documenta NAT un a un amb NAT-T com la disposició suportada per a un peer darrere de NAT, i aquesta és la restricció amb què cal dissenyar si l'extrem remot és una passarel·la Cloud VPN. Compartir un a molts o per ports no és la mateixa topologia suportada, i cap ajustament local d'identitat ho canvia. Si el costat remot és un altre aparell, la seva pròpia documentació defineix què acceptarà com a identitat i si tolera una adreça de peer traduïda. Llegiu-ho abans de canviar un camp local, perquè el costat local no pot negociar una regla que el costat remot no implementa.

Pas 3: comproveu què no resol la fase 1

El pas de NAT aixeca el túnel, l'acord d'identitat decideix si el peer l'accepta, i l'encaminament de prefix interior decideix què travessa realment. Un ID local correcte no pot proporcionar una ruta estàtica que falta ni un selector de trànsit que falta.

Per tant, verifiqueu per capes. get vpn ipsec tunnel details mostra si el túnel està aixecat i quins selectors s'han negociat, i una discrepància entre la subxarxa remota configurada i el selector negociat és un problema d'encaminament amb vestit de fase 2. execute vpn ike gateway clear obliga a renegociar, així que proveu la configuració actual i no una sessió establerta abans del vostre darrer canvi. Després envieu trànsit a un host del prefix remot i confirmeu que els comptadors es mouen, perquè un túnel aixecat que no passa res és idèntic a un de funcional fins que el comproveu.

Manteniu els tres valors en un sol lloc a les notes: l'adreça local que posseeix el dispositiu, l'extrem públic que presenta el dispositiu NAT i la cadena d'identitat que espera el peer. Canvien per motius diferents i en moments diferents.

Renumerar el dispositiu NAT no és motiu per tocar local-gw del FortiGate, i un canvi d'identitat no és motiu per renumerar res. Barrejar les dues coses és com es reconstrueix un túnel funcionant durant una finestra de manteniment no relacionada. La guia de NAT de Cloud VPN és la referència per a la topologia suportada en aquell costat.

La prova que ho decideix és avorrida i ràpida: captureu a la interfície externa, confirmeu que UDP 500 i 4500 arriben del peer, confirmeu que la identitat en l'intercanvi IKE coincideix amb el que el peer estava configurat per esperar, i després confirmeu que els selectors negociats cobreixen les subxarxes que us importen. Si la primera comprovació falla, el sospitós és el dispositiu NAT. Si falla la segona, són els camps d'identitat. Si falla la tercera, ni NAT ni identitat no havien estat mai el problema.