Näin ohjaat SaaS-liikenteen oikeaan asiakas-VPN:ään
Päällekkäiset asiakasverkot rikkovat jaetun reitityksen. Valitse eristysmalli, sido jokainen työ vahvistettuun vuokralaiseen ja testaa vuokralaisten väliset polut ennen käyttöönottoa.
SaaS-alusta yhdistää kahteentoista asiakasverkkoon, ja kaksi näistä asiakkaista käyttää molemmat osoitetta 10.20.0.10 ensisijaiseen tietokantaansa. Työntekijä, joka saa tämän osoitteen työssä, ei voi mitenkään tietää, mitä tietokantaa työ tarkoittaa, ja jaettu reititystaulu lähettää sen mielellään siihen tunneliin, johon etuliite osoittaa. Ratkaisu ei ole lisää tunneleita; ratkaisu on päättää, mistä vuokralaisen identiteetti tulee polulle ja mitä eristysmallia osoitesuunnitelma vaatii. Kolme ehtoa ratkaisevat valinnan: ovatko asiakkaiden etuliitteet päällekkäisiä, kuinka kauas virhe voi levitä ja kuka ylläpitää yhdistintä.
Kaksi asiakastietokantaa, yksi kohdeosoite
IP-osoite on sijainti, ei identiteetti. Pyynnön on kuljetettava vuokralaista, jonka palvelin on vahvistanut, ja tämän vuokralaisen on valittava verkkokonteksti ennen kuin kohde ratkaistaan.
Kun näin ei tapahdu, vika on hiljainen. Yhteys onnistuu, kysely suoritetaan ja vastaus tulee väärän asiakkaan tietokannasta, koska reititystaulussa oli yksi merkintä osoitteelle 10.20.0.10. DNS pahentaa sitä: välimuistiin tallennettu nimi, joka ratkaistiin vuokralaisen A kontekstissa, voidaan käyttää uudelleen vuokralaiselle B ajettavassa työssä. Mikään paketissa ei erota näitä kahta, joten mikään uudelleenyrityslogiikka ei korjaa sitä.
Päätä eristysmallista ensin
Kirjoita kolme ehtoa muistiin ennen tuotteiden vertailua. Päällekkäisyys ratkaisee, voidaanko yhtä osoiteavaruutta jakaa lainkaan; vaikutussäde ratkaisee, onko reititysvirhe tukipyyntö vai tietoturvaloukkaus; operatiivinen omistajuus ratkaisee, voitko ylläpitää yhdistinlaivueen vuokralaista kohden.
| 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 |
Jos etuliitteet ovat erillisiä ja käytäntö sallii hallitun keskittymän, yksi Transit Gateway vuokralaiskohtaisilla reititystauluilla on toteutettavissa. Liitännän assosiaatio valitsee reititystaulun, jota käytetään kyseisestä liitännästä saapuvalle liikenteelle, ja levitys valitsee, mitkä reitit näkyvät taulussa. Vuokralaisen liitäntä, joka on assosioitu vain omaan tauluun ja levittää vain omat etuliitteensä, saavuttaa keskittymän eikä mitään muuta. Se on reitityspäätös, ja se pysyy oikeana vain niin kauan kuin kukaan ei lisää oletusreittiä jaettuun tauluun.
Jos etuliitteet ovat päällekkäisiä, pelkkä reititys ei voi erottaa niitä. Tarvitset joko erillisen verkkokontekstin vuokralaista kohden tai käännössuunnitelman, joka antaa kunkin asiakkaan avaruudelle yksiselitteisen merkityksen.
Mitä Transit Gateway -eristys todella tarkoittaa
Assosiaatio ja levitys ovat kaksi tärkeintä säätöä, ja ne on helppo sekoittaa. Assosiaatio vastaa, missä taulussa tästä liitännästä tulevaa pakettia haetaan; levitys vastaa, mitkä taulut oppivat tämän liitännän reitit. Eristys syntyy siitä, että molemmat tehdään vuokralaiskohtaisiksi, ei siitä, että luodaan lisää liitäntöjä.
Oletuksena kaikki-kaikille -asetus on kätevä eikä ole eristystä. Erilliset reititystaulut rajoittavat yhteyksiä, mutta ne eivät anna yhdelle muuttumattomalle kohdeosoitteelle kahta merkitystä samassa reitityskontekstissa. Jos sovellus ratkaisee 10.20.0.10 ennen kuin se tuntee vuokralaisen, reitityskerros on jo menettänyt tarvitsemansa tiedon.
AWS lisäsi 23. lokakuuta 2026 liitäntätason 1:1 NAT:n Transit Gatewaylle ja Cloud WANille, mikä muuttaa päällekkäisyyden vastausta tuetuille liitännöille. Transit Gateway NAT -dokumentaatio kuvaa staattiset, tilattomat ja samanetuliitteiset IPv4-mappaukset, joissa isäntäbitit säilyvät. Tarkista tuetut liitäntätyypit ja alueelliset rajoitukset ennen kuin suunnittelet sen varaan.
Sido työ vahvistettuun vuokralaiseen
Jokaisen työn tulee kuljettaa palvelimen vahvistamaa vuokralaisen identiteettiä, ja tämän identiteetin tulee valita ylläpitäjän omistama yhteystietue. Tietue nimeää hyväksytyn verkkokontekstin, palvelun osoitteen, tunnistetietoviitteen ja siellä sallitut toiminnot. Epäluotettava pyyntö ei saa koskaan toimittaa omaa VPN-tunnistettaan, yhdyskäytäväänsä tai yksityistä kohdettaan, koska kelvollinen kirjautuminen ei ole lupa tutkia jokaisen yhdistetyn asiakkaan osoiteavaruutta.
Eristettyjen yhdistinten mallissa vuokralaisen A työ menee A-kohtaiseen yhdistimeen, joka toimii A:n VPC:ssä ja voi tavoittaa vain A:n hyväksytyt resurssit. Erilliset säiliöt yhdellä isännällä eivät luo tätä erottelua itsestään; verkkonimialueet, reitit ja lähtevän liikenteen käytäntö on toteutettava se. Yhdistin tarvitsee myös vuokralaiskohtaiset tunnistetiedot ja jonot, sillä yksityinen reitti ei rajaa jaettua salaisuutta tai jaettua työkohdetta. Yhdistetyt sovellustyöntekijät ovat kunnossa, kunhan verkkokonteksti ja tunnistetiedot valitaan vuokralaista eikä isäntää kohden.
Terveystarkistusten tulee nimetä vuokralainen ja vaihe: tunneli muodostettu, reitti olemassa ja todellinen palvelupyyntö onnistunut ovat kolme eri signaalia. Käynnissä olevien tunnelien kokonaismäärä piilottaa sen yhden asiakkaan, jonka yhdistin on rikki.
Testaa polut, joiden on epäonnistuttava
Suorita kolme testiä ennen käyttöönottoa. Sallitun A-toiminnon on onnistuttava, sallitun B-toiminnon on onnistuttava, ja A-työn, joka on tahallaan suunnattu B:n yhdistimeen tai käännettyyn aliakseen, on epäonnistuttava suljetusti. Katkaise sitten yksi tunneli ja varmista, että työ epäonnistuu vain tälle vuokralaiselle, putoamatta toisen asiakkaan samannumeroiseen aliverkkoon. Myös palautuminen on testattava, koska vanhentunut reitti tai välimuistiin tallennetut tunnistetiedot voivat kestää katkoksen yli.
Arkkitehtuuri voi olla yhdistettyjä työntekijöitä eristetyillä yhdistimillä tai täysin erillisiä vuokralaisresursseja. Invariantti on sama: vahvistettu vuokralaiskonteksti valitsee reitin ja tunnistetiedot, eikä mikään reittimuutos koskaan anna sovellukselle lupaa vuokralaisten välillä.