FortiGate za NAT: local-gw, localid a verejná IP
FortiGate za NAT má lokálnu adresu, preložený verejný koncový bod a identitu IKE. FortiOS ich drží v poliach, ktoré nie sú zameniteľné.
FortiGate za NAT môže vlastniť 10.0.0.2 na svojom rozhraní WAN, zatiaľ čo internet ho prezentuje ako 198.51.100.40, a obe čísla sú skutočné. Adresa, na ktorú sa zariadenie viaže, a identita, ktorú posiela počas autentifikácie IKE, sú oddelené rozhodnutia, urobené v oddelených poliach pre oddelené publikum. NAT prepisuje vonkajšie adresovanie cestou; neprepisuje autentifikovanú identitu na to, čo očakáva vzdialený peer. Väčšina zlyhaní fázy 1 v tomto tvare vzniká tým, že sa správna hodnota vloží do nesprávneho poľa.
Tri hodnoty, traja vlastníci
Začnite tým, že pomenujete tri hodnoty a kto každú vlastní. local-gw je adresa, ktorú FortiGate používa ako zdroj IKE na vonkajšom rozhraní, a musí to byť adresa, ktorú zariadenie skutočne má. Verejný koncový bod je adresa zariadenia NAT a patrí tomu, kto vykonáva preklad. Identita IKE je reťazec, ktorý peer porovnáva so svojou konfiguráciou, a vôbec nemusí byť IP adresou.
Názvy polí sú dosť blízko, aby lákali na zámenu, a to je pasca. localid a localid-type opisujú identifikáciu; local-gw opisuje lokálnu väzbu.
Príklad robí rozdiel konkrétnym. Na FortiGate otvorte config vpn ipsec phase1-interface, potom set interface "wan1" a set local-gw 10.0.0.2 — adresa, ktorú box vlastní, a práve to umožňuje úspešné naviazanie socketu IKE. Ponechajte local-gw na 0.0.0.0 a použije sa adresa rozhrania, čo je zvyčajne to isté, ale menej explicitné. Nenastavujte local-gw na 198.51.100.40, pretože zariadenie túto adresu nevlastní a socket sa na ňu nenaviaže. Urobiť dve hodnoty na papieri rovnakými nie je konfigurácia.
Krok 1: vyberte identitu, ktorú peer prijme
Teraz identita, čo je iné rozhodnutie. set localid berie hodnotu, ktorú bude peer porovnávať, a set localid-type hovorí FortiGate, ako ju interpretovať: adresa, FQDN, používateľský FQDN alebo ID kľúča. S auto ju zariadenie odvodzuje, zvyčajne z adresy odchádzajúceho rozhrania, čo je presne hodnota, ktorú sa zariadenie NAT chystá zmeniť.
Práve toto odvodzovanie je dôvod, prečo je v tejto topológii dôležitá explicitná identita. Ak peer očakáva adresnú identitu, nastavte localid-type address a localid na verejnú adresu, ktorú peer uvidí, a potom overte, že peer prijíma túto hodnotu ako identitu, nie ako cieľ smerovania. Ak peer očakáva FQDN, použite localid-type fqdn a názov, s ktorým bol konfigurovaný. Overte, čo bolo skutočne odoslané, pomocou diagnose vpn ike gateway list, ktorá zobrazuje stav brány a používané identifikátory, nie to, čo ste zamýšľali napísať. Nepredpokladajte, že voľba typu identity prijíma ľubovoľnú nelokálnu adresu; najprv skontrolujte dokumentovanú sémantiku vydania.
Krok 2: prepošlite UDP 500 a 4500 na zariadenie
Tretia hodnota patrí zariadeniu NAT a je to tá, ktorú ľudia zabúdajú skontrolovať. Verejný koncový bod musí preposielať UDP 500 a UDP 4500 na FortiGate, pretože detekcia NAT-T aj nasledujúci zapuzdrený ESP závisia od toho, že tieto porty dorazia. Tento návrh predpokladá mapovanie jeden k jednému; zdieľanie jednej verejnej adresy po portoch medzi viacerými peermi je iná topológia s inými limitmi.
Potvrďte preposielanie zachytením, nie nádejou: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 ukazuje, či pakety prichádzajú a či odpovede odchádzajú.
Google Cloud VPN dokumentuje NAT jeden k jednému s NAT-T ako podporované usporiadanie pre peera za NAT, a to je obmedzenie, proti ktorému treba navrhovať, ak je vzdialená strana bránou Cloud VPN. Zdieľanie jeden k mnohým alebo po portoch nie je tá istá podporovaná topológia a žiadne ladenie lokálnej identity to nezmení. Ak je vzdialená strana iné zariadenie, jeho vlastná dokumentácia určuje, čo prijme ako identitu a či toleruje preloženú adresu peera. Prečítajte si to pred zmenou lokálneho poľa, pretože lokálna strana nemôže vyjednať pravidlo, ktoré vzdialená strana neimplementuje.
Krok 3: skontrolujte, čo fáza 1 nerieši
Prechod cez NAT zdvihne tunel, zhoda identity rozhoduje, či ho peer prijme, a smerovanie vnútorného prefixu rozhoduje, čo skutočne prejde. Správne lokálne ID nedokáže dodať chýbajúcu statickú trasu ani chýbajúci selektor prevádzky.
Preto overujte po vrstvách. get vpn ipsec tunnel details ukazuje, či je tunel zdvihnutý a ktoré selektory boli vyjednané, a nesúlad medzi nakonfigurovanou vzdialenou podsietou a vyjednaným selektorom je problém smerovania v kostýme fázy 2. execute vpn ike gateway clear vynúti nové vyjednávanie, takže testujete aktuálnu konfiguráciu, nie reláciu vytvorenú pred vašou poslednou zmenou. Potom pošlite prevádzku na hostiteľa vo vzdialenom prefixe a potvrďte, že sa počítadlá hýbu, pretože tunel, ktorý je zdvihnutý a nič neprepúšťa, vyzerá rovnako ako funkčný, kým to neskontrolujete.
Držte tri hodnoty na jednom mieste v poznámkach: lokálnu adresu, ktorú zariadenie vlastní, verejný koncový bod, ktorý zariadenie NAT prezentuje, a reťazec identity, ktorý peer očakáva. Menia sa z rôznych dôvodov a v rôznych časoch.
Prečíslovanie zariadenia NAT nie je dôvod siahať na local-gw na FortiGate a zmena identity nie je dôvod čokoľvek prečíslovať. Miešanie oboch je spôsob, ako sa funkčný tunel prestavia počas nesúvisiaceho okna údržby. Príručka Cloud VPN k NAT je referenciou pre podporovanú topológiu na tej strane.
Test, ktorý to rozhodne, je nudný a rýchly: zachyťte na vonkajšom rozhraní, potvrďte, že UDP 500 a 4500 prichádzajú od peera, potvrďte, že identita vo výmene IKE zodpovedá tomu, čo bol peer nakonfigurovaný očakávať, a potom potvrďte, že vyjednané selektory pokrývajú podsiete, na ktorých vám záleží. Ak prvá kontrola zlyhá, podozrivým je zariadenie NAT. Ak druhá, sú to polia identity. Ak tretia, tak NAT ani identita nikdy neboli problémom.