Anypoint VPN ці NAT у Transit Gateway: дзе выконваецца пераўтварэнне

Патрабаванне да NAT не становіцца патрабаваннем, пакуль яно не назаве адрасы, якія змяняюцца, і кампанент, якому дазволена іх змяняць. У злучэнні MuleSoft гэтае рашэнне мае тры ўваходныя даныя: ці патрэбна сістэме на баку сэрвера пераўтварэнне партоў «многія ў адзін» або псеўданім прэфікса адзін-да-аднаго, ці можа далучэнне AWS, якім вы сапраўды валодаеце, выканаць гэтае супастаўленне, і ці застаецца ўвесь шлях унутры камбінацыі, якую падтрымлівае пастаўшчык. Памыліцеся тут, і вы пабудуеце працоўную лабараторыю, якая не пройдзе разгляд.

Адзіная нязменная кропка ў тым, што сам Anypoint VPN не з'яўляецца прыладай пераўтварэння. Дакументацыя CloudHub 2.0 пералічвае NAT як непадтрыманы там, таму любы праект, які мяркуе, што тунель схавае адрасы вашых працоўных, ужо зламаны.

Вызначце, што менавіта павінна рабіць пераўтварэнне

Калі мноства працоўных праграм павінны выглядаць для сістэмы на баку сэрвера як адзін адрас, патрабаванне — гэта супольнае пераўтварэнне крыніцы, звычайна SNAT або PAT з захаваннем стану на міжсеткавым экране, які вы кантралюеце. Гэты элемент павінен стаяць на дазволеным шляху, захоўваць свой стан на працягу ўсяго жыцця патоку і бачыць зваротны трафік для кожнага злучэння, якое ён перапісаў. Страта стану пасярэдзіне сеансу не пагаршае злучэнне; яна яго спыняе. Пара міжсеткавых экранаў, якая адмаўляецца дзяліць стан пераўтварэння, скіне кожны сеанс, што пасля пераключэння трапіць на рэзервовы вузел. Разлічвайце гэты элемент на адначасовыя патокі, а не на прапускную здольнасць.

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

Запішыце рашэнне ў канкрэтных тэрмінах, перш чым выбіраць прадукт: зыходная крыніца, зыходнае прызначэнне, пераўтворанае значэнне, кірунак ініцыявання, уладальнік пераўтваральніка і чаканы зваротны маршрут. Дадайце, якую ідэнтычнасць захаваюць журналы сістэмы на баку сэрвера, бо праект, які хавае ўсе крыніцы, таксама знішчае аўдыт па кожным кліенце.

Праверце, ці можа AWS выканаць супастаўленне за вас

AWS цяпер дакументуе кіраваны NAT адзін-да-аднаго на далучэннях Transit Gateway і Cloud WAN, абвешчаны ў канцы кастрычніка 2026, таму старое агульнае сцвярджэнне, што транзітная брама ніколі не можа пераўтвараць, ужо састарэла. Дакументацыя Transit Gateway NAT апісвае супастаўленне прэфіксаў IPv4 без стану: зыходныя і пераўтвораныя прэфіксы захоўваюць аднолькавую даўжыню, а біты хоста і транспартныя парты перажываюць пераўтварэнне. Чытайце кірункі ўваходу і выхаду як асобныя праектныя рашэнні, бо яны настройваюцца асобна, і адзін можа быць гатовы, пакуль другі не гатовы. Нішто ў гэтым апісанні не прадугледжвае стану на паток, таму не чакайце, што супастаўленне будзе адсочваць злучэнні за вас.

Гэта азначае, што 10.80.0.0/16, супастаўлены з 172.28.0.0/16, ператварае 10.80.10.23 у 172.28.10.23. Ён не сціскае /16 у адзін адрас і не замяняе патрабаванне PAT. Ён таксама ахоплівае выбраныя тыпы далучэнняў, сярод якіх VPC і Site-to-Site VPN, але не далучэнні Client VPN, і наладжванне знаходзіцца ў уладальніка транзітнай брамы, а не на баку Anypoint.

Разглядайце гэтую магчымасць як яшчэ адну магчымую кропку кантролю, а не як доказ таго, што ваша разгортванне можа яе выкарыстаць. CloudHub 2.0 дакументуе далучэнні прыватнай прасторы да транзітнай брамы ў уласным акаўнце AWS кліента, з рэгіянальнымі ўмовамі і ўмовамі правамоцнасці, таму пацвердзіце рэальны тып далучэння, яго ўладальніка і пазіцыю падтрымкі пастаўшчыка, перш чым праектаваць вакол новага варыянта.

Трымайце шлях унутры падтрыманых межаў

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

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

Параўнайце тры варыянты ў адной табліцы

Большасці каманд дастаткова адказаць на два пытанні: многія ў адзін ці адзін-да-аднаго, і хто валодае далучэннем. Табліца ніжэй ператварае гэтыя адказы ў пачатковы варыянт.

Чытайце трэці слупок як пытанне разгляду, а не як познюю думку. Карта прэфіксаў, дазволеная на паперы, але наладжаная на далучэнні, якім вы не валодаеце, застаецца заблакаваным праектам, а правіла PAT, якое прапускае трафік, але ламае журналаванне па кожным кліенце, правальвае аўдыт, які ідзе следам.

Праверце супастаўленне, перш чым абяцаць яго

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

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

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