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

En FortiGate bak NAT kan eie 10.0.0.2 på WAN-grensesnittet sitt, mens internett presenterer den som 198.51.100.40, og begge tallene er reelle. Adressen enheten binder til, og identiteten den sender under IKE-autentisering, er separate valg, tatt i separate felt, for separate mottakere. NAT skriver om den ytre adresseringen på veien; det skriver ikke om en autentisert identitet til det den fjerne peer forventer. De fleste feil i fase 1 i denne formen kommer av å sette riktig verdi i feil felt.

Tre verdier, tre eiere

Start med å navngi de tre verdiene og hvem som eier hver. local-gw er adressen FortiGate bruker som kilde for IKE på det eksterne grensesnittet, og den må være en adresse enheten faktisk har. Det offentlige endepunktet er NAT-enhetens adresse, og eies av den som utfører oversettelsen. IKE-identiteten er en streng peer sammenligner med sin egen konfigurasjon, og den trenger slett ikke være en IP-adresse.

Feltnavnene er nære nok til å friste til utskifting, og det er fellen. localid og localid-type beskriver identifikasjon; local-gw beskriver lokal binding.

Et eksempel gjør forskjellen konkret. På FortiGate åpner du config vpn ipsec phase1-interface, deretter set interface "wan1" og set local-gw 10.0.0.2 — en adresse boksen eier, og det er det som får IKE-socketen til å binde riktig. La local-gw stå på 0.0.0.0 og grensesnittadressen brukes, noe som vanligvis er det samme, men mindre eksplisitt. Ikke sett local-gw til 198.51.100.40, fordi enheten ikke eier den adressen, og socketen vil ikke binde til den. Å få to verdier til å se like ut på papiret er ikke en konfigurasjon.

Trinn 1: velg identiteten peer vil godta

Nå identiteten, som er et annet valg. set localid tar verdien peer vil sammenligne, og set localid-type forteller FortiGate hvordan den skal tolkes: en adresse, et FQDN, et bruker-FQDN eller en nøkkel-ID. Med auto utleder enheten den, vanligvis fra adressen til det utgående grensesnittet, som er nøyaktig verdien en NAT-enhet er i ferd med å endre.

Den utledningen er grunnen til at en eksplisitt identitet er viktig i denne topologien. Hvis peer forventer en adresseidentitet, sett localid-type address og localid til den offentlige adressen peer vil se, og bekreft deretter at peer godtar den verdien som identitet og ikke som rutingmål. Hvis peer forventer et FQDN, bruk localid-type fqdn og navnet den ble konfigurert med. Bekreft hva som faktisk ble sendt med diagnose vpn ike gateway list, som viser gateway-tilstand og identifikatorene som brukes, ikke det du hadde tenkt å skrive. Ikke anta at et identitetstype-alternativ godtar en vilkårlig ikke-lokal adresse; sjekk først den dokumenterte semantikken i utgivelsen.

Trinn 2: videresend UDP 500 og 4500 til enheten

Den tredje verdien tilhører NAT-enheten, og det er den folk glemmer å sjekke. Det offentlige endepunktet må videresende UDP 500 og UDP 4500 til FortiGate, fordi NAT-T-deteksjon og den innkapslede ESP-en som følger begge avhenger av at disse portene kommer inn. Denne utformingen forutsetter en en-til-en-mapping; portbasert deling av én offentlig adresse mellom flere peers er en annen topologi med andre grenser.

Bekreft videresendingen med en opptak i stedet for et håp: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 viser om pakker kommer inn og om svar går ut.

Google Cloud VPN dokumenterer en-til-en NAT med NAT-T som det støttede arrangementet for en peer bak NAT, og det er begrensningen som må designes mot hvis den fjerne enden er en Cloud VPN-gateway. En-til-mange eller portbasert deling er ikke den samme støttede topologien, og ingen mengde lokal identitetsjustering endrer det. Hvis den fjerne siden er en annen enhet, definerer dens egen dokumentasjon hva den godtar som identitet og om den tåler en oversatt peer-adresse. Les det før du endrer et lokalt felt, fordi den lokale siden ikke kan forhandle en regel den fjerne siden ikke implementerer.

Trinn 3: sjekk hva fase 1 ikke løser

NAT-traversering får tunnelen opp, identitetsenighet avgjør om peer godtar den, og ruting av indre prefiks avgjør hva som faktisk passerer. En korrekt lokal ID kan ikke levere en manglende statisk rute eller en manglende trafikkvelger.

Så verifiser i lag. get vpn ipsec tunnel details viser om tunnelen er oppe og hvilke velgere som ble forhandlet, og avvik mellom det konfigurerte fjerne subnettet og den forhandlede velgeren er et ruteproblem i fase 2-kostyme. execute vpn ike gateway clear tvinger ny forhandling, så du tester gjeldende konfigurasjon og ikke en sesjon etablert før din siste endring. Send deretter trafikk til en vert i det fjerne prefikset og bekreft at tellerne beveger seg, fordi en tunnel som er oppe og ikke slipper noe gjennom ser identisk ut med en som fungerer, helt til du sjekker.

Hold de tre verdiene på ett sted i notatene dine: den lokale adressen enheten eier, det offentlige endepunktet NAT-enheten presenterer, og identitetsstrengen peer forventer. De endres av ulike grunner og til ulike tider.

En omnummerering av NAT-enheten er ikke grunn til å røre local-gw på FortiGate, og en identitetsendring er ikke grunn til å omnummerere noe. Å blande de to er hvordan en fungerende tunnel bygges på nytt i et urelatert vedlikeholdsvindu. Cloud VPNs NAT-veiledning er referansen for den støttede topologien på den siden.

Testen som avgjør det, er kjedelig og rask: ta opp på det eksterne grensesnittet, bekreft at UDP 500 og 4500 kommer fra peer, bekreft at identiteten i IKE-utvekslingen samsvarer med det peer var konfigurert til å forvente, og bekreft deretter at de forhandlede velgerne dekker subnettene du bryr deg om. Hvis den første sjekken feiler, er NAT-enheten den mistenkte. Hvis den andre feiler, er det identitetsfeltene. Hvis den tredje feiler, var verken NAT eller identitet noen gang problemet.