Kuidas suunata SaaS-liiklus õigesse kliendi-VPN-i
Kattuvad kliendi alamvõrgud lõhuvad ühise marsruutimise. Valige isolatsioonimudel, siduge iga töö kontrollitud rentnikuga ja testige rentnikevahelisi teid enne käivitamist.
SaaS-platvorm ühendub tosina kliendivõrguga ning kaks neist klientidest kasutavad mõlemad aadressi 10.20.0.10 oma peamise andmebaasi jaoks. Töötaja, kes saab selle aadressi töös, ei saa kuidagi teada, millist andmebaasi töö mõtleb, ja ühine marsruutimistabel saadab selle hea meelega sellesse tunnelisse, kuhu eesliide osutab. Lahendus ei ole rohkem tunneleid; lahendus on otsustada, kust rentniku identiteet teele siseneb ja millist isolatsioonimudelit aadressiplaan nõuab. Kolm tingimust otsustavad valiku: kas kliendi eesliited kattuvad, kui kaugele viga levida võib ja kes konnektorit haldab.
Kaks kliendi andmebaasi, üks sihtaadress
IP-aadress on asukoht, mitte identiteet. Päring peab kandma rentnikku, mille server on kontrollinud, ja see rentnik peab valima võrgukonteksti enne, kui siht lahendatakse.
Kui seda ei juhtu, on tõrge vaikne. Ühendus õnnestub, päring jookseb ja vastus tuleb vale kliendi andmebaasist, sest marsruutimistabelis oli aadressi 10.20.0.10 jaoks üks kirje. DNS teeb selle hullemaks: rentniku A kontekstis lahendatud vahemällu salvestatud nime võib uuesti kasutada rentniku B jaoks jooksev töö. Midagi paketis ei erista neid kahte, seega ei paranda seda ükski korduskatse loogika.
Otsustage esmalt isolatsioonimudeli üle
Kirjutage kolm tingimust üles enne toodete võrdlemist. Kattuvus otsustab, kas üht aadressiruumi saab üldse jagada; mõjuraadius otsustab, kas marsruutimisviga on tugipilet või turvarike; tegevusomand otsustab, kas saate käitada rentniku kohta konnektorite voogu.
| 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 |
Kui eesliited on erinevad ja poliitika lubab juhitud jaoturit, on üks Transit Gateway rentnikupõhiste marsruutimistabelitega teostatav. Ühenduse seostamine valib marsruutimistabeli, mida kasutatakse sellest ühendusest siseneva liikluse jaoks, ja levitamine valib, millised marsruudid tabelisse ilmuvad. Rentniku ühendus, mis on seotud ainult oma tabeliga ja levitab ainult oma eesliiteid, jõuab jaoturini ja mitte kuhugi mujale. See on marsruutimisotsus ja jääb õigeks ainult seni, kuni keegi ei lisa ühisesse tabelisse vaikemarsruuti.
Kui eesliited kattuvad, ei suuda ainult marsruutimine neid eraldada. Teil on vaja kas rentnikupõhist eraldi võrgukonteksti või tõlkeplaani, mis annab iga kliendi ruumile üheselt mõistetava tähenduse.
Mida Transit Gateway isolatsioon tegelikult tähendab
Seostamine ja levitamine on kaks olulist nuppu ja neid on lihtne segi ajada. Seostamine vastab, millisest tabelist selle ühenduse paketti otsitakse; levitamine vastab, millised tabelid selle ühenduse marsruudid õpivad. Isolatsioon tuleneb mõlema rentnikupõhiseks muutmisest, mitte rohkematest ühendustest.
Vaikimisi kõik-kõigile seadistus on mugav ega ole isolatsioon. Eraldi marsruutimistabelid piiravad ühenduvust, kuid ei anna ühele muutumatule sihtaadressile kahte tähendust sama marsruutimiskonteksti sees. Kui rakendus lahendab aadressi 10.20.0.10 enne, kui ta rentnikku teab, on marsruutimiskiht juba kaotanud teabe, mida ta vajaks.
AWS lisas 23. oktoobril 2026 Transit Gateway ja Cloud WAN jaoks ühendustasemel 1:1 NAT-i, mis muudab kattuvuse vastust toetatud ühenduste puhul. Transit Gateway NAT dokumentatsioon kirjeldab staatilisi, olekuta võrdse eesliitega IPv4 vastendusi, kus hostibitid on säilitatud. Kontrollige toetatud ühenduse tüüpe ja piirkondlikke piiranguid enne, kui selle ümber projekteerite.
Siduge töö kontrollitud rentnikuga
Iga töö peaks kandma serveri kontrollitud rentniku identiteeti ja see identiteet peaks valima administraatori omanduses oleva ühenduskirje. Kirje nimetab kinnitatud võrgukonteksti, teenuse aadressi, identimisandmete viite ja seal lubatud toimingud. Ebausaldusväärne päring ei tohi kunagi esitada oma VPN-identifikaatorit, lüüsi ega privaatset sihti, sest kehtiv sisselogimine ei ole luba uurida iga ühendatud kliendi aadressiruumi.
Isoleeritud konnektoritega lahenduses läheb rentniku A töö A-spetsiifilisse konnektorisse, mis töötab A VPC-s ja pääseb ligi ainult A kinnitatud ressurssidele. Eraldi konteinerid ühel hostil ei loo seda eraldust iseenesest; võrgu nimeruumid, marsruudid ja väljundpoliitika peavad selle rakendama. Konnektor vajab ka rentnikuga piiratud identimisandmeid ja järjekordi, sest privaatne marsruut ei piira ühist saladust ega ühist tööüksust. Koondatud rakendustöötajad on korras seni, kuni võrgukontekst ja identimisandmed valitakse rentniku, mitte hosti kaupa.
Tervisekontrollid peaksid nimetama rentniku ja etapi: tunnel loodud, marsruut olemas ja tõeline teenusepäring õnnestunud on kolm erinevat signaali. Töötavate tunnelite koondarv varjab selle ühe kliendi, kelle konnektor on katki.
Testige teid, mis peavad ebaõnnestuma
Tehke enne käivitamist kolm testi. Lubatud A-toiming peab õnnestuma, lubatud B-toiming peab õnnestuma ja A-töö, mis on meelega suunatud B konnektorile või tõlgitud aliasele, peab ebaõnnestuma suletult. Seejärel katkestage üks tunnel ja kinnitage, et töö ebaõnnestub ainult selle rentniku jaoks, langemata teise kliendi sama numbriga alamvõrku. Taastamine tuleks samuti ära testida, sest aegunud marsruut või vahemällu salvestatud identimisandmed võivad katkestuse üle elada.
Arhitektuur võib olla koondatud töötajad isoleeritud konnektoritega või täielikult eraldatud rentnikuressursid. Invariant on sama: kontrollitud rentnikukontekst valib marsruudi ja identimisandmed ning ükski marsruudimuudatus ei anna rakendusele kunagi luba rentnike vahel.