VPN til VPC fungerer, men den styrte tenesta får tidsavbrot
Tunnelen endar ved kanten din, ikkje ved inngangsdøra til leverandøren. Klassifiser målet som VM-host, VPC-tilknytt eller berre offentleg før du endrar ei rute.
Å nå ei styrt database via VPN feilar vanlegvis av ein grunn ingen skreiv i runbooken: tunnelen endar ved kanten av nettverket ditt, medan tenesta aldri har lege på di side av det. Rutetabellen ser rett ut, tunnelen rapporterer at han er oppe, og tilkoplinga får tidsavbrot likevel. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje og stopp ved den første der vilkåret for å passere ikkje er oppfylt, fordi kvar kontroll etterpå føreset at dei førre gjekk gjennom.
Kontroll éin: kvar bur endepunktet eigentleg?
Ein VPN-gateway knyter saman to nettverk der du styrer adresseringa. Ei styrt teneste blir driven bak leverandøren si eiga inngangsdør, og den døra har éin av tre former avhengig av produktet. Viss du ikkje veit kva form du har med å gjere, hjelper ingen mengd rutearbeid, fordi feilen kanskje slett ikkje er ein rutefeil.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Dei fleste bortkasta ettermiddagane kjem av å hoppe over denne klassifiseringa og gå rett til rutetabellen. Ei leverandørhosta teneste med offentleg endepunkt ligg ikkje bak tunnelen din uansett kva diagrammet seier, og ei VPC-tilknytt vil aldri dukke opp i eit offentleg DNS-svar.
Kontroll to: ei VPC-tilknytt teneste som ElastiCache
Cache av den typen blir adressert inne i din eigen VPC og har ingen internettvend lytter i det heile. Ein klient-VPN som endar i same VPC kan nå dei, men berre når tre vilkår er oppfylte samtidig. Cache-endepunktet må vere knytt til subnett som tunnelen din ser, tryggingsgruppa må tillate adressa klientane dine kjem frå, og klientsida treng ei rute som dekkjer cachesubnetta.
Den vanlege feilen er å tru at ei tilkopling ein stad i nærleiken tel. Å knyte VPN-en til ein annan VPC, eller å lene seg berre på peering, utvidar ikkje tryggingsgruppa til cachen eller rutetabellen til subnettet dens til klientane dine. Når den eksisterande tunnelen endar ein annan stad, er ein jump host eller ein VPN-server plassert inne i den VPC-en den vanlege fallbacken. Den fallbacken er ein omveg og ikkje eit design, og han bør merkast som det i runbooken.
Kontroll tre: eit PaaS-endepunkt med offentleg namn
Azure Database for PostgreSQL presenterer eit offentleg servernamn. Det gir deg ikkje ei privat adresse du kan feste i ei hosts-fil og rute gjennom ein gateway. Tenesteslutepunkt for virtuelle nettverk avgrensar kva subnett som kan nå ein ressurs; dei autoriserer ikkje ein lokal klient som kjem over ein VPN.
Å få privat tilgang tyder å innføre eit privat endepunkt eller eit private-link-design og deretter leggje til ei privat DNS-sone slik at det offentlege namnet svarar med det endepunktet i staden for internett. Ein VPN kombinert med ein tenesteslutepunktregel er ein annan arkitektur som berre ser lik ut i eit diagram. App Service følgjer same logikk frå motsett retning: VNet-integrering lèt appen gjere utgåande kall inn i eit VNet, og ho skaper ikkje ein inngåande privat veg frå tunnelen din. Inngåande privat tilgang krev derfor eit privat endepunkt, eit App Service Environment eller ein gateway framfor appen, og kva av dei du kan bruke avheng av planen.
Kontroll fire: produkt med si eiga inngangsdør
Firebase Hosting kan ikkje knytast til ein Cloud VPN, fordi hostinglaget er ein global front og ikkje noko inne i ein prosjekt-VPC. Det dokumenterte alternativet er å byggje det kontrollerte inngangspunktet sjølv, med ein proxyinstans eller ein lastbalansar støtta av ei bøtte. Uansett sluttar nettstaden å vere eit reint hostingprodukt og blir infrastruktur du no driv. Den byttehandelen er verd å namngi før nokon lovar at tunnelen vil dekkje han.
Private API Gateway ligg nærare VPC-tenestesida: eit interface-VPC-endepunkt publiserer eit vertsnamn der svara er private adresser, og trafikk frå lokala dine kjem over tunnelen eller ei dedikert samankopling. Endepunktet må vere knytt til API-et, og sertifikatet pluss vertsnamnet må samsvare med det eigendefinerte domenet kallarane brukar.
Google Cloud VPN-tunnelar bind til peer-IP-adresser, ikkje til namn. DNS-vidaresending blir konfigurert separat, og derfor kan ein tunnel vere heilt sunn medan oppslag i den fjerne private sona framleis feilar.
Lokaliser deretter grensa
Køyr den same tilkoplinga frå ein VM inne i VPC-en. Når ho lykkast der og feilar frå VPN-klienten, ligg gapet mellom klientvegen og endepunktet til tenesta: ei rute, ei tryggingsgruppe, ein endepunktpolicy eller eit namn. Når båe forsøka feilar, kan ingenting i det nettverket nå tenesta, og VPN-en var aldri hindringa.
getent hosts db.internal.example
nc -vz db.internal.example 5432Gjer namneoppslaget og portkontrollen kvar for seg, fordi dei feilar av ulike grunnar, og paret fortel deg kva halvdel av vegen som er broten. Eit namn som blir løyst til ei offentleg adresse fortel deg at den private DNS-sona ikkje er i spel.