FortiGate za NAT: local-gw, localid a veřejná IP

FortiGate za NAT může vlastnit 10.0.0.2 na svém rozhraní WAN, zatímco internet jej prezentuje jako 198.51.100.40 a obě čísla jsou skutečná. Adresa, na kterou se zařízení váže, a identita, kterou posílá při autentizaci IKE, jsou oddělená rozhodnutí, učiněná v oddělených polích pro oddělené publikum. NAT přepisuje vnější adresování cestou; nepřepisuje autentizovanou identitu na to, co očekává vzdálený peer. Většina selhání fáze 1 v tomto tvaru vzniká tím, že se správná hodnota vloží do špatného pole.

Tři hodnoty, tři vlastníci

Začněte tím, že pojmenujete tři hodnoty a kdo každou vlastní. local-gw je adresa, kterou FortiGate používá jako zdroj IKE na vnějším rozhraní, a musí to být adresa, kterou zařízení skutečně má. Veřejný koncový bod je adresa zařízení NAT a vlastní jej ten, kdo provádí překlad. Identita IKE je řetězec, který peer porovnává se svou konfigurací, a vůbec nemusí být IP adresou.

Názvy polí jsou dost blízko, aby sváděly k záměně, a to je past. localid a localid-type popisují identifikaci; local-gw popisuje lokální vazbu.

Příklad činí rozdíl konkrétním. Na FortiGate otevřete config vpn ipsec phase1-interface, pak set interface "wan1" a set local-gw 10.0.0.2 — adresa, kterou box vlastní, a právě to umožňuje úspěšné navázání socketu IKE. Ponechte local-gw na 0.0.0.0 a použije se adresa rozhraní, což je obvykle totéž, ale méně explicitní. Nenastavujte local-gw na 198.51.100.40, protože zařízení tuto adresu nevlastní a socket se na ni nenaváže. Udělat dvě hodnoty na papíře stejnými není konfigurace.

Krok 1: vyberte identitu, kterou peer přijme

Nyní identita, což je jiné rozhodnutí. set localid bere hodnotu, kterou bude peer porovnávat, a set localid-type říká FortiGate, jak ji interpretovat: adresa, FQDN, uživatelský FQDN nebo ID klíče. S auto ji zařízení odvozuje, obvykle z adresy odchozího rozhraní, což je přesně hodnota, kterou se zařízení NAT chystá změnit.

Právě toto odvození je důvod, proč je v této topologii explicitní identita důležitá. Pokud peer očekává adresní identitu, nastavte localid-type address a localid na veřejnou adresu, kterou peer uvidí, a poté ověřte, že peer tuto hodnotu přijímá jako identitu, nikoli jako cíl směrování. Pokud peer očekává FQDN, použijte localid-type fqdn a název, se kterým byl konfigurován. Ověřte, co bylo skutečně odesláno, pomocí diagnose vpn ike gateway list, která ukazuje stav brány a používané identifikátory, nikoli to, co jste zamýšleli napsat. Nepředpokládejte, že volba typu identity přijímá libovolnou nelokální adresu; nejprve zkontrolujte dokumentovanou sémantiku vydání.

Krok 2: přepošlete UDP 500 a 4500 na zařízení

Třetí hodnota patří zařízení NAT a je to ta, kterou lidé zapomínají zkontrolovat. Veřejný koncový bod musí přeposílat UDP 500 a UDP 4500 na FortiGate, protože detekce NAT-T i následný zapouzdřený ESP závisí na tom, že tyto porty dorazí. Tento návrh předpokládá mapování jedna ku jedné; sdílení jedné veřejné adresy po portech mezi několika peery je jiná topologie s jinými limity.

Potvrďte přeposílání zachycením, ne nadějí: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 ukazuje, zda pakety přicházejí a zda odpovědi odcházejí.

Google Cloud VPN dokumentuje NAT jedna ku jedné s NAT-T jako podporované uspořádání pro peer za NAT, a to je omezení, proti kterému je třeba navrhovat, pokud je vzdálená strana bránou Cloud VPN. Sdílení jedna ku mnoha nebo po portech není stejná podporovaná topologie a žádné ladění lokální identity to nezmění. Pokud je vzdálená strana jiný appliance, jeho vlastní dokumentace určuje, co přijme jako identitu a zda toleruje přeloženou adresu peeru. Přečtěte si to, než změníte lokální pole, protože lokální strana nemůže vyjednat pravidlo, které vzdálená strana neimplementuje.

Krok 3: zkontrolujte, co fáze 1 neřeší

Průchod NAT zvedne tunel, shoda identity rozhoduje, zda jej peer přijme, a směrování vnitřního prefixu rozhoduje, co skutečně projde. Správné lokální ID nedokáže dodat chybějící statickou trasu ani chybějící selektor provozu.

Proto ověřujte po vrstvách. get vpn ipsec tunnel details ukazuje, zda je tunel zvednutý a které selektory byly vyjednány, a nesoulad mezi nakonfigurovanou vzdálenou podsítí a vyjednaným selektorem je problém směrování v kostýmu fáze 2. execute vpn ike gateway clear vynutí nové vyjednání, takže testujete aktuální konfiguraci, ne relaci navázanou před vaší poslední změnou. Poté pošlete provoz na hostitele ve vzdáleném prefixu a potvrďte, že se počítadla hýbou, protože tunel, který je zvednutý a nic nepropouští, vypadá stejně jako funkční, dokud to nezkontrolujete.

Držte tři hodnoty na jednom místě v poznámkách: lokální adresu, kterou zařízení vlastní, veřejný koncový bod, který zařízení NAT prezentuje, a řetězec identity, který peer očekává. Mění se z různých důvodů a v různých časech.

Přečíslování zařízení NAT není důvod sahat na local-gw na FortiGate a změna identity není důvod cokoli přečíslovat. Míchání obojího je způsob, jak se funkční tunel přestaví během nesouvisejícího okna údržby. Pokyny Cloud VPN k NAT jsou referencí pro podporovanou topologii na oné straně.

Test, který to rozhodne, je nudný a rychlý: zachyťte na vnějším rozhraní, potvrďte, že UDP 500 a 4500 přicházejí od peeru, potvrďte, že identita ve výměně IKE odpovídá tomu, co byl peer nakonfigurován očekávat, a poté potvrďte, že vyjednané selektory pokrývají podsítě, na kterých vám záleží. Pokud první kontrola selže, podezřelým je zařízení NAT. Pokud druhá, jsou to pole identity. Pokud třetí, pak NAT ani identita nikdy nebyly problémem.