Anypoint VPN или NAT во Transit Gateway: каде се врши преводот

Барањето за NAT не е барање додека не ги именува адресите што се менуваат и компонентата на која ѝ е дозволено да ги менува. Кај поврзувањето со MuleSoft таа одлука има три влеза: дали на backend-от му треба превод на порти многу-кон-еден или псевдоним на префикс еден-кон-еден, дали AWS врската што навистина ја поседувате може да го изврши тоа мапирање, и дали целиот пат останува во комбинација што добавдувачот ја поддржува. Ако тоа го згрешите, ќе изградите лабораторија што работи, но паѓа на прегледот.

Единствената фиксна точка е дека самиот Anypoint VPN не е уред за превод. Документацијата на CloudHub 2.0 го наведува NAT како неподдржан таму, така што секој дизајн што претпоставува дека тунелот ќе ги сокрие адресите на вашите работници е веќе расипан.

Одредете што треба да прави преводот

Ако многу апликациски работници треба да изгледаат на backend-от како една адреса, барањето е споделен превод на изворот, обично SNAT или PAT со состојба на огнен ѕид што вие го контролирате. Тој елемент мора да стои на одобрен пат, да ја чува својата состојба во целиот животен век на текот и да го гледа повратниот сообраќај за секоја врска што ја препишал. Губењето состојба на средина од сесијата не ја влошува врската; ја завршува. Пар огнени ѕидови што одбива да сподели состојба за превод ќе ја испушти секоја сесија што по префрлањето ќе слета на резервниот член. Димензионирајте го тој елемент за истовремени текови, а не за пропусност.

Ако пак две мрежи се преклопуваат и секој домаќин бара посебен псевдоним, барањето е план на адреси еден-кон-еден со недвосмислени мапирани префикси, соодветни рути и резолуција на имиња што се согласува со мапирањето. Криењето на секој работник зад една адреса не е поевтина верзија од тоа, а заменувањето едно со друго на преглед на дизајн е начинот на кој проектите губат едно тримесечје.

Запишете ја одлуката со конкретни термини пред да изберете производ: првичен извор, првично одредиште, преведена вредност, насока на иницирање, сопственик на преведувачот и очекувана рута на одговор. Додајте и каков идентитет ќе задржат логовите на backend-от, зашто дизајн што ги крие сите извори ја уништува и ревизијата по клиент.

Проверете дали 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 правило во тунел што работи. Одговорот на backend-от мора да се врати низ истиот елемент за превод, а здравиот излезен тунел не кажува ништо за тој повратен пат.

За рутата преку транзитната порта направете попис на врската на приватниот простор, релевантните табели за рути, локалната врска и деловите што клиентот навистина може да ги конфигурира. Тоа е друга архитектура на поврзување, а не квадратче за NAT зашрафено на постоечка врска Anypoint VPN, и границата на поддршка се движи со неа.

Споредете ги трите опции во една табела

Повеќето тимови треба да одговорат само на две прашања: многу-кон-еден или еден-кон-еден, и кој ја поседува врската. Табелата подолу ги претвора тие одговори во почетна опција.

Читајте ја третата колона како прашање за преглед, а не како дополнителна мисла. Карта на префикси дозволена на хартија, но конфигурирана на врска што не ја поседувате, сè уште е блокиран проект, а правило за PAT што пропушта сообраќај, но го крши логирањето по клиент, паѓа на ревизијата што следи.

Проверете го мапирањето пред да го ветите

Пратете една свежа апликациска операција по патот и потврдете го одговорот, не само барањето. Прашајте го сопственикот на backend-от која изворна адреса ја запишале нивните логови, проверете дали ракувањето со адресното семејство одговара на планот во двете насоки и потврдете дека патот што треба да биде одбиен сè уште е одбиен. Стара врска не докажува ништо за мапирањето што штотуку го сменивте.

Држете ја автентикацијата на backend-от независна од тоа која преведена адреса го задоволува нејзиниот список за дозвола, зашто мапирањето е мрежна инсталација, а не одлука за контрола на пристап. Во моментот кога ресетирање лозинка зависи од NAT префикс, секоја идна промена на опсегот станува прекин.

Пред одобрување запишете ги трите одговори: тип на превод, сопственик на преведувачот и поддржаната врска или пат на производот што го носи. Ако било кој од нив е сè уште претпоставка, дизајнот не е подготвен за прозорец на промени.