Ako smerovať prevádzku SaaS k správnej zákazníckej VPN
Prekrývajúce sa zákaznícke podsiete lámu zdieľané smerovanie. Vyberte model izolácie, pripnite každú úlohu k overenému nájomcovi a pred spustením otestujte cesty medzi nájomcami.
Platforma SaaS sa pripája k dvanástim zákazníckym sieťam a dvaja z týchto zákazníkov používajú obaja 10.20.0.10 pre svoju primárnu databázu. Pracovník, ktorý v úlohe dostane túto adresu, nemá ako zistiť, ktorú databázu úloha myslí, a zdieľaná smerovacia tabuľka ho ochotne pošle do tunela, na ktorý ukazuje prefix. Riešením nie je viac tunelov; riešením je rozhodnúť, kde do cesty vstupuje identita nájomcu a aký model izolácie si plán adries vyžaduje. O výbere rozhodujú tri podmienky: či sa zákaznícke prefixy prekrývajú, ako ďaleko sa môže chyba rozšíriť a kto prevádzkuje konektor.
Dve zákaznícke databázy, jedna cieľová adresa
IP adresa je miesto, nie identita. Požiadavka musí niesť nájomcu, ktorého server overil, a tento nájomca musí vybrať sieťový kontext predtým, než sa cieľ vyhodnotí.
Keď sa tak nestane, zlyhanie je tiché. Spojenie uspeje, dopyt prebehne a odpoveď príde z databázy nesprávneho zákazníka, pretože smerovacia tabuľka mala jeden záznam pre 10.20.0.10. DNS to zhoršuje: kešované meno vyhodnotené v kontexte nájomcu A môže znova použiť úloha bežiaca pre nájomcu B. Nič v pakete tých dvoch nerozlišuje, takže to nespraví žiadna logika opakovania.
Najprv rozhodnite o modeli izolácie
Pred porovnávaním produktov zapíšte tri podmienky. Prekryv rozhoduje, či sa jednému adresnému priestoru dá vôbec zdieľať; polomer dopadu rozhoduje, či je chyba smerovania tiket podpory alebo incident; prevádzkové vlastníctvo rozhoduje, či môžete prevádzkovať flotilu konektorov pre každého nájomcu.
| 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 |
Ak sú prefixy odlišné a politika povoľuje riadené centrum, jeden Transit Gateway s tabuľkami smerovania pre každého nájomcu je uskutočniteľný. Asociácia pripojenia vyberá tabuľku smerovania používanú pre prevádzku vstupujúcu z tohto pripojenia a propagácia vyberá, ktoré trasy sa v tabuľke objavia. Pripojenie nájomcu spojené iba s vlastnou tabuľkou a propagujúce iba vlastné prefixy dosiahne centrum a nič iné. To je rozhodnutie o smerovaní a zostáva správne iba dovtedy, kým nikto do zdieľanej tabuľky nepridá predvolenú trasu.
Ak sa prefixy prekrývajú, samotné smerovanie ich nedokáže oddeliť. Potrebujete buď samostatný sieťový kontext pre každého nájomcu, alebo plán prekladu, ktorý dá priestoru každého zákazníka jednoznačný význam.
Čo izolácia Transit Gateway skutočne znamená
Asociácia a propagácia sú dva dôležité prepínače a ľahko sa popletú. Asociácia odpovedá, v ktorej tabuľke sa hľadá paket z tohto pripojenia; propagácia odpovedá, ktoré tabuľky sa učia trasy tohto pripojenia. Izolácia vzniká tým, že obe nastavíte špecifické pre nájomcu, nie vytváraním ďalších pripojení.
Predvolené nastavenie všetci-všetkým je pohodlné a nie je izoláciou. Samostatné smerovacie tabuľky obmedzujú konektivitu, ale nedávajú jednej nezmenenej cieľovej adrese dva významy v tom istom kontexte smerovania. Ak aplikácia vyhodnotí 10.20.0.10 skôr, než pozná nájomcu, smerovacia vrstva už stratila informáciu, ktorú by potrebovala.
AWS 23. októbra 2026 pridala NAT 1:1 na úrovni pripojenia pre Transit Gateway a Cloud WAN, čo mení odpoveď na prekryv pri podporovaných pripojeniach. Dokumentácia Transit Gateway NAT opisuje statické, bezstavové mapovania IPv4 s rovnakým prefixom a zachovanými bitmi hostiteľa. Pred návrhom okolo toho skontrolujte podporované typy pripojení a regionálne obmedzenia.
Pripnite úlohu k overenému nájomcovi
Každá úloha by mala niesť identitu nájomcu overenú serverom a táto identita by mala vybrať záznam pripojenia vlastnený správcom. Záznam uvádza schválený sieťový kontext, adresu služby, odkaz na prístupové údaje a povolené operácie. Nedôveryhodná požiadavka nikdy nesmie dodať vlastný identifikátor VPN, bránu alebo súkromný cieľ, pretože platné prihlásenie nie je oprávnenie skúmať adresný priestor každého pripojeného zákazníka.
V návrhu s izolovanými konektormi ide práca nájomcu A ku konektoru špecifickému pre A, ktorý beží vo VPC nájomcu A a dosiahne iba schválené zdroje A. Samostatné kontajnery na jednom hostiteľovi toto oddelenie samy nevytvárajú; musia ho implementovať sieťové menné priestory, trasy a politika výstupu. Konektor tiež potrebuje prístupové údaje a fronty s rozsahom nájomcu, pretože súkromná trasa neobmedzuje zdieľané tajomstvo ani zdieľanú pracovnú položku. Združení pracovníci aplikácie sú v poriadku, pokiaľ sa sieťový kontext a prístupové údaje vyberajú pre každého nájomcu, nie pre každého hostiteľa.
Kontroly stavu by mali uviesť nájomcu a fázu: tunel nadviazaný, trasa prítomná a úspešná skutočná požiadavka na službu sú tri rôzne signály. Súhrnný počet tunelov, ktoré sú hore, skryje toho jediného zákazníka, ktorého konektor je pokazený.
Otestujte cesty, ktoré musia zlyhať
Pred spustením vykonajte tri testy. Povolená operácia A musí uspieť, povolená operácia B musí uspieť a úloha A zámerne namierená na konektor B alebo jeho preložený alias musí zlyhať zavretá. Potom prerušte jeden tunel a potvrďte, že úloha zlyhá iba pre tohto nájomcu, bez pádu do podsiete s rovnakým číslom iného zákazníka. Obnovu treba tiež otestovať, pretože zastaraná trasa alebo kešované prístupové údaje môžu výpadok prežiť.
Architektúra môže byť združení pracovníci s izolovanými konektormi alebo úplne oddelené zdroje nájomcov. Invariant je rovnaký: overený kontext nájomcu vyberá trasu a prístupové údaje a žiadna zmena trasy nikdy neudelí aplikácii oprávnenie medzi nájomcami.