FortiGate în spatele NAT: local-gw, localid și IP-ul public

Un FortiGate în spatele NAT poate deține 10.0.0.2 pe interfața sa WAN, în timp ce internetul îl prezintă ca 198.51.100.40, și ambele numere sunt reale. Adresa la care se leagă dispozitivul și identitatea pe care o trimite în timpul autentificării IKE sunt alegeri separate, făcute în câmpuri separate, pentru publicuri separate. NAT rescrie adresarea exterioară în trecere; nu rescrie o identitate autentificată în ceea ce așteaptă peer-ul îndepărtat. Majoritatea eșecurilor din faza 1 în această formă provin din plasarea valorii corecte în câmpul greșit.

Trei valori, trei proprietari

Începeți prin a numi cele trei valori și cine deține fiecare. local-gw este adresa pe care FortiGate o folosește ca sursă pentru IKE pe interfața externă și trebuie să fie o adresă pe care dispozitivul o are cu adevărat. Punctul final public este adresa dispozitivului NAT și aparține celui care face traducerea. Identitatea IKE este un șir pe care peer-ul îl compară cu propria configurație și nu trebuie să fie deloc o adresă IP.

Numele câmpurilor sunt suficient de apropiate încât să invite la substituire, și aceasta este capcana. localid și localid-type descriu identificarea; local-gw descrie legarea locală.

Un exemplu face distincția concretă. Pe FortiGate, deschideți config vpn ipsec phase1-interface, apoi set interface "wan1" și set local-gw 10.0.0.2 — o adresă pe care cutia o deține, și exact aceasta face ca socketul IKE să se lege cu succes. Lăsați local-gw pe 0.0.0.0 și se folosește adresa interfeței, ceea ce de obicei este același lucru, dar mai puțin explicit. Nu setați local-gw la 198.51.100.40, pentru că dispozitivul nu deține acea adresă și socketul nu se va lega la ea. A face două valori să pară egale pe hârtie nu este o configurație.

Pasul 1: alegeți identitatea pe care peer-ul o va accepta

Acum identitatea, care este o decizie diferită. set localid ia valoarea pe care peer-ul o va compara, iar set localid-type îi spune FortiGate-ului cum să o interpreteze: o adresă, un FQDN, un FQDN de utilizator sau un ID de cheie. Cu auto dispozitivul o derivă, de obicei din adresa interfeței de ieșire, care este exact valoarea pe care un dispozitiv NAT este pe cale să o schimbe.

Această derivare este motivul pentru care o identitate explicită contează în această topologie. Dacă peer-ul așteaptă o identitate de adresă, setați localid-type address și localid la adresa publică pe care peer-ul o va vedea, apoi confirmați că peer-ul acceptă acea valoare ca identitate și nu ca țintă de rutare. Dacă peer-ul așteaptă un FQDN, folosiți localid-type fqdn și numele cu care a fost configurat. Verificați ce s-a trimis efectiv cu diagnose vpn ike gateway list, care arată starea gateway-ului și identificatorii în uz, nu ceea ce intenționați să tastați. Nu presupuneți că o opțiune de tip identitate acceptă o adresă ne-locală arbitrară; verificați mai întâi semantica documentată a versiunii.

Pasul 2: redirecționați UDP 500 și 4500 către dispozitiv

A treia valoare aparține dispozitivului NAT și este cea pe care oamenii uită să o verifice. Punctul final public trebuie să redirecționeze UDP 500 și UDP 4500 către FortiGate, deoarece detectarea NAT-T și ESP-ul încapsulat care urmează depind ambele de sosirea acestor porturi. Această arhitectură presupune o corespondență unu la unu; partajarea unei singure adrese publice pe porturi între mai mulți peer-i este o altă topologie, cu alte limite.

Confirmați redirecționarea cu o captură și nu cu o speranță: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 arată dacă pachetele sosesc și dacă răspunsurile pleacă.

Google Cloud VPN documentează NAT unu la unu cu NAT-T ca aranjamentul acceptat pentru un peer în spatele NAT, iar aceasta este constrângerea față de care trebuie proiectat dacă capătul îndepărtat este un gateway Cloud VPN. Partajarea unu-la-mulți sau pe porturi nu este aceeași topologie acceptată, iar nicio ajustare locală a identității nu schimbă asta. Dacă partea îndepărtată este un alt echipament, documentația proprie definește ce va accepta ca identitate și dacă tolerează o adresă de peer tradusă. Citiți-o înainte de a schimba un câmp local, pentru că partea locală nu poate negocia o regulă pe care partea îndepărtată nu o implementează.

Pasul 3: verificați ce nu rezolvă faza 1

Traversarea NAT ridică tunelul, acordul de identitate decide dacă peer-ul îl acceptă, iar rutarea prefixului interior decide ce trece efectiv. Un ID local corect nu poate furniza o rută statică lipsă sau un selector de trafic lipsă.

Deci verificați pe straturi. get vpn ipsec tunnel details arată dacă tunelul este ridicat și ce selectori au fost negociați, iar o nepotrivire între subrețeaua îndepărtată configurată și selectorul negociat este o problemă de rutare în costum de faza 2. execute vpn ike gateway clear forțează o renegociere, așa că testați configurația curentă, nu o sesiune stabilită înainte de ultima modificare. Apoi trimiteți trafic către un host din prefixul îndepărtat și confirmați că contoarele se mișcă, pentru că un tunel ridicat care nu trece nimic arată identic cu unul funcțional până când verificați.

Țineți cele trei valori într-un singur loc în note: adresa locală pe care o deține dispozitivul, punctul final public pe care îl prezintă dispozitivul NAT și șirul de identitate pe care îl așteaptă peer-ul. Se schimbă din motive diferite și la momente diferite.

Renumerotarea dispozitivului NAT nu este un motiv pentru a atinge local-gw de pe FortiGate, iar o schimbare de identitate nu este un motiv pentru a renumerota nimic. Amestecarea celor două este modul în care un tunel funcțional este reconstruit în timpul unei ferestre de mentenanță fără legătură. Ghidul NAT al Cloud VPN este referința pentru topologia acceptată de acea parte.

Testul care lămurește lucrurile este plictisitor și rapid: capturați pe interfața externă, confirmați că UDP 500 și 4500 sosesc de la peer, confirmați că identitatea din schimbul IKE corespunde cu ceea ce peer-ul era configurat să aștepte, apoi confirmați că selectorii negociați acoperă subrețelele care vă interesează. Dacă prima verificare eșuează, suspectul este dispozitivul NAT. Dacă eșuează a doua, sunt câmpurile de identitate. Dacă eșuează a treia, nici NAT, nici identitatea nu au fost vreodată problema.