Як накіраваць трафік 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 або яго перакладзены псеўданім, павінна пацярпець няўдачу з закрыццём. Затым абарвіце адзін тунель і пераканайцеся, што заданне не спрацоўвае толькі для гэтага тэнанта, не пераходзячы да падсеткі з тым жа нумарам іншага кліента. Аднаўленне таксама трэба праверыць, бо састарэлы маршрут або кэшаваныя ўліковыя дадзеныя могуць перажыць збой.
Архітэктура можа ўяўляць сабой агульныя працоўныя працэсы з ізаляванымі канэктарамі або цалкам асобныя рэсурсы тэнантаў. Інварыянт адзін: правераны кантэкст тэнанта выбірае маршрут і ўліковыя дадзеныя, і ніякае змяненне маршруту ніколі не дае праграме дазволу паміж тэнантамі.