FortiGate sa likod ng NAT: local-gw, localid at ang pampublikong IP

Ang FortiGate sa likod ng NAT ay maaaring magmay-ari ng 10.0.0.2 sa WAN interface nito habang ipinapakita ito ng internet bilang 198.51.100.40, at ang dalawang numero ay totoo. Ang address na kinabibilangan ng device at ang pagkakakilanlang ipinapadala nito sa panahon ng IKE authentication ay magkahiwalay na desisyon, ginawa sa magkahiwalay na field, para sa magkahiwalay na audience. Binabago ng NAT ang panlabas na addressing sa daan; hindi nito binabago ang isang authenticated na pagkakakilanlan tungo sa inaasahan ng malayong peer. Karamihan ng mga pagkabigo sa phase 1 sa ganitong anyo ay nagmumula sa paglalagay ng tamang halaga sa maling field.

Tatlong halaga, tatlong may-ari

Magsimula sa pagpangalan ng tatlong halaga at kung sino ang may-ari ng bawat isa. local-gw ang address na ginagamit ng FortiGate bilang pinagmulan para sa IKE sa panlabas na interface nito, at dapat itong address na talagang taglay ng device. Ang pampublikong endpoint ay ang address ng NAT device, at pag-aari ng sinumang gumagawa ng pagsasalin. Ang pagkakakilanlang IKE ay isang string na inihahambing ng peer sa sarili nitong configuration, at hindi ito kailangang maging IP address.

Ang mga pangalan ng field ay sapat na malapit para mag-imbita ng pagpapalit, at iyon ang patibong. localid at localid-type ay naglalarawan ng pagkakakilanlan; local-gw ay naglalarawan ng lokal na pagbubuklod.

Ginagawang kongkreto ng isang halimbawa ang pagkakaiba. Sa FortiGate, buksan ang config vpn ipsec phase1-interface, pagkatapos set interface "wan1" at set local-gw 10.0.0.2 — address na taglay ng kahon, at ito ang nagpapabuklod nang matagumpay sa IKE socket. Iwanan ang local-gw sa 0.0.0.0 at gagamitin ang address ng interface, na karaniwang pareho ngunit hindi gaanong tahasan. Huwag itakda ang local-gw sa 198.51.100.40, dahil hindi taglay ng device ang address na iyon at hindi ito mabubuklod ng socket. Ang paggawang magkamukha ang dalawang halaga sa papel ay hindi configuration.

Hakbang 1: piliin ang pagkakakilanlang tatanggapin ng peer

Ngayon ang pagkakakilanlan, na ibang desisyon. set localid ay kumukuha ng halagang ihahambing ng peer, at set localid-type ay nagsasabi sa FortiGate kung paano ito bigyang-kahulugan: isang address, isang FQDN, isang user FQDN o isang key ID. Sa auto hinihinuha ito ng device, karaniwan mula sa address ng palabas na interface, na siyang eksaktong halagang babaguhin ng NAT device.

Ang hinihunang iyon ang dahilan kung bakit mahalaga ang tahasang pagkakakilanlan sa topolohiyang ito. Kung ang peer ay umaasa ng address identity, itakda ang localid-type address at localid sa pampublikong address na makikita ng peer, pagkatapos ay tiyakin na tinatanggap ng peer ang halagang iyon bilang pagkakakilanlan at hindi bilang target ng routing. Kung ang peer ay umaasa ng FQDN, gamitin ang localid-type fqdn at ang pangalang ginamit noong i-configure ito. Tiyakin kung ano ang aktwal na ipinadala gamit ang diagnose vpn ike gateway list, na nagpapakita ng estado ng gateway at ng mga identifier na ginagamit, hindi ang balak mong i-type. Huwag ipagpalagay na ang opsyon ng uri ng pagkakakilanlan ay tumatanggap ng arbitraryong di-lokal na address; suriin muna ang dokumentadong semantika ng release.

Hakbang 2: ipasa ang UDP 500 at 4500 sa device

