VPN til VPC fungerer, men den administrerte tjenesten får tidsavbrudd
Tunnelen ender ved din kant, ikke ved leverandørens inngangsdør. Klassifiser målet som VM-hostet, VPC-tilkoblet eller bare offentlig før du endrer en rute.
Å nå en administrert database via VPN feiler vanligvis av en grunn ingen skrev i runbooken: tunnelen ender ved kanten av nettverket ditt, mens tjenesten aldri har ligget på din side av den. Rutetabellen ser riktig ut, tunnelen rapporterer at den er oppe, og tilkoblingen får tidsavbrudd likevel. Gå gjennom de fire kontrollene nedenfor i rekkefølge og stopp ved den første der beståelsesbetingelsen ikke er oppfylt, fordi hver kontroll etterpå forutsetter at de foregående besto.
Kontroll én: hvor bor endepunktet egentlig?
En VPN-gateway forbinder to nettverk der du styrer adresseringen. En administrert tjeneste drives bak leverandørens egen inngangsdør, og den døren har én av tre former avhengig av produktet. Hvis du ikke vet hvilken form du har med å gjøre, hjelper ingen mengde rutearbeid, fordi feilen kanskje slett ikke er en 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 |
De fleste bortkastede ettermiddagene kommer av å hoppe over denne klassifiseringen og gå rett til rutetabellen. En leverandørhostet tjeneste med offentlig endepunkt ligger ikke bak tunnelen din uansett hva diagrammet sier, og en VPC-tilkoblet vil aldri dukke opp i et offentlig DNS-svar.
Kontroll to: en VPC-tilkoblet tjeneste som ElastiCache
Cache av den typen adresseres inne i din egen VPC og har ingen internettvendt lytter i det hele tatt. En klient-VPN som ender i samme VPC kan nå dem, men bare når tre betingelser er oppfylt samtidig. Cache-endepunktet må være knyttet til subnett som tunnelen din ser, sikkerhetsgruppen må tillate adressen klientene dine kommer fra, og klientsiden trenger en rute som dekker cachesubnettene.
Den vanlige feilen er å anta at en tilkobling et sted i nærheten teller. Å knytte VPN-en til en annen VPC, eller å lene seg bare på peering, utvider ikke sikkerhetsgruppen til cachen eller rutetabellen til subnettet dens til klientene dine. Når den eksisterende tunnelen ender et annet sted, er en jump host eller en VPN-server plassert inne i den VPC-en den vanlige fallbacken. Den fallbacken er en omvei og ikke et design, og den bør merkes som det i runbooken.
Kontroll tre: et PaaS-endepunkt med offentlig navn
Azure Database for PostgreSQL presenterer et offentlig servernavn. Det gir deg ikke en privat adresse du kan feste i en hosts-fil og rute gjennom en gateway. Tjenesteslutepunkter for virtuelle nettverk begrenser hvilke subnett som kan nå en ressurs; de autoriserer ikke en lokal klient som kommer over en VPN.
Å få privat tilgang betyr å innføre et privat endepunkt eller et private-link-design og deretter legge til en privat DNS-sone slik at det offentlige navnet svarer med det endepunktet i stedet for internett. En VPN kombinert med en tjenesteslutepunktregel er en annen arkitektur som bare ser lik ut i et diagram. App Service følger samme logikk fra motsatt retning: VNet-integrasjon lar appen gjøre utgående kall inn i et VNet, og den skaper ikke en inngående privat vei fra tunnelen din. Inngående privat tilgang krever derfor et privat endepunkt, et App Service Environment eller en gateway foran appen, og hvilke av dem du kan bruke avhenger av planen.
Kontroll fire: produkter med sin egen inngangsdør
Firebase Hosting kan ikke knyttes til en Cloud VPN, fordi hostinglaget er en global front og ikke noe inne i en prosjekt-VPC. Det dokumenterte alternativet er å bygge det kontrollerte inngangspunktet selv, med en proxyinstans eller en lastbalanserer støttet av en bøtte. Uansett slutter nettstedet å være et rent hostingprodukt og blir infrastruktur du nå drifter. Den byttehandelen er verdt å navngi før noen lover at tunnelen vil dekke den.
Private API Gateway ligger nærmere VPC-tjenestesiden: et interface-VPC-endepunkt publiserer et vertsnavn der svarene er private adresser, og trafikk fra lokalene dine kommer over tunnelen eller en dedikert sammenkobling. Endepunktet må være knyttet til API-et, og sertifikatet pluss vertsnavnet må samsvare med det egendefinerte domenet kallerne bruker.
Google Cloud VPN-tunneler binder til peer-IP-adresser, ikke til navn. DNS-videresending konfigureres separat, og derfor kan en tunnel være helt sunn mens oppslag i den fjerne private sonen fortsatt feiler.
Lokaliser deretter grensen
Kjør den samme tilkoblingen fra en VM inne i VPC-en. Når den lykkes der og feiler fra VPN-klienten, ligger gapet mellom klientveien og tjenestens endepunkt: en rute, en sikkerhetsgruppe, en endepunktpolicy eller et navn. Når begge forsøkene feiler, kan ingenting i det nettverket nå tjenesten, og VPN-en var aldri hindringen.
getent hosts db.internal.example
nc -vz db.internal.example 5432Gjør navneoppslaget og portkontrollen hver for seg, fordi de feiler av ulike grunner, og paret forteller deg hvilken halvdel av veien som er brutt. Et navn som løses til en offentlig adresse forteller deg at den private DNS-sonen ikke er i spill.