FortiGate agter NAT: local-gw, localid en die publieke IP

'n FortiGate agter NAT kan 10.0.0.2 op sy WAN-koppelvlak besit, terwyl die internet dit as 198.51.100.40 aanbied, en albei getalle is werklik. Die adres waaraan die toestel bind en die identiteit wat dit tydens IKE-verifikasie stuur, is afsonderlike keuses, in afsonderlike velde, vir afsonderlike gehore. NAT herskryf die buitenste adressering op pad verby; dit herskryf nie 'n geverifieerde identiteit na wat die verre eweknie verwag nie. Die meeste fase 1-foute in hierdie vorm kom daarvan dat die regte waarde in die verkeerde veld gesit word.

Drie waardes, drie eienaars

Begin deur die drie waardes en elkeen se eienaar te benoem. local-gw is die adres wat die FortiGate gebruik om IKE op sy eksterne koppelvlak te source, en dit moet 'n adres wees wat die toestel werklik het. Die publieke eindpunt is die NAT-toestel se adres, wat deur die een of ander vertaler besit word. Die IKE-identiteit is 'n string wat die eweknie teen sy eie konfigurasie pas, en dit hoef glad nie 'n IP-adres te wees nie.

Die veldname is naby genoeg om vervanging uit te lok, en dit is die lokval. localid en localid-type beskryf identifikasie; local-gw beskryf plaaslike binding.

'n Deurloop maak die onderskeid konkreet. Op die FortiGate, maak config vpn ipsec phase1-interface oop, dan set interface "wan1" en set local-gw 10.0.0.2 - 'n adres wat die boks besit, en dit is wat die IKE-sok suksesvol laat bind. Laat local-gw op 0.0.0.0 en die koppelvlakadres word gebruik, wat gewoonlik dieselfde ding is maar minder eksplisiet. Moet nie local-gw op 198.51.100.40 stel nie, want die toestel besit nie daardie adres nie en die sok sal nie daarby bind nie. Om twee waardes op papier gelyk te laat lyk, is nie 'n konfigurasie nie.

Stap 1: kies die identiteit wat die eweknie sal aanvaar

Nou die identiteit, wat 'n ander besluit is. set localid neem die waarde wat die eweknie sal vergelyk, en set localid-type vertel die FortiGate hoe om dit te interpreteer: 'n adres, 'n FQDN, 'n gebruiker-FQDN of 'n sleutel-ID. Met auto lei die toestel dit af, tipies van die uitgaande koppelvlakadres, wat presies die waarde is wat 'n NAT-toestel op die punt is om te verander.

Daardie afleiding is waarom 'n eksplisiete identiteit in hierdie topologie saak maak. As die eweknie 'n adresidentiteit verwag, stel localid-type address en localid op die publieke adres wat die eweknie sal sien, en bevestig dan dat die eweknie daardie waarde as 'n identiteit aanvaar eerder as as 'n roeteteiken. As die eweknie 'n FQDN verwag, gebruik localid-type fqdn en die naam waarmee dit gekonfigureer is. Verifieer wat werklik gestuur is met diagnose vpn ike gateway list, wat die gateway-toestand en die identifiers in gebruik wys eerder as wat jy bedoel het om te tik. Moenie aanvaar dat 'n identiteitstipe-opsie 'n arbitrere nie-plaaslike adres aanvaar nie; kyk eers na die release se gedokumenteerde semantiek.

Stap 2: stuur UDP 500 en 4500 na die toestel

Die derde waarde behoort aan die NAT-toestel, en dit is die een wat mense vergeet om na te gaan. Die publieke eindpunt moet UDP 500 en UDP 4500 na die FortiGate stuur, want NAT-T-opsporing en die ingekapselde ESP wat volg, hang albei daarvan af dat daardie poorte aankom. 'n Een-tot-een-kaart is wat hierdie ontwerp veronderstel; poortgebaseerde deel van 'n enkele publieke adres oor verskeie ewekniee is 'n ander topologie met ander beperkings.

Bevestig die stuur met 'n opname eerder as 'n hoop: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 wys of pakkette aankom en of antwoorde vertrek.

Google Cloud VPN dokumenteer een-tot-een NAT met NAT-T as die ondersteunde reelings vir 'n eweknie agter NAT, en dit is die beperking waarteen jy moet ontwerp as die verre kant 'n Cloud VPN-gateway is. Een-tot-baie of poortgebaseerde deel is nie dieselfde ondersteunde topologie nie, en geen hoeveelheid plaaslike identiteitsinstelling verander dit nie. As die verre kant 'n ander toestel is, bepaal sy eie dokumentasie wat hy as 'n identiteit sal aanvaar en of hy 'n vertaalde eweknie-adres duld. Lees dit voordat jy 'n plaaslike veld verander, want die plaaslike kant kan nie 'n reel beding wat die verre kant nie implementeer nie.

Stap 3: kyk wat fase 1 nie oplos nie

NAT-deurgang kry die tonnel op, identiteitsooreenkoms besluit of die eweknie dit aanvaar, en binnedoelwit-roetering besluit wat werklik deurgaan. 'n Korrekte plaaslike ID kan nie 'n ontbrekende statiese roete of 'n ontbrekende verkeerskeuse verskaf nie.

Verifieer dus in lae. get vpn ipsec tunnel details wys of die tonnel op is en watter keuses beding is, en 'n wanverhouding tussen die gekonfigureerde verre subnet en die bedingde keuse is 'n roeteringsprobleem in 'n fase 2-kostuum. execute vpn ike gateway clear forseer 'n heronderhandeling, so jy toets die huidige konfigurasie eerder as 'n sessie wat voor jou laaste verandering opgestel is. Stuur dan verkeer na 'n gasheer in die verre voorvoegsel en bevestig dat die tellers beweeg, want 'n tonnel wat op is en niks deurlaat nie lyk identies aan een wat werk totdat jy kyk.

Hou die drie waardes op een plek in jou notas: die plaaslike adres wat die toestel besit, die publieke eindpunt wat die NAT-toestel bied, en die identiteitsstring wat die eweknie verwag. Hulle verander om verskillende redes en op verskillende tye.

'n NAT-toestel-hernommering is nie 'n rede om aan die FortiGate se local-gw te raak nie, en 'n identiteitsverandering is nie 'n rede om enigiets te hernommer nie. Om die twee te meng, is hoe 'n werkende tonnel tydens 'n onverwante onderhoudsvenster herbou word. Die Cloud VPN NAT-riglyne is die verwysing vir die ondersteunde topologie aan daardie kant.

Die toets wat dit besleg, is vervelig en vinnig: neem op op die eksterne koppelvlak, bevestig dat UDP 500 en 4500 van die eweknie af aankom, bevestig dat die identiteit in die IKE-uitruiling ooreenstem met wat die eweknie gekonfigureer is om te verwag, en bevestig dan dat die bedingde keuses die subnette dek waaroor jy sorg. As die eerste toets misluk, is die NAT-toestel die verdagte. As die tweede misluk, is die identiteitsvelde. As die derde misluk, was nog NAT nog identiteit ooit die probleem.