Kako usmjeriti SaaS promet na pravi VPN kupca
Preklapajuće kupčeve podmreže lome zajedničko usmjeravanje. Odaberite model izolacije, vežite svaki posao za provjerenog zakupca i testirajte putanje između zakupaca prije pokretanja.
SaaS platforma se povezuje s dvanaest kupčevih mreža, a dva od tih kupaca koriste 10.20.0.10 za svoju primarnu bazu podataka. Radnik koji u poslu dobije tu adresu nema načina da zna koju bazu podataka posao znači, a zajednička tablica usmjeravanja će ga rado poslati u onaj tunel na koji pokazuje prefiks. Rješenje nije više tunela; ono je odluka o tome gdje identitet zakupca ulazi u putanju i koji model izolacije zahtijeva plan adresa. Tri uslova odlučuju o izboru: da li se kupčevi prefiksi preklapaju, koliko daleko greška može da se širi i ko upravlja konektorom.
Dvije kupčeve baze podataka, jedna odredišna adresa
IP adresa je lokacija, a ne identitet. Zahtjev mora nositi zakupca koji je server provjerio, a taj zakupac mora odabrati mrežni kontekst prije nego što se odredište razriješi.
Kada se to ne dogodi, kvar je tih. Veza uspijeva, upit se izvršava, a odgovor dolazi iz baze podataka pogrešnog kupca jer je tablica usmjeravanja imala jedan unos za 10.20.0.10. DNS to pogoršava: keširano ime razriješeno unutar konteksta zakupca A može ponovo koristiti posao koji radi za zakupca B. Ništa u paketu ne razlikuje njih dvoje, pa to nikakva logika ponovnih pokušaja ne popravlja.
Prvo odlučite o modelu izolacije
Zapišite tri uslova prije nego što uporedite proizvode. Preklapanje odlučuje može li se jedan adresni prostor uopće dijeliti; polumjer štete odlučuje je li greška u usmjeravanju tiket podrške ili povreda; operativno vlasništvo odlučuje možete li pokretati flotu konektora po zakupcu.
| 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 |
Ako su prefiksi različiti i politika dopušta kontrolirano čvorište, jedan Transit Gateway sa tablicama ruta po zakupcu je izvediv. Asocijacija priključka bira tablicu ruta koja se koristi za promet koji ulazi iz tog priključka, a propagacija bira koje se rute pojavljuju u tablici. Priključak zakupca povezan samo sa svojom tablicom i koji propagira samo svoje prefikse doseže čvorište i ništa drugo. To je odluka o usmjeravanju i ostaje ispravna samo dok nitko ne doda zadanu rutu u zajedničku tablicu.
Ako se prefiksi preklapaju, samo usmjeravanje ih ne može razdvojiti. Trebate ili zaseban mrežni kontekst po zakupcu ili plan prevođenja koji prostoru svakog kupca daje nedvosmisleno značenje.
Što izolacija Transit Gatewaya zapravo znači
Asocijacija i propagacija su dvije važne poluge i lako ih je zamijeniti. Asocijacija odgovara u kojoj se tablici traži paket s ovog priključka; propagacija odgovara koje tablice uče rute ovog priključka. Izolacija dolazi od toga da oboje bude specifično za zakupca, a ne od stvaranja više priključaka.
Zadana postavka svi-prema-svima je prikladna i nije izolacija. Zasebne tablice ruta ograničavaju povezanost, ali ne daju jednoj nepromijenjenoj odredišnoj adresi dva značenja unutar istog konteksta usmjeravanja. Ako aplikacija razriješi 10.20.0.10 prije nego što zna zakupca, sloj usmjeravanja je već izgubio informaciju koja bi mu trebala.
AWS je 23 oktobra 2026 dodao NAT 1:1 na razini priključka za Transit Gateway i Cloud WAN, što mijenja odgovor o preklapanju za podržane priključke. Dokumentacija Transit Gateway NAT opisuje statička, bezstanjna IPv4 preslikavanja jednakih prefiksa sa sačuvanim bitovima hosta. Provjerite podržane vrste priključaka i regionalna ograničenja prije nego što dizajnirate oko toga.
Vežite posao za provjerenog zakupca
Svaki posao treba nositi identitet zakupca koji je server provjerio, a taj identitet treba odabrati zapis veze koji posjeduje administrator. Zapis navodi odobreni mrežni kontekst, adresu usluge, referencu vjerodajnica i dopuštene operacije tamo. Nepouzdan zahtjev nikada ne smije dostaviti vlastiti VPN identifikator, pristupnik ili privatni cilj, jer valjana prijava nije dozvola za ispitivanje adresnog prostora svakog povezanog kupca.
U dizajnu s izoliranim konektorima posao zakupca A ide konektoru specifičnom za A koji radi u VPC-u zakupca A i doseže samo odobrene resurse A. Odvojeni kontejneri na jednom hostu ne stvaraju to razdvajanje sami po sebi; mrežni imenski prostori, rute i politika izlaza moraju ga provesti. Konektor također treba vjerodajnice i redove čekanja ograničene na zakupca, jer privatna ruta ne ograničava zajedničku tajnu ni zajedničku radnu stavku. Združeni radnici aplikacije su u redu sve dok se mrežni kontekst i vjerodajnice biraju po zakupcu, a ne po hostu.
Provjere zdravlja trebaju navesti zakupca i fazu: uspostavljen tunel, prisutna ruta i uspješan stvarni zahtjev usluge tri su različita signala. Zbirni broj tunela koji rade sakrit će onog jedinog kupca čiji je konektor pokvaren.
Testirajte putanje koje moraju pasti
Provedite tri testa prije pokretanja. Dopuštena operacija A mora uspjeti, dopuštena operacija B mora uspjeti, a posao A namjerno usmjeren na konektor B ili njegov prevedeni alias mora pasti zatvoreno. Zatim prekinite jedan tunel i potvrdite da posao pada samo za tog zakupca, bez vraćanja na podmrežu s istim brojem drugog kupca. Obnova se također mora testirati, jer zastarjela ruta ili keširane vjerodajnice mogu nadživjeti prekid.
Arhitektura može biti združeni radnici s izoliranim konektorima ili potpuno odvojeni resursi zakupaca. Invarijanta je ista: provjereni kontekst zakupca bira rutu i vjerodajnice, i nijedna promjena rute nikada ne daje aplikaciji dopuštenje između zakupaca.