NAT у Azure VPN не вырашае праблему супадальных адрасоў VNet
Дзве VNet з адным прыватным дыяпазонам не злучацца толькі таму, што ёсць NAT. Спачатку праверце тып злучэння, потым перанумаруйце або валодайце псеўданімам перакладу.
Абедзве VNet выкарыстоўваюць 10.40.1.0/24, тунелі ўздымаюцца, і нічога не працуе. Даданне другога шлюза VPN гэтага не змяняе, і ніжэйшая метрыка маршруту таксама, бо праблема не ў выбары шляху. Дзве працоўныя нагрузкі, якія адказваюць на той самы прыватны адрас, пакідаюць кожны пакет з няпэўным пунктам прызначэння і непацверджаным зваротным шляхам. Перш чым планаваць любы пераклад, высветліце, які тып злучэння вы насамрэч стварылі, бо гэты адзіны выбар вызначае, ці даступная функцыя NAT у Azure наогул.
Што насамрэч кажа вам гэты сімптом
Калі хост у VNet A адпраўляе на 10.40.1.10, табліца маршрутызацыі можа толькі накіраваць яго кудысьці. Калі VNet B таксама змяшчае 10.40.1.10, гэты адрас не з'яўляецца пунктам прызначэння, які шлях можа адрозніць; гэта адзін адрас з двума ўладальнікамі.
Другі шлюз, які звычайна разгортваюць, не дапамагае. Ён дае яшчэ адзін тунель, а не яшчэ адзін адрас, і дублікат дыяпазону падарожнічае ўнутры тунеля без змен. Ён таксама падвойвае канфігурацыю, якую трэба трымаць узгодненай. Чаго ён не можа, дык гэта зрабіць так, каб адзін адрас азначаў два хасты.
Змена публічных адрасоў партнёраў VPN таксама нічога не дае. Гэтыя адрасы вызначаюць канцавыя пункты тунеля, а канфлікт знаходзіцца ў прыватным дыяпазоне, які пераносіцца ўнутры яго.
Тып злучэння вызначае, ці даступны NAT
Azure VPN Gateway сапраўды мае магчымасць NAT, і яна дакументавана для міжсайтавых злучэнняў IPsec на аснове маршрутаў на пэўных SKU шлюза. Тая ж дакументацыя выключае злучэнні VNet-to-VNet і point-to-site, таму гэта не сцяжок, які з'яўляецца на кожнай сувязі шлюза.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Уласны VNet-to-VNet таксама патрабуе, каб дыяпазоны VNet і лакальнай сеткі не супадалі з самага пачатку, што адпавядае выключэнню. Аб'яднанне VNet не з'яўляецца рашэннем для супадання па той жа прычыне.
Ёсць падтрыманая альтэрнатыва, якую людзі блытаюць з уласным тыпам: прадставіць іншую VNet як лакальную сетку і злучыць яе як злучэнне паміж пляцоўкамі. Гэта іншы рэсурс і іншы дызайн, таму стаўцеся да пераназванага злучэння як да змены, якую трэба праверыць, а не як да простага перайменавання.
Перанумаруйце або перакладайце з тым, што валодае псеўданімам
Калі абедзве VNet ваш, параўнайце запланаваную перанумарацыю з пастаяннымі выдаткамі на пераклад. Перанумарацыя закранае канфігурацыю праграм, запісы DNS, правілы бяспекі і кожнае існуючае злучэнне, але пакідае сетку, якая пасля чытаецца нармальна. Рабіце гэта па адной падсетцы, з зменай DNS апошняй. Напалову перанумараваны дыяпазон горш за любы з варыянтаў, бо тады абодва прэфіксы выглядаюць аўтарытэтнымі для таго, хто наступны чытае табліцу.
Там, дзе перанумарацыя непрактычная, выкарыстоўвайце перакладзены дызайн з рэальным уладальнікам псеўданіма. Кліенты ў VNet A могуць дасягаць 10.40.1.10 у VNet B як 10.140.1.10, але гэты псеўданім патрабуе прылады, якая перакладае, маршруту да яе і адпаведных паводзін для адказу. Адрас, дададзены толькі ў DNS, не з'яўляецца перакладам.
Запішыце абодва дыяпазоны ў абодвух напрамках: што набірае кліент, што прызначэнне бачыць як крыніцу і які бок можа ініцыяваць. Уласныя правілы NAT у Azure ўключаюць зваротны пераклад для іх адлюстраванняў SNAT, таму вы не пішаце адпаведнае правіла DNAT уручную, але гэтая зручнасць спыняецца на тыпах злучэнняў, якія падтрымлівае функцыя.
Што не будзе працаваць
Маршрут, вызначаны карыстальнікам, або метрыка маршруту не могуць стварыць адсутную адрозненне адрасоў. Абодва працуюць на пункце прызначэння, які ўсё яшчэ няпэўны, і пакет прыбывае на той наступны крок, які табліца аддае перавагу.
Даданне дубліката дыяпазону ў табліцу маршрутызацыі як больш канкрэтнага прэфікса толькі перасоўвае няпэўнасць на адзін крок. Гэта таксама схільна ламаць іншы напрамак, дзе адказ цяпер мае дзве верагодныя крыніцы.
Прыміце дызайн з трафікам у абодвух напрамках
Даказвайце дызайн свежай дазволенай аперацыяй з кожнага боку, а не статусам тунеля. Падключаны тунель IPsec кажа, што партнёры згодныя адносна крыптаграфіі; ён нічога не кажа пра тое, ці сталі пункты прызначэння адрознымі.
Затым прагоньце забароненыя шляхі: адрас, які павінен заставацца недасягальным, і службу, якую палітыка павінна блакаваць. Калі абодва ўсё яшчэ паспяховыя, пераклад шырэйшы, чым меркаваў дызайн.
Завяршыце фактамі, якія пазней тлумачаць наладку: зыходны дыяпазон, прадстаўлены дыяпазон, прылада, якая перакладае, і напрамак, які кожны бок можа ініцыяваць. Калі чагосьці з гэтага няма, наступны інжынер атрымлівае сетку, у якой два хасты дзеляць імя і ніхто не памятае, чаму адзін з іх адказвае.