FortiGate NAT mögött: local-gw, localid és a nyilvános IP

A NAT mögötti FortiGate rendelkezhet 10.0.0.2 a WAN-interfészén, miközben az internet 198.51.100.40 címként mutatja, és mindkét szám valós. A cím, amelyhez az eszköz kötődik, és az identitás, amelyet az IKE-hitelesítés során küld, külön döntések, külön mezőkben, külön közönségnek. A NAT átírja a külső címzést útközben; nem írja át a hitelesített identitást arra, amit a távoli peer vár. A legtöbb 1. fázisú hiba ebben a formában abból ered, hogy a helyes érték a rossz mezőbe kerül.

Három érték, három tulajdonos

Kezdje a három érték és tulajdonosuk megnevezésével. local-gw az a cím, amelyet a FortiGate az IKE forrásaként használ a külső interfészen, és olyan címnek kell lennie, amellyel az eszköz valóban rendelkezik. A nyilvános végpont a NAT-eszköz címe, és azé, aki a fordítást végzi. Az IKE-identitás egy karakterlánc, amelyet a peer a saját konfigurációjával vet össze, és egyáltalán nem kell IP-címnek lennie.

A mezőnevek elég közel vannak ahhoz, hogy helyettesítésre csábítsanak, és ez a csapda. localid és localid-type az azonosítást írják le; local-gw a helyi kötést írja le.

Egy példa konkréttá teszi a különbséget. A FortiGate-en nyissa meg a config vpn ipsec phase1-interface parancsot, majd a set interface "wan1" és a set local-gw 10.0.0.2 — olyan cím, amellyel a doboz rendelkezik, és ez teszi lehetővé az IKE-socket sikeres kötését. Ha a local-gw értéket 0.0.0.0 -on hagyja, az interfész címe lesz használva, ami általában ugyanaz, de kevésbé egyértelmű. Ne állítsa a local-gw értéket 198.51.100.40 -ra, mert az eszköz nem rendelkezik ezzel a címmel, és a socket nem fog hozzákötődni. Két értéket papíron egyenlőnek mutatni nem konfiguráció.

1. lépés: válassza ki az identitást, amelyet a peer elfogad

Most az identitás, ami más döntés. set localid azt az értéket veszi, amelyet a peer összehasonlít, a set localid-type pedig megmondja a FortiGate-nek, hogyan értelmezze: cím, FQDN, felhasználói FQDN vagy kulcs-ID. A auto esetén az eszköz levezeti, általában a kimenő interfész címéből, ami pontosan az az érték, amelyet a NAT-eszköz éppen módosítani készül.

Ez a levezetés az oka annak, hogy ebben a topológiában fontos a kifejezett identitás. Ha a peer cím-identitást vár, állítsa a localid-type address és a localid értékét arra a nyilvános címre, amelyet a peer látni fog, majd erősítse meg, hogy a peer ezt az értéket identitásként fogadja el, nem útvonalcélként. Ha a peer FQDN-t vár, használja a localid-type fqdn és a nevet, amellyel konfigurálták. Ellenőrizze a diagnose vpn ike gateway list paranccsal, mi került ténylegesen elküldésre; ez az átjáró állapotát és a használt azonosítókat mutatja, nem azt, amit beírni szándékozott. Ne feltételezze, hogy az identitástípus-beállítás tetszőleges nem helyi címet elfogad; először ellenőrizze a kiadás dokumentált szemantikáját.

2. lépés: továbbítsa az UDP 500 és 4500 portot az eszközre

A harmadik érték a NAT-eszközhöz tartozik, és ez az, amelyet az emberek elfelejtenek ellenőrizni. A nyilvános végpontnak továbbítania kell az UDP 500 és UDP 4500 portot a FortiGate-re, mert a NAT-T felismerés és az azt követő beágyazott ESP egyaránt ezeknek a portoknak a megérkezésétől függ. Ez a tervezés egy-az-egyhez leképezést feltételez; egyetlen nyilvános cím portok szerinti megosztása több peer között más topológia, más korlátokkal.

A továbbítást rögzítéssel erősítse meg, nem reménnyel: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 megmutatja, hogy érkeznek-e csomagok, és távoznak-e válaszok.

A Google Cloud VPN a NAT mögötti peer számára támogatott elrendezésként dokumentálja az egy-az-egyhez NAT-ot NAT-T-vel, és ha a távoli vég egy Cloud VPN-átjáró, akkor ehhez a korláthoz kell tervezni. Az egy-többhöz vagy portok szerinti megosztás nem ugyanaz a támogatott topológia, és ezen semmilyen helyi identitáshangolás nem változtat. Ha a távoli oldal másik eszköz, a saját dokumentációja határozza meg, mit fogad el identitásként, és tolerálja-e a lefordított peer-címet. Ezt olvassa el, mielőtt helyi mezőt módosít, mert a helyi oldal nem tud olyan szabályt kialkudni, amelyet a távoli oldal nem valósít meg.

3. lépés: ellenőrizze, mit nem old meg az 1. fázis

A NAT-átjárás felhozza az alagutat, az identitás egyezése eldönti, hogy a peer elfogadja-e, a belső előtag útválasztása pedig eldönti, mi halad át valójában. A helyes helyi ID nem tud hiányzó statikus útvonalat vagy hiányzó forgalomválasztót biztosítani.

Ezért rétegenként ellenőrizze. get vpn ipsec tunnel details megmutatja, hogy az alagút fent van-e és mely választókat tárgyalták ki, és a konfigurált távoli alhálózat és a kialkudott választó közötti eltérés a 2. fázis jelmezébe bújt útválasztási probléma. execute vpn ike gateway clear újratárgyalást kényszerít, így az aktuális konfigurációt teszteli, nem az utolsó módosítása előtt létrejött munkamenetet. Ezután küldjön forgalmat a távoli előtag egyik hosztjára, és erősítse meg, hogy a számlálók mozdulnak, mert a fent lévő, de semmit át nem engedő alagút pontosan úgy néz ki, mint egy működő, amíg nem ellenőrzi.

Tartsa a három értéket egy helyen a jegyzeteiben: a helyi címet, amellyel az eszköz rendelkezik, a nyilvános végpontot, amelyet a NAT-eszköz mutat, és az identitáskarakterláncot, amelyet a peer vár. Különböző okokból és különböző időpontokban változnak.

A NAT-eszköz újraszámozása nem ok arra, hogy hozzányúljon a FortiGate local-gw mezőjéhez, és az identitás változása nem ok arra, hogy bármit újraszámozzon. A kettő keverése az, ahogy egy működő alagút egy független karbantartási ablakban újjáépül. A Cloud VPN NAT-útmutató a hivatkozás az adott oldalon támogatott topológiához.

A döntő teszt unalmas és gyors: rögzítsen a külső interfészen, erősítse meg, hogy az UDP 500 és 4500 a peertől érkezik, erősítse meg, hogy az IKE-csere identitása megegyezik azzal, amit a peer elvárására konfiguráltak, majd erősítse meg, hogy a kialkudott választók lefedik az Ön számára fontos alhálózatokat. Ha az első ellenőrzés sikertelen, a NAT-eszköz a gyanúsított. Ha a második, akkor az identitásmezők. Ha a harmadik, akkor sem a NAT, sem az identitás nem volt soha a probléma.