Како да го насочите SaaS сообраќајот кон вистинскиот VPN на клиентот

SaaS платформата се поврзува со дванаесет клиентски мрежи, и два од тие клиенти и двата го користат 10.20.0.10 за нивната примарна база на податоци. Работникот што ја добива таа адреса во задача нема начин да знае која база на податоци ја мисли задачата, а споделената табела за рутирање со задоволство ќе ја испрати до тунелот кон кој покажува префиксот. Решението не е повеќе тунели; решението е да се одлучи каде идентитетот на закупецот влегува во патеката и кој модел на изолација го бара планот за адреси. Три услови ја одлучуваат изборот: дали клиентските префикси се преклопуваат, колку далеку може да се шири грешка и кој го управува конекторот.

Две клиентски бази на податоци, една дестинациска адреса

IP адресата е локација, а не идентитет. Барањето мора да носи закупец што серверот го потврдил, и тој закупец мора да го избере мрежниот контекст пред да се реши дестинацијата.

Кога тоа не се случува, дефектот е тивок. Врската успева, барањето се извршува, и одговорот доаѓа од базата на податоци на погрешниот клиент, бидејќи табелата за рутирање имаше еден запис за 10.20.0.10. DNS го влошува: кеширано име што е решено во контекстот на закупецот A може да се користи повторно од задача што работи за закупецот B. Ништо во пакетот не ги разликува двете, така што ниту една логика за повторен обид не го поправа.

Прво одлучете за моделот на изолација

Запишете ги трите услови пред да споредувате производи. Преклопувањето одлучува дали еден адресен простор воопшто може да се сподели; радиусот на влијание одлучува дали грешка во рутирањето е билет за поддршка или нарушување; оперативната сопственост одлучува дали можете да управувате со флота конектори за секој закупец.

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

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

Што всушност значи изолацијата на Transit Gateway

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

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

AWS на 23 октомври 2026 додаде NAT 1:1 на ниво на приклучок за Transit Gateway и Cloud WAN, што го менува одговорот за преклопување за поддржаните приклучоци. Документацијата за Transit Gateway NAT опишува статични, без состојба, IPv4 мапирања со еднаков префикс и зачувани битови на домаќинот. Проверете ги поддржаните типови приклучоци и регионалните ограничувања пред да проектирате околу тоа.

Врзете ја задачата за потврден закупец

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

Во дизајн со изолирани конектори, работата на закупецот A оди до конектор специфичен за A што работи во VPC на A и може да достигне само одобрени ресурси на A. Оделните контејнери на еден домаќин не го создаваат тоа одвојување сами; мрежните именски простори, рутите и излезната политика мора да го спроведат. Конекторот исто така бара акредитиви и редици ограничени на закупецот, бидејќи приватна рута не ограничува споделена тајна или споделен работен елемент. Здружените апликациски работници се во ред додека мрежниот контекст и акредитивите се избираат за секој закупец, а не за секој домаќин.

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

Тестирајте ги патеките што мора да не успеат

Извршете три теста пред лансирање. Дозволената операција A мора да успее, дозволената операција B мора да успее, а задачата A намерно насочена кон конекторот на B или неговиот преведен псевдоним мора да не успее затворено. Потоа прекинете еден тунел и потврдете дека задачата не успева само за тој закупец, без да падне на подмрежата со истиот број на друг клиент. Враќањето во нормала исто така треба да се тестира, бидејќи застарена рута или кеширани акредитиви можат да ја надживеат пречката.

Архитектурата може да биде здружени работници со изолирани конектори или целосно одвоени ресурси на закупци. Инваријантата е иста: потврдениот контекст на закупецот ги избира рутата и акредитивите, и ниту една промена на рутата никогаш не ѝ дава на апликацијата дозвола меѓу закупци.