Како усмерити SaaS саобраћај на прави VPN клијента
Мреже клијената које се преклапају кваре дељено рутирање. Изаберите модел изолације, вежите сваки посао за провереног закупца и тестирајте путање између закупаца пре покретања.
SaaS платформа се повезује са дванаест клијентских мрежа, и два од тих клијената користе 10.20.0.10 за своју примарну базу података. Радник који добије ту адресу у послу не може да зна коју базу података посао означава, а дељена табела рутирања ће га радо послати у тунел на који показује префикс. Решење нису више тунела; решење је да се одлучи где идентитет закупца улази у путању и који модел изолације захтева план адреса. Три услова одлучују о избору: да ли се префикси клијената преклапају, колико далеко грешка може да се прошири и ко управља конектором.
Две базе података клијената, једна одредишна адреса
IP адреса је локација, а не идентитет. Захтев мора да носи закупца којег је сервер проверио, и тај закупац мора да изабере мрежни контекст пре него што се одредиште разреши.
Када се то не догоди, отказ је тих. Веза успева, упит се извршава, а одговор долази из базе података погрешног клијента јер је табела рутирања имала један запис за 10.20.0.10. DNS то погоршава: кеширано име решено у контексту закупца A може поново да користи посао који ради за закупца B. Ништа у пакету не разликује њих двоје, па то никаква логика поновног покушаја не поправља.
Прво одлучите о моделу изолације
Запишите три услова пре него што упоредите производе. Преклапање одлучује да ли се један адресни простор уопште може делити; полупречник утицаја одлучује да ли је грешка у рутирању тикет за подршку или повреда; оперативно власништво одлучује да ли можете да водите флоту конектора за сваког закупца.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
Ако су префикси различити и политика дозвољава контролисано чвориште, један 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 или његовом преведеном псеудониму мора да не успе затворено. Затим прекините један тунел и потврдите да посао не успева само за тог закупца, без пада на подмрежу са истим бројем другог клијента. Враћање у нормалу такође треба тестирати, јер застарела путања или кеширани акредитиви могу да надживе прекид.
Архитектура може бити заједнички радни процеси са изолованим конекторима или потпуно одвојени ресурси закупаца. Инваријанта је иста: проверени контекст закупца бира путању и акредитиве, и никаква промена путање никада не даје апликацији дозволу између закупаца.