FortiGate malantaŭ NAT: local-gw, localid kaj la publika IP

FortiGate malantaŭ NAT povas posedi 10.0.0.2 sur sia WAN-interfaco, dum la interreto prezentas ĝin kiel 198.51.100.40, kaj ambaŭ nombroj estas realaj. La adreso, al kiu la aparato ligiĝas, kaj la identeco, kiun ĝi sendas dum IKE-aŭtentikigo, estas apartaj decidoj, faritaj en apartaj kampoj, por apartaj aŭskultantoj. NAT reskribas la eksteran adresadon survoje; ĝi ne reskribas aŭtentikigitan identecon en tion, kion la fora peer atendas. Plej multaj malsukcesoj de fazo 1 en ĉi tiu formo venas de metado de la ĝusta valoro en la malĝustan kampon.

Tri valoroj, tri posedantoj

Komencu nomante la tri valorojn kaj kiu posedas ĉiun. local-gw estas la adreso, kiun FortiGate uzas kiel fonton por IKE sur sia ekstera interfaco, kaj ĝi devas esti adreso, kiun la aparato efektive havas. La publika finpunkto estas la adreso de la NAT-aparato, posedata de tiu, kiu faras la tradukon. La IKE-identeco estas ĉeno, kiun la peer komparas kun sia propra agordo, kaj ĝi tute ne devas esti IP-adreso.

La kampnomoj estas sufiĉe proksimaj por inviti anstataŭigon, kaj tio estas la kaptilo. localid kaj localid-type priskribas identigon; local-gw priskribas lokan ligadon.

Ekzemplo faras la distingon konkreta. Sur la FortiGate, malfermu config vpn ipsec phase1-interface, poste set interface "wan1" kaj set local-gw 10.0.0.2 — adreso, kiun la skatolo posedas, kaj ĝuste tio ebligas sukcesan ligon de la IKE-ingo. Lasu local-gw je 0.0.0.0 kaj la interfaca adreso estas uzata, kio kutime estas la sama afero sed malpli eksplicita. Ne agordu local-gw al 198.51.100.40, ĉar la aparato ne posedas tiun adreson kaj la ingo ne ligiĝos al ĝi. Igigi du valorojn aspekti egalaj sur papero ne estas agordo.

Paŝo 1: elektu la identecon, kiun la peer akceptos

Nun la identeco, kiu estas malsama decido. set localid prenas la valoron, kiun la peer komparos, kaj set localid-type diras al la FortiGate kiel interpreti ĝin: adreso, FQDN, uzanta FQDN aŭ ŝlosila ID. Kun auto la aparato derivas ĝin, kutime el la adreso de la elira interfaco, kio estas ĝuste la valoro, kiun NAT-aparato baldaŭ ŝanĝos.

Tiu derivado estas kial eksplicita identeco gravas en ĉi tiu topologio. Se la peer atendas adresan identecon, agordu localid-type address kaj localid al la publika adreso, kiun la peer vidos, poste konfirmu, ke la peer akceptas tiun valoron kiel identecon, ne kiel enkursigan celon. Se la peer atendas FQDN, uzu localid-type fqdn kaj la nomon, kun kiu ĝi estis agordita. Kontrolu, kio efektive estis sendita, per diagnose vpn ike gateway list, kiu montras la staton de la enirejo kaj la uzatajn identigilojn, ne tion, kion vi intencis tajpi. Ne supozu, ke identectipa opcio akceptas arbitran nelokan adreson; unue kontrolu la dokumentitan semantikon de la eldono.

Paŝo 2: plusendu UDP 500 kaj 4500 al la aparato

La tria valoro apartenas al la NAT-aparato, kaj ĝi estas tiu, kiun homoj forgesas kontroli. La publika finpunkto devas plusendi UDP 500 kaj UDP 4500 al la FortiGate, ĉar NAT-T-detekto kaj la ĉirkaŭvolvita ESP, kiu sekvas, ambaŭ dependas de alveno de tiuj havenoj. Ĉi tiu dezajno supozas unu-al-unu mapadon; havenbaza divido de unu publika adreso inter pluraj peer estas malsama topologio kun malsamaj limoj.

Konfirmu la plusendadon per kaptaĵo, ne per espero: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 montras, ĉu pakaĵoj alvenas kaj ĉu respondoj foriras.

Google Cloud VPN dokumentas unu-al-unu NAT kun NAT-T kiel la subtenatan aranĝon por peer malantaŭ NAT, kaj tio estas la limo, kontraŭ kiu oni devas dezajni se la fora fino estas Cloud VPN-enirejo. Unu-al-multaj aŭ havenbaza divido ne estas la sama subtenata topologio, kaj nenia kvanto da loka identeca agordado tion ŝanĝas. Se la fora flanko estas alia aparato, ĝia propra dokumentaro difinas, kion ĝi akceptos kiel identecon kaj ĉu ĝi toleras tradukitan peer-adreson. Legu tion antaŭ ol ŝanĝi lokan kampon, ĉar la loka flanko ne povas negocadi regulon, kiun la fora flanko ne efektivigas.

Paŝo 3: kontrolu, kion fazo 1 ne solvas

NAT-trapaso starigas la tunelon, identeca interkonsento decidas, ĉu la peer akceptos ĝin, kaj ena prefiksa enkursigado decidas, kio efektive trapasas. Ĝusta loka ID ne povas provizi mankantan statikan itineron aŭ mankantan trafikan selektilon.

Do kontrolu laŭ tavoloj. get vpn ipsec tunnel details montras, ĉu la tunelo estas supre kaj kiuj selektiloj estis negocitaj, kaj malkongruo inter la agordita fora subreto kaj la negocita selektilo estas enkursiga problemo en fazo 2-kostumo. execute vpn ike gateway clear devigas renegocadon, do vi testas la nunan agordon, ne sesion starigitan antaŭ via lasta ŝanĝo. Poste sendu trafikon al gastiganto en la fora prefikso kaj konfirmu, ke la nombriloj moviĝas, ĉar tunelo, kiu estas supre kaj trapasigas nenion, aspektas idente al funkcianta ĝis vi kontrolas.

Tenu la tri valorojn en unu loko en viaj notoj: la loka adreso, kiun la aparato posedas, la publika finpunkto, kiun la NAT-aparato prezentas, kaj la identeca ĉeno, kiun la peer atendas. Ili ŝanĝiĝas pro malsamaj kialoj kaj en malsamaj tempoj.

Renumerado de NAT-aparato ne estas kialo tuŝi la local-gw de la FortiGate, kaj identeca ŝanĝo ne estas kialo renumeri ion ajn. Miksi la du estas kiel funkcianta tunelo rekonstruiĝas dum nerilata bontenada fenestro. La Cloud VPN NAT-gvidilo estas la referenco por la subtenata topologio sur tiu flanko.

La testo, kiu solvas ĝin, estas enuiga kaj rapida: kaptu sur la ekstera interfaco, konfirmu, ke UDP 500 kaj 4500 alvenas de la peer, konfirmu, ke la identeco en la IKE-interŝanĝo kongruas kun tio, kion la peer estis agordita atendi, poste konfirmu, ke la negocitaj selektiloj kovras la subretojn, kiuj gravas al vi. Se la unua kontrolo malsukcesas, la NAT-aparato estas la suspektato. Se la dua malsukcesas, temas pri la identecaj kampoj. Se la tria malsukcesas, nek NAT nek identeco iam estis la problemo.