Cum să direcționezi traficul SaaS către VPN-ul corect al clientului
Subrețelele de clienți suprapuse strică rutarea partajată. Alegeți un model de izolare, legați fiecare job de un chiriaș verificat și testați căile între chiriași înainte de lansare.
O platformă SaaS se conectează la douăsprezece rețele de clienți, iar doi dintre acești clienți folosesc amândoi 10.20.0.10 pentru baza lor de date principală. Un worker care primește acea adresă într-un job nu are cum să știe ce bază de date înseamnă jobul, iar un tabel de rutare partajat îl va trimite bucuros către tunelul pe care indică prefixul. Soluția nu sunt mai multe tuneluri; soluția este să decizi unde intră identitatea chiriașului în cale și ce model de izolare cere planul de adrese. Trei condiții decid alegerea: dacă prefixele clienților se suprapun, cât de departe se poate răspândi o greșeală și cine operează conectorul.
Două baze de date ale clienților, o adresă de destinație
O adresă IP este o locație, nu o identitate. Cererea trebuie să poarte un chiriaș pe care serverul l-a verificat, iar acel chiriaș trebuie să selecteze contextul de rețea înainte ca destinația să fie rezolvată.
Când nu se întâmplă, eșecul este silențios. Conexiunea reușește, interogarea rulează, iar răspunsul vine din baza de date a clientului greșit pentru că tabelul de rutare avea o singură intrare pentru 10.20.0.10. DNS agravează: un nume din cache rezolvat în contextul chiriașului A poate fi reutilizat de un job care rulează pentru chiriașul B. Nimic din pachet nu le distinge pe cele două, așa că nicio logică de reîncercare nu repară asta.
Decideți mai întâi modelul de izolare
Scrieți cele trei condiții înainte de a compara produse. Suprapunerea decide dacă un spațiu de adrese poate fi partajat; raza de impact decide dacă o greșeală de rutare este un tichet de suport sau o încălcare; proprietatea operațională decide dacă puteți rula o flotă de conectori per chiriaș.
| 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 |
Dacă prefixele sunt distincte și politica permite un hub controlat, un Transit Gateway cu tabele de rutare per chiriaș este fezabil. Asocierea attachment-ului alege tabelul de rutare folosit pentru traficul care intră din acel attachment, iar propagarea alege ce rute apar într-un tabel. Un attachment de chiriaș asociat doar cu propriul tabel și care propagă doar propriile prefixe ajunge la hub și la nimic altceva. Aceasta este o decizie de rutare și rămâne corectă doar atâta timp cât nimeni nu adaugă o rută implicită în tabelul partajat.
Dacă prefixele se suprapun, rutarea singură nu le poate separa. Aveți nevoie fie de un context de rețea distinct per chiriaș, fie de un plan de traducere care dă spațiului fiecărui client un sens neechivoc.
Ce înseamnă de fapt izolarea Transit Gateway
Asocierea și propagarea sunt cele două butoane care contează și este ușor să le confunzi. Asocierea răspunde în ce tabel se caută un pachet din acest attachment; propagarea răspunde ce tabele învață rutele acestui attachment. Izolarea vine din a le face pe amândouă specifice chiriașului, nu din a crea mai multe attachment-uri.
O configurație implicită toți-la-toți este comodă și nu este izolare. Tabelele de rutare separate limitează conectivitatea, dar nu dau unei adrese de destinație neschimbate două semnificații în același context de rutare. Dacă aplicația rezolvă 10.20.0.10 înainte de a cunoaște chiriașul, stratul de rutare a pierdut deja informația de care avea nevoie.
AWS a adăugat pe 23 octombrie 2026 NAT 1:1 la nivel de attachment pentru Transit Gateway și Cloud WAN, ceea ce schimbă răspunsul la suprapunere pentru attachment-urile acceptate. Documentația NAT a Transit Gateway descrie mapări IPv4 statice, fără stare și cu prefix egal, cu biții de gazdă păstrați. Verificați tipurile de attachment acceptate și constrângerile regionale înainte de a proiecta în jurul acestui lucru.
Legați jobul de un chiriaș verificat
Fiecare job ar trebui să poarte o identitate de chiriaș verificată de server, iar acea identitate ar trebui să selecteze o înregistrare de conexiune deținută de administrator. Înregistrarea numește contextul de rețea aprobat, adresa serviciului, referința acreditărilor și operațiunile permise acolo. O cerere neîncrezătoare nu trebuie să furnizeze niciodată propriul identificator VPN, gateway sau țintă privată, deoarece o autentificare validă nu este permisiunea de a sonda spațiul de adrese al fiecărui client conectat.
Într-un design cu conectori izolați, munca chiriașului A merge la un conector specific pentru A care rulează în VPC-ul lui A și poate ajunge doar la resursele aprobate ale lui A. Containerele separate pe un singur host nu creează acea separare de la sine; spațiile de nume de rețea, rutele și politica de ieșire trebuie să o implementeze. Conectorul are nevoie și de acreditări și cozi cu domeniu de chiriaș, deoarece o rută privată nu limitează un secret partajat sau un element de lucru partajat. Workerii de aplicație grupați sunt în regulă atâta timp cât contextul de rețea și acreditările sunt alese per chiriaș, nu per host.
Verificările de sănătate ar trebui să numească chiriașul și etapa: tunel stabilit, rută prezentă și o cerere reală de serviciu reușită sunt trei semnale diferite. Un număr agregat de tuneluri active va ascunde singurul client al cărui conector este stricat.
Testați căile care trebuie să eșueze
Rulați trei teste înainte de lansare. O operațiune A permisă trebuie să reușească, o operațiune B permisă trebuie să reușească, iar un job A îndreptat deliberat către conectorul lui B sau aliasul său tradus trebuie să eșueze închis. Apoi rupeți un tunel și confirmați că jobul eșuează doar pentru acel chiriaș, fără a cădea în subrețeaua cu același număr a altui client. Și restaurarea trebuie testată, deoarece o rută învechită sau acreditări din cache pot supraviețui întreruperii.
Arhitectura poate fi workeri grupați cu conectori izolați sau resurse de chiriaș complet separate. Invariantul este același: contextul de chiriaș verificat selectează ruta și acreditările, iar nicio schimbare de rută nu acordă vreodată permisiune de aplicație între chiriași.