Ang ikatlong halaga ay pag-aari ng NAT device, at iyon ang nakakalimutang suriin ng mga tao. Ang pampublikong endpoint ay dapat magpasa ng UDP 500 at UDP 4500 sa FortiGate, dahil ang NAT-T detection at ang naka-encapsulate na ESP na kasunod ay parehong umaasa sa pagdating ng mga port na iyon. Ipinapalagay ng disenyong ito ang one-to-one mapping; ang pagbabahagi ng isang pampublikong address sa mga port sa maraming peer ay ibang topolohiya na may ibang limitasyon.

Tiyakin ang pagpapasa gamit ang capture at hindi gamit ang pag-asa: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 ay nagpapakita kung dumarating ang mga packet at kung lumalabas ang mga tugon.

Dinodokumento ng Google Cloud VPN ang one-to-one NAT kasama ang NAT-T bilang sinusuportahang kaayusan para sa peer sa likod ng NAT, at iyon ang limitasyong dapat isaalang-alang sa disenyo kung ang malayong dulo ay isang Cloud VPN gateway. Ang one-to-many o pagbabahagi sa mga port ay hindi ang parehong sinusuportahang topolohiya, at walang lokal na pag-tune ng pagkakakilanlan ang makakabago nito. Kung ang malayong panig ay ibang device, tinutukoy ng sarili nitong dokumentasyon kung ano ang tatanggapin nito bilang pagkakakilanlan at kung pinapayagan nito ang isinaling address ng peer. Basahin iyon bago baguhin ang isang lokal na field, dahil hindi makakipag-usap ang lokal na panig sa isang patakarang hindi ipinapatupad ng malayong panig.

Hakbang 3: suriin kung ano ang hindi niresolba ng phase 1

Itinataas ng NAT traversal ang tunnel, ang kasunduan sa pagkakakilanlan ang nagpapasya kung tatanggapin ito ng peer, at ang routing ng panloob na prefix ang nagpapasya kung ano ang aktwal na dumadaan. Ang tamang lokal na ID ay hindi makapagbibigay ng nawawalang static na ruta o nawawalang traffic selector.

Kaya tiyakin ito nang pa-layer. get vpn ipsec tunnel details ay nagpapakita kung nakataas ang tunnel at kung aling mga selector ang napagkasunduan, at ang pagkakaiba sa pagitan ng naka-configure na malayong subnet at ng napagkasunduang selector ay problema sa routing na nakasuot ng phase 2. execute vpn ike gateway clear ay nagpipilit ng muling pakikipag-usap, kaya sinusubukan mo ang kasalukuyang configuration at hindi ang session na itinatag bago ang huling pagbabago mo. Pagkatapos ay magpadala ng traffic sa isang host sa malayong prefix at tiyakin na gumagalaw ang mga counter, dahil ang tunnel na nakataas ngunit walang pinapasang anuman ay mukhang kapareho ng gumagana hanggang sa tiyakin mo.

Itago ang tatlong halaga sa isang lugar sa iyong mga tala: ang lokal na address na taglay ng device, ang pampublikong endpoint na ipinapakita ng NAT device, at ang string ng pagkakakilanlang inaasahan ng peer. Nagbabago ang mga ito sa iba't ibang dahilan at sa iba't ibang oras.

Ang muling pag-numero ng NAT device ay hindi dahilan para hawakan ang local-gw ng FortiGate, at ang pagbabago ng pagkakakilanlan ay hindi dahilan para muling numero ang anuman. Ang paghahalo ng dalawa ay kung paano itinayong muli ang isang gumaganang tunnel sa panahon ng walang kaugnayang maintenance window. Ang gabay sa NAT ng Cloud VPN ang sanggunian para sa sinusuportahang topolohiya sa panig na iyon.

Ang pagsubok na nagpapasya nito ay nakababagot at mabilis: kumuha ng capture sa panlabas na interface, tiyakin na dumarating ang UDP 500 at 4500 mula sa peer, tiyakin na tumutugma ang pagkakakilanlan sa palitan ng IKE sa kung ano ang naka-configure na inaasahan ng peer, pagkatapos ay tiyakin na sinasaklaw ng napagkasunduang selector ang mga subnet na mahalaga sa iyo. Kung nabigo ang unang pagsusuri, ang NAT device ang pinaghihinalaan. Kung nabigo ang pangalawa, ang mga field ng pagkakakilanlan. Kung nabigo ang pangatlo, hindi kailanman naging problema ang NAT o pagkakakilanlan.