Jak směrovat provoz SaaS správnému zákaznickému VPN
Překrývající se zákaznické podsítě rozbíjejí sdílené směrování. Zvolte model izolace, připněte každou úlohu k ověřenému nájemci a před spuštěním otestujte cesty mezi nájemci.
Platforma SaaS se připojuje k dvanácti zákaznickým sítím a dva z těchto zákazníků používají 10.20.0.10 pro svou primární databázi. Pracovník, který v úloze dostane tuto adresu, nemá jak zjistit, kterou databázi úloha míní, a sdílená směrovací tabulka ho ochotně pošle do tunelu, na který ukazuje prefix. Řešením není více tunelů; je to rozhodnutí, kde do cesty vstupuje identita nájemce a který model izolace plán adres vyžaduje. O volbě rozhodují tři podmínky: zda se zákaznické prefixy překrývají, jak daleko se chyba může rozšířit a kdo provozuje konektor.
Dvě zákaznické databáze, jedna cílová adresa
IP adresa je místo, ne identita. Požadavek musí nést nájemce, kterého server ověřil, a tento nájemce musí vybrat síťový kontext dříve, než se cíl vyhodnotí.
Když se tak nestane, selhání je tiché. Spojení uspěje, dotaz proběhne a odpověď přijde z databáze nesprávného zákazníka, protože směrovací tabulka měla jeden záznam pro 10.20.0.10. DNS to zhoršuje: kešované jméno vyhodnocené v kontextu nájemce A může znovu použít úloha běžící pro nájemce B. Nic v paketu ty dva nerozliší, takže to nespraví žádná logika opakování.
Nejprve rozhodněte o modelu izolace
Než začnete porovnávat produkty, zapište tři podmínky. Překryv rozhoduje, zda lze adresní prostor vůbec sdílet; poloměr dopadu rozhoduje, zda je chyba směrování tiket podpory, nebo incident; provozní vlastnictví rozhoduje, zda můžete provozovat flotilu konektorů pro každého nájemce.
| 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 |
Pokud jsou prefixy odlišné a politika povoluje řízené rozbočovač, je jeden Transit Gateway s tabulkami tras pro jednotlivé nájemce proveditelný. Asociace připojení volí tabulku tras použitou pro provoz vstupující z tohoto připojení a propagace volí, které trasy se v tabulce objeví. Připojení nájemce spojené pouze s vlastní tabulkou a propagující pouze své vlastní prefixy dosáhne rozbočovače a ničeho jiného. To je rozhodnutí o směrování a zůstává správné jen tak dlouho, dokud nikdo do sdílené tabulky nepřidá výchozí trasu.
Pokud se prefixy překrývají, samotné směrování je nedokáže oddělit. Potřebujete buď samostatný síťový kontext pro každého nájemce, nebo plán překladu, který dá prostoru každého zákazníka jednoznačný význam.
Co izolace Transit Gateway skutečně znamená
Asociace a propagace jsou dva důležité přepínače a snadno se pletou. Asociace odpovídá, v jaké tabulce se hledá paket z tohoto připojení; propagace odpovídá, které tabulky se naučí trasy tohoto připojení. Izolace vzniká tím, že obojí uděláte specifické pro nájemce, ne vytvářením dalších připojení.
Výchozí nastavení všichni-všem je pohodlné a není izolací. Samostatné tabulky tras omezují konektivitu, ale nedávají jedné neměnné cílové adrese dva významy ve stejném směrovacím kontextu. Pokud aplikace vyhodnotí 10.20.0.10 dříve, než zná nájemce, směrovací vrstva už ztratila informaci, kterou by potřebovala.
AWS 23. října 2026 přidala NAT 1:1 na úrovni připojení pro Transit Gateway a Cloud WAN, což mění odpověď na překryv u podporovaných připojení. Dokumentace Transit Gateway NAT popisuje statická, bezstavová mapování IPv4 se stejnými prefixy a zachovanými bity hostitele. Před návrhem kolem toho zkontrolujte podporované typy připojení a regionální omezení.
Připněte úlohu k ověřenému nájemci
Každá úloha by měla nést identitu nájemce ověřenou serverem a tato identita by měla vybrat záznam připojení vlastněný správcem. Záznam uvádí schválený síťový kontext, adresu služby, odkaz na přihlašovací údaje a povolené operace. Nedůvěryhodný požadavek nikdy nesmí dodat vlastní identifikátor VPN, bránu nebo soukromý cíl, protože platné přihlášení není oprávnění sonovat adresní prostor každého připojeného zákazníka.
V návrhu s izolovanými konektory jde práce nájemce A ke konektoru specifickému pro A, který běží ve VPC nájemce A a dosáhne jen na schválené zdroje A. Samostatné kontejnery na jednom hostiteli toto oddělení samy nevytvářejí; musí ho implementovat síťové jmenné prostory, trasy a politika výstupu. Konektor také potřebuje přihlašovací údaje a fronty s rozsahem nájemce, protože soukromá trasa neomezuje sdílené tajemství ani sdílenou pracovní položku. Sdílení pracovníci aplikace jsou v pořádku, pokud se síťový kontext a přihlašovací údaje volí pro každého nájemce, ne pro každého hostitele.
Kontroly stavu by měly uvádět nájemce a fázi: tunel navázán, trasa přítomna a úspěšný skutečný požadavek na službu jsou tři různé signály. Souhrnný počet tunelů, které jsou nahoru, skryje toho jediného zákazníka, jehož konektor je rozbitý.
Otestujte cesty, které musí selhat
Před spuštěním proveďte tři testy. Povolená operace A musí uspět, povolená operace B musí uspět a úloha A záměrně namířená na konektor B nebo jeho přeložený alias musí selhat zavřeně. Potom přerušte jeden tunel a potvrďte, že úloha selže jen pro tohoto nájemce, aniž by spadla do podsítě se stejným číslem jiného zákazníka. Obnovu je také třeba otestovat, protože zastaralá trasa nebo kešované přihlašovací údaje mohou výpadek přežít.
Architektura může být sdílení pracovníci s izolovanými konektory nebo plně oddělené zdroje nájemců. Invariant je stejný: ověřený kontext nájemce vybírá trasu a přihlašovací údaje a žádná změna trasy nikdy neudělí aplikaci oprávnění mezi nájemci.