FortiGate за NAT: local-gw, localid і публічны IP

FortiGate за NAT можа валодаць 10.0.0.2 на сваім інтэрфейсе WAN, у той час як інтэрнэт прадстаўляе яго як 198.51.100.40, і абодва лікі сапраўдныя. Адрас, да якога прывязваецца прылада, і ідэнтычнасць, якую яна адпраўляе падчас аўтэнтыфікацыі IKE, — гэта асобныя рашэнні, зробленыя ў асобных палях для асобных аўдыторый. NAT перапісвае знешнюю адрасацыю па шляху, але не перапісвае аўтэнтыфікаваную ідэнтычнасць у тое, што чакае далёкі партнёр. Большасць збояў фазы 1 у такой форме ўзнікае з-за таго, што правільнае значэнне ставяць у няправільнае поле.

Тры значэнні, тры ўласнікі

Пачніце з таго, каб назваць тры значэнні і ўласніка кожнага. local-gw — гэта адрас, які FortiGate выкарыстоўвае як крыніцу IKE на знешнім інтэрфейсе, і ён павінен быць адрасам, які прылада сапраўды мае. Публічны канчатковы пункт — гэта адрас прылады NAT, ім валодае той, хто выконвае трансляцыю. Ідэнтычнасць IKE — гэта радок, які партнёр супастаўляе са сваёй канфігурацыяй, і ён зусім не абавязаны быць IP-адрасам.

Назвы палёў дастаткова блізкія, каб схіляць да падмены, і гэта пастка. localid і localid-type апісваюць ідэнтыфікацыю; local-gw апісвае лакальную прывязку.

Прыклад робіць розніцу канкрэтнай. На FortiGate адкрыйце config vpn ipsec phase1-interface, затым set interface "wan1" і set local-gw 10.0.0.2 — адрас, якім валодае прылада, і менавіта гэта дазваляе сокету IKE паспяхова прывязацца. Пакіньце local-gw на 0.0.0.0, і будзе выкарыстаны адрас інтэрфейсу, што звычайна тое ж самае, але менш яўна. Не ўстанаўлівайце local-gw у 198.51.100.40, бо прылада не валодае гэтым адрасам, і сокет не прывяжацца да яго. Зрабіць два значэнні аднолькавымі на паперы — гэта не канфігурацыя.

Крок 1: выберыце ідэнтычнасць, якую прыме партнёр

Цяпер ідэнтычнасць, а гэта іншае рашэнне. set localid прымае значэнне, якое будзе параўноўваць партнёр, а set localid-type паведамляе FortiGate, як яго інтэрпрэтаваць: адрас, FQDN, FQDN карыстальніка або ключ ID. З auto прылада выводзіць яго, звычайна з адраса зыходнага інтэрфейсу, а гэта менавіта тое значэнне, якое прылада NAT збіраецца змяніць.

Менавіта праз гэты вывад яўная ідэнтычнасць важная ў такой тапалогіі. Калі партнёр чакае адрасную ідэнтычнасць, усталюйце localid-type address і localid на публічны адрас, які ўбачыць партнёр, затым пераканайцеся, што партнёр прымае гэта значэнне як ідэнтычнасць, а не як мэту маршрутызацыі. Калі партнёр чакае FQDN, выкарыстайце localid-type fqdn і імя, з якім ён быў наладжаны. Праверце, што фактычна адпраўлена, з дапамогай diagnose vpn ike gateway list, якая паказвае стан шлюза і ідэнтыфікатары, што выкарыстоўваюцца, а не тое, што вы мелі намер набраць. Не мяркуйце, што опцыя тыпу ідэнтычнасці прымае адвольны нелакальны адрас; спачатку праверце дакументаваную семантыку выпуску.

Крок 2: перанакіруйце UDP 500 і 4500 на прыладу

Трэцяе значэнне належыць прыладзе NAT, і гэта тое, што людзі забываюць праверыць. Публічны канчатковы пункт павінен перанакіроўваць UDP 500 і UDP 4500 на FortiGate, бо выяўленне NAT-T і інкапсуляваны ESP, што ідзе следам, залежаць ад прыходу гэтых партоў. Менавіта адно-да-аднаго супастаўленне прадугледжвае гэты дызайн; падзел аднаго публічнага адраса паміж некалькімі партнёрамі па партах — гэта іншая тапалогія з іншымі абмежаваннямі.

Пацвердзіце перанакіраванне захопам, а не надзеяй: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 паказвае, ці прыходзяць пакеты і ці сыходзяць адказы.

Google Cloud VPN дакументуе NAT адзін-да-аднаго з NAT-T як падтрымліваемую схему для партнёра за NAT, і менавіта гэтае абмежаванне трэба ўлічваць, калі далёкі бок — шлюз Cloud VPN. Падзел адзін-да-многіх або па партах — гэта не тая ж падтрымліваемая тапалогія, і ніякая наладка лакальнай ідэнтычнасці гэтага не зменіць. Калі далёкі бок — іншая прылада, яе ўласная дакументацыя вызначае, што яна прыме як ідэнтычнасць і ці церпіць трансляваны адрас партнёра. Прачытайце гэта, перш чым змяняць лакальнае поле, бо лакальны бок не можа ўзгадніць правіла, якое далёкі бок не рэалізуе.

Крок 3: праверце, чаго не вырашае фаза 1

Праходжанне NAT паднімае тунель, узгадненне ідэнтычнасці вырашае, ці прыме яго партнёр, а маршрутызацыя ўнутранага прэфікса вырашае, што фактычна пройдзе. Правільны лакальны ID не можа забяспечыць адсутны статычны маршрут або адсутны селектар трафіку.

Таму правярайце па слаях. get vpn ipsec tunnel details паказвае, ці падняты тунель і якія селектары ўзгоднены, а неадпаведнасць паміж наладжанай далёкай падсеткай і ўзгодненым селектарам — гэта праблема маршрутызацыі ў касцюме фазы 2. execute vpn ike gateway clear прымушае перагаворы нанова, таму вы правяраеце бягучую канфігурацыю, а не сеанс, усталяваны да вашай апошняй змены. Затым адпраўце трафік на хост у далёкім прэфіксе і пацвердзіце, што лічыльнікі рухаюцца, бо тунель, які падняты і нічога не прапускае, выглядае аднолькава з працоўным, пакуль вы не праверыце.

Трымайце тры значэнні ў адным месцы ў нататках: лакальны адрас, якім валодае прылада, публічны канчатковы пункт, які прадстаўляе прылада NAT, і радок ідэнтычнасці, які чакае партнёр. Яны змяняюцца з розных прычын і ў розныя часы.

Перанумарацыя прылады NAT — не прычына чапаць local-gw у FortiGate, а змена ідэнтычнасці — не прычына перанумароўваць што-небудзь. Змешванне двух — гэта як працоўны тунель перабудоўваюць падчас незвязанага акна абслугоўвання. Дапаможнік Cloud VPN па NAT — гэта даведка для падтрымліваемай тапалогіі на тым баку.

Тэст, які ўсё вырашае, нудны і хуткі: зрабіце захоп на знешнім інтэрфейсе, пацвердзіце, што UDP 500 і 4500 прыходзяць ад партнёра, пацвердзіце, што ідэнтычнасць у абмене IKE супадае з тым, што партнёр быў наладжаны чакаць, затым пацвердзіце, што ўзгодненыя селектары пакрываюць падсеткі, якія вас цікавяць. Калі першая праверка не ўдалася, падазроны — прылада NAT. Калі другая — палі ідэнтычнасці. Калі трэцяя — то ні NAT, ні ідэнтычнасць ніколі не былі праблемай.