FortiGate bak NAT: local-gw, localid og den offentlege IP-en

Ein FortiGate bak NAT kan eige 10.0.0.2 på WAN-grensesnittet sitt, medan internett presenterer han som 198.51.100.40, og begge tala er reelle. Adressa eininga bind til, og identiteten ho sender under IKE-autentisering, er separate val, tekne i separate felt, for separate mottakarar. NAT skriv om den ytre adresseringa på vegen; det skriv ikkje om ein autentisert identitet til det den fjerne peer forventar. Dei fleste feil i fase 1 i denne forma kjem av å setje rett verdi i feil felt.

Tre verdiar, tre eigarar

Start med å namngje dei tre verdiane og kven som eig kvar. local-gw er adressa FortiGate brukar som kjelde for IKE på det eksterne grensesnittet, og ho må vere ei adresse eininga faktisk har. Det offentlege endepunktet er adressa til NAT-eininga, og vert eigd av den som utfører omsetjinga. IKE-identiteten er ein streng peer samanliknar med si eiga konfigurasjon, og han treng slett ikkje vere ei IP-adresse.

Feltnamna er nære nok til å freiste til utskifting, og det er fella. localid og localid-type skildrar identifikasjon; local-gw skildrar lokal binding.

Eit døme gjer skilnaden konkret. På FortiGate opnar du config vpn ipsec phase1-interface, deretter set interface "wan1" og set local-gw 10.0.0.2 — ei adresse boksen eig, og det er det som får IKE-socketen til å binde rett. Lat local-gw stå på 0.0.0.0 og grensesnittadressa vert brukt, noko som vanlegvis er det same, men mindre eksplisitt. Ikkje set local-gw til 198.51.100.40, fordi eininga ikkje eig den adressa, og socketen vil ikkje binde til henne. Å få to verdiar til å sjå like ut på papiret er ikkje ein konfigurasjon.

Steg 1: vel identiteten peer vil godta

No identiteten, som er eit anna val. set localid tek verdien peer vil samanlikne, og set localid-type fortel FortiGate korleis han skal tolkast: ei adresse, eit FQDN, eit brukar-FQDN eller ein nøkkel-ID. Med auto leier eininga han ut, vanlegvis frå adressa til det utgåande grensesnittet, som er nøyaktig verdien ei NAT-eining er i ferd med å endre.

Den utleiinga er grunnen til at ein eksplisitt identitet er viktig i denne topologien. Viss peer forventar ein adresseidentitet, set localid-type address og localid til den offentlege adressa peer vil sjå, og stadfest deretter at peer godtek den verdien som identitet og ikkje som rutingmål. Viss peer forventar eit FQDN, bruk localid-type fqdn og namnet det vart konfigurert med. Stadfest kva som faktisk vart sendt med diagnose vpn ike gateway list, som viser gateway-tilstand og identifikatorane som vert brukte, ikkje det du hadde tenkt å skrive. Ikkje gå ut frå at eit identitetstype-alternativ godtek ei vilkårleg ikkje-lokal adresse; sjekk først den dokumenterte semantikken i utgåva.

Steg 2: vidaresend UDP 500 og 4500 til eininga

Den tredje verdien høyrer til NAT-eininga, og det er den folk gløymer å sjekke. Det offentlege endepunktet må vidaresende UDP 500 og UDP 4500 til FortiGate, fordi NAT-T-deteksjon og den innkapsla ESP-en som følgjer begge er avhengige av at desse portane kjem inn. Denne utforminga føreset ein ein-til-ein-mapping; portbasert deling av éi offentleg adresse mellom fleire peers er ein annan topologi med andre grenser.

Stadfest vidaresendinga med eit opptak i staden for eit håp: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 viser om pakkar kjem inn og om svar går ut.

Google Cloud VPN dokumenterer ein-til-ein-NAT med NAT-T som det støtta arrangementet for ein peer bak NAT, og det er avgrensinga som må designast mot viss den fjerne enden er ein Cloud VPN-gateway. Ein-til-mange eller portbasert deling er ikkje den same støtta topologien, og inga mengd lokal identitetsjustering endrar det. Viss den fjerne sida er eit anna apparat, definerer si eiga dokumentasjon kva det godtek som identitet og om det toler ei omsett peer-adresse. Les det før du endrar eit lokalt felt, fordi den lokale sida ikkje kan forhandle ein regel den fjerne sida ikkje implementerer.

Steg 3: sjekk kva fase 1 ikkje løyser

NAT-traversering får tunnelen opp, identitetseining avgjer om peer godtek han, og ruting av indre prefiks avgjer kva som faktisk passerer. Ein korrekt lokal ID kan ikkje levere ei manglande statisk rute eller ein manglande trafikkveljar.

Så verifiser i lag. get vpn ipsec tunnel details viser om tunnelen er oppe og kva veljarar som vart forhandla, og avvik mellom det konfigurerte fjerne subnettet og den forhandla veljaren er eit ruteproblem i fase 2-kostyme. execute vpn ike gateway clear tvingar ny forhandling, så du testar gjeldande konfigurasjon og ikkje ein sesjon etablert før den siste endringa di. Send deretter trafikk til ein vert i det fjerne prefikset og stadfest at teljarane flyttar seg, fordi ein tunnel som er oppe og ikkje slepp noko gjennom ser identisk ut med ein som fungerer, heilt til du sjekkar.

Hald dei tre verdiane på eitt stad i notata dine: den lokale adressa eininga eig, det offentlege endepunktet NAT-eininga presenterer, og identitetsstrengen peer forventar. Dei endrar seg av ulike grunnar og til ulike tider.

Ei omnummerering av NAT-eininga er ikkje grunn til å røre local-gw på FortiGate, og ei identitetsendring er ikkje grunn til å omnummerere noko. Å blande dei to er korleis ein fungerande tunnel vert bygd på nytt i eit urelatert vedlikehaldsvindauge. Cloud VPNs NAT-rettleiing er referansen for den støtta topologien på den sida.

Testen som avgjer det, er keisam og rask: ta opp på det eksterne grensesnittet, stadfest at UDP 500 og 4500 kjem frå peer, stadfest at identiteten i IKE-utvekslinga samsvarar med det peer var konfigurert til å forvente, og stadfest deretter at dei forhandla veljarane dekkjer subneta du bryr deg om. Viss den første sjekken feilar, er NAT-eininga den mistenkte. Viss den andre feilar, er det identitetsfelta. Viss den tredje feilar, var korkje NAT eller identitet nokon gong problemet.