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

En FortiGate bag NAT kan eje 10.0.0.2 på sin WAN-grænseflade, mens internettet præsenterer den som 198.51.100.40, og begge tal er reelle. Den adresse, enheden binder til, og den identitet, den sender under IKE-godkendelse, er separate valg, truffet i separate felter, for separate modtagere. NAT omskriver den ydre adressering på vejen forbi; det omskriver ikke en godkendt identitet til det, den fjerne peer forventer. De fleste fejl i fase 1 i denne form kommer af at sætte den rigtige værdi i det forkerte felt.

Tre værdier, tre ejere

Start med at navngive de tre værdier og hvem der ejer hver. local-gw er den adresse, FortiGate bruger som kilde til IKE på sin eksterne grænseflade, og den skal være en adresse, enheden faktisk har. Det offentlige endepunkt er NAT-enhedens adresse og ejes af den, der udfører oversættelsen. IKE-identiteten er en streng, som peer'en sammenligner med sin egen konfiguration, og den behøver slet ikke være en IP-adresse.

Feltnavnene er tæt nok på til at friste til udskiftning, og det er fælden. localid og localid-type beskriver identifikation; local-gw beskriver lokal binding.

Et eksempel gør forskellen konkret. På FortiGate åbner du config vpn ipsec phase1-interface, derefter set interface "wan1" og set local-gw 10.0.0.2 — en adresse, boksen ejer, og det er det, der får IKE-socket'en til at binde korrekt. Lad local-gw stå på 0.0.0.0 og grænsefladens adresse bruges, hvilket normalt er det samme, men mindre eksplicit. Sæt ikke local-gw til 198.51.100.40, fordi enheden ikke ejer den adresse, og socket'en vil ikke binde til den. At få to værdier til at se ens ud på papiret er ikke en konfiguration.

Trin 1: vælg den identitet, peer'en accepterer

Nu identiteten, som er en anden beslutning. set localid tager den værdi, peer'en sammenligner, og set localid-type fortæller FortiGate, hvordan den skal fortolkes: en adresse, et FQDN, et bruger-FQDN eller et nøgle-ID. Med auto udleder enheden den, typisk fra den udgående grænseflades adresse, som netop er den værdi, en NAT-enhed er ved at ændre.

Den udledning er grunden til, at en eksplicit identitet er vigtig i denne topologi. Hvis peer'en forventer en adresseidentitet, sæt localid-type address og localid til den offentlige adresse, peer'en vil se, og bekræft derefter, at peer'en accepterer den værdi som identitet og ikke som rute-mål. Hvis peer'en forventer et FQDN, brug localid-type fqdn og det navn, den blev konfigureret med. Bekræft, hvad der faktisk blev sendt, med diagnose vpn ike gateway list, som viser gateway-tilstand og de anvendte identifikatorer i stedet for det, du havde tænkt dig at skrive. Antag ikke, at en identitetstype-indstilling accepterer en vilkårlig ikke-lokal adresse; tjek først udgivelsens dokumenterede semantik.

Trin 2: videresend UDP 500 og 4500 til enheden

Den tredje værdi tilhører NAT-enheden, og det er den, folk glemmer at tjekke. Det offentlige endepunkt skal videresende UDP 500 og UDP 4500 til FortiGate, fordi NAT-T-detektering og den indkapslede ESP, der følger, begge afhænger af, at disse porte ankommer. En en-til-en-mapping er det, dette design forudsætter; portbaseret deling af én offentlig adresse mellem flere peers er en anden topologi med andre grænser.

Bekræft videresendelsen med en optagelse i stedet for et håb: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 viser, om pakker ankommer, og om svar forlader.

Google Cloud VPN dokumenterer en-til-en NAT med NAT-T som det understøttede arrangement for en peer bag NAT, og det er den begrænsning, der skal designes efter, hvis den fjerne ende er en Cloud VPN-gateway. En-til-mange eller portbaseret deling er ikke den samme understøttede topologi, og ingen mængde lokal identitetsjustering ændrer det. Hvis den fjerne side er et andet apparat, definerer dets egen dokumentation, hvad det accepterer som identitet, og om det tolererer en oversat peer-adresse. Læs det, før du ændrer et lokalt felt, fordi den lokale side ikke kan forhandle en regel, den fjerne side ikke implementerer.

Trin 3: tjek, hvad fase 1 ikke løser

NAT-traversering får tunnelen op, identitetsenighed afgør, om peer'en accepterer den, og indre præfiks-routing afgør, hvad der faktisk passerer. Et korrekt lokalt ID kan ikke levere en manglende statisk rute eller en manglende trafikvælger.

Så verificer i lag. get vpn ipsec tunnel details viser, om tunnelen er oppe, og hvilke vælgere der blev forhandlet, og uoverensstemmelse mellem det konfigurerede fjerne subnet og den forhandlede vælger er et routingproblem i fase 2-kostume. execute vpn ike gateway clear tvinger en ny forhandling, så du tester den aktuelle konfiguration i stedet for en session, der blev oprettet før din seneste ændring. Send derefter trafik til en vært i det fjerne præfiks, og bekræft at tællerne flytter sig, fordi en tunnel, der er oppe og ikke sender noget igennem, ser identisk ud med en fungerende, indtil du tjekker.

Hold de tre værdier ét sted i dine noter: den lokale adresse, enheden ejer, det offentlige endepunkt, NAT-enheden præsenterer, og den identitetsstreng, peer'en forventer. De ændrer sig af forskellige grunde og på forskellige tidspunkter.

En omnummerering af NAT-enheden er ikke en grund til at røre local-gw på FortiGate, og en identitetsændring er ikke en grund til at omnummerere noget. At blande de to er, hvordan en fungerende tunnel genopbygges i et urelateret vedligeholdelsesvindue. Cloud VPN's NAT-vejledning er referencen for den understøttede topologi på den side.

Testen, der afgør det, er kedelig og hurtig: optag på den eksterne grænseflade, bekræft at UDP 500 og 4500 ankommer fra peer'en, bekræft at identiteten i IKE-udvekslingen matcher det, peer'en var konfigureret til at forvente, og bekræft derefter, at de forhandlede vælgere dækker de subnets, du bekymrer dig om. Hvis den første kontrol fejler, er NAT-enheden den mistænkte. Hvis den anden fejler, er det identitetsfelterne. Hvis den tredje fejler, var hverken NAT eller identitet nogensinde problemet.