FortiGate pas NAT: local-gw, localid dhe IP-ja publike

Një FortiGate pas NAT mund të zotërojë 10.0.0.2 në ndërfaqen e tij WAN, ndërsa interneti e paraqet si 198.51.100.40, dhe të dy numrat janë realë. Adresa me të cilën lidhet pajisja dhe identiteti që dërgon gjatë vërtetimit IKE janë zgjedhje të ndara, të marra në fusha të ndara, për audiencë të ndarë. NAT rishkruan adresimin e jashtëm gjatë rrugës; nuk rishkruan një identitet të vërtetuar në atë që pret peer-i i largët. Shumica e dështimeve të fazës 1 në këtë formë vijnë nga vendosja e vlerës së saktë në fushën e gabuar.

Tre vlera, tre pronarë

Filloni duke emërtuar tre vlerat dhe kush zotëron secilën. local-gw është adresa që FortiGate përdor si burim për IKE në ndërfaqen e jashtme, dhe duhet të jetë një adresë që pajisja e ka vërtet. Pika fundore publike është adresa e pajisjes NAT dhe i përket atij që kryen përkthimin. Identiteti IKE është një varg që peer-i e krahason me konfigurimin e vet, dhe nuk kërkohet të jetë fare adresë IP.

Emrat e fushave janë mjaft të afërt për të ftuar zëvendësimin, dhe ajo është kurthi. localid dhe localid-type përshkruajnë identifikimin; local-gw përshkruan lidhjen lokale.

Një shembull e bën dallimin konkret. Në FortiGate, hapni config vpn ipsec phase1-interface, pastaj set interface "wan1" dhe set local-gw 10.0.0.2 — një adresë që kutia e zotëron, dhe kjo është ajo që bën që socket-i IKE të lidhet me sukses. Lëreni local-gw në 0.0.0.0 dhe përdoret adresa e ndërfaqes, që zakonisht është e njëjta gjë por më pak e qartë. Mos e vendosni local-gw në 198.51.100.40, sepse pajisja nuk e zotëron atë adresë dhe socket-i nuk do të lidhet me të. Të bësh dy vlera të duken të barabarta në letër nuk është konfigurim.

Hapi 1: zgjidhni identitetin që peer-i do të pranojë

Tani identiteti, që është një vendim tjetër. set localid merr vlerën që peer-i do të krahasojë, dhe set localid-type i thotë FortiGate si ta interpretojë: një adresë, një FQDN, një FQDN përdoruesi ose një ID çelësi. Me auto pajisja e nxjerre atë, zakonisht nga adresa e ndërfaqes dalëse, që është pikërisht vlera që një pajisje NAT është gati të ndryshojë.

Ky nxjerrje është arsyeja pse një identitet i qartë ka rëndësi në këtë topologji. Nëse peer-i pret një identitet adrese, vendosni localid-type address dhe localid në adresën publike që peer-i do të shohë, pastaj konfirmoni që peer-i e pranon atë vlerë si identitet dhe jo si objektiv rrugëtimi. Nëse peer-i pret një FQDN, përdorni localid-type fqdn dhe emrin me të cilin u konfigurua. Verifikoni çfarë u dërgua në të vërtetë me diagnose vpn ike gateway list, që tregon gjendjen e gateway-it dhe identifikuesit në përdorim, jo atë që kishit ndërmend të shkruani. Mos supozoni që një opsion i tipit të identitetit pranon një adresë arbitrare jo-lokale; kontrolloni së pari semantikën e dokumentuar të versionit.

Hapi 2: përcillni UDP 500 dhe 4500 te pajisja

Vlera e tretë i përket pajisjes NAT, dhe është ajo që njerëzit harrojnë të kontrollojnë. Pika fundore publike duhet të përcjellë UDP 500 dhe UDP 4500 te FortiGate, sepse zbulimi i NAT-T dhe ESP-ja e inkapsuluar që vjen pas varen të dy nga ardhja e këtyre porteve. Ky dizajn supozon një hartëzim një-me-një; ndarja e një adrese publike sipas porteve midis disa peer-ëve është një topologji tjetër me kufij të tjerë.

Konfirmoni përcjelljen me një kapje dhe jo me një shpresë: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 tregon nëse paketat po vijnë dhe nëse përgjigjet po dalin.

Google Cloud VPN dokumenton NAT një-me-një me NAT-T si rregullimin e mbështetur për një peer pas NAT, dhe ky është kufizimi ndaj të cilit duhet projektuar nëse skaji i largët është një gateway Cloud VPN. Ndarja një-me-shumë ose sipas porteve nuk është e njëjta topologji e mbështetur, dhe asnjë rregullim lokal i identitetit nuk e ndryshon atë. Nëse ana e largët është një pajisje tjetër, dokumentacioni i saj përcakton çfarë do të pranojë si identitet dhe nëse toleron një adresë peer-i të përkthyer. Lexojeni atë përpara se të ndryshoni një fushë lokale, sepse ana lokale nuk mund të negociojë një rregull që ana e largët nuk e zbaton.

Hapi 3: kontrolloni çfarë nuk zgjidh faza 1

Kalimi përmes NAT ngre tunelin, marrëveshja e identitetit vendos nëse peer-i do ta pranojë, dhe rrugëtimi i prefiksit të brendshëm vendos çfarë kalon në të vërtetë. Një ID lokal i saktë nuk mund të sigurojë një rrugë statike që mungon ose një përzgjedhës trafiku që mungon.

Prandaj verifikoni shtresë pas shtrese. get vpn ipsec tunnel details tregon nëse tuneli është ngritur dhe cilët përzgjedhës u negociuan, dhe mospërputhja midis nënrrjetit të largët të konfiguruar dhe përzgjedësit të negociuar është një problem rrugëtimi me kostum faze 2. execute vpn ike gateway clear detyron një rinegocim, kështu që testoni konfigurimin aktual dhe jo një sesion të vendosur përpara ndryshimit tuaj të fundit. Pastaj dërgoni trafik te një host në prefiksin e largët dhe konfirmoni që numëruesit lëvizin, sepse një tunel i ngritur që nuk kalon asgjë duket identik me një funksional derisa ta kontrolloni.

Mbani tre vlerat në një vend në shënimet tuaja: adresën lokale që zotëron pajisja, pikën fundore publike që paraqet pajisja NAT dhe vargun e identitetit që pret peer-i. Ato ndryshojnë për arsye të ndryshme dhe në kohë të ndryshme.

Rinumërimi i pajisjes NAT nuk është arsye për të prekur local-gw e FortiGate, dhe një ndryshim identiteti nuk është arsye për të rinumëruar asgjë. Përzierja e të dyjave është mënyra se si një tunel funksional rindërtohet gjatë një dritareje mirëmbajtjeje të palidhur. Udhëzuesi i NAT i Cloud VPN është referenca për topologjinë e mbështetur në atë anë.

Testi që e zgjidh është i mërzitshëm dhe i shpejtë: bëni një kapje në ndërfaqen e jashtme, konfirmoni që UDP 500 dhe 4500 vijnë nga peer-i, konfirmoni që identiteti në shkëmbimin IKE përputhet me atë që peer-i ishte konfiguruar të presë, pastaj konfirmoni që përzgjedësit e negociuar mbulojnë nënrrjetet që ju interesojnë. Nëse kontrolli i parë dështon, i dyshuari është pajisja NAT. Nëse i dyti, janë fushat e identitetit. Nëse i treti, as NAT as identiteti nuk ishin kurrë problemi.