VPN til VPC virker, men den administrerede tjeneste får timeout
Tunnelen slutter ved din kant, ikke ved udbyderens fordør. Klassificér målet som VM-hostet, VPC-tilsluttet eller kun offentligt, før du ændrer en rute.
Adgang til en administreret database via VPN fejler normalt af en grund, som ingen skrev i runbooken: tunnelen slutter ved kanten af dit netværk, mens tjenesten aldrig har ligget på din side af den. Rutetabellen ser rigtig ud, tunnelen rapporterer, at den er oppe, og forbindelsen får alligevel timeout. Udfør de fire kontroller nedenfor i rækkefølge og stop ved den første, hvis beståelsesbetingelse ikke er opfyldt, fordi hver kontrol derefter forudsætter, at de foregående bestod.
Kontrol et: hvor bor endepunktet egentlig?
En VPN-gateway forbinder to netværk, hvis adressering du styrer. En administreret tjeneste drives bag udbyderens egen fordør, og den dør har en af tre former afhængigt af produktet. Hvis du ikke ved, hvilken form du har med at gøre, hjælper ingen mængde rutearbejde, fordi fejlen måske slet ikke er en rutefejl.
| 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 spildte eftermiddage kommer af at springe denne klassificering over og gå direkte til rutetabellen. En udbyderhostet tjeneste med et offentligt endepunkt er ikke bag din tunnel, uanset hvad diagrammet siger, og en VPC-tilsluttet vil aldrig dukke op i et offentligt DNS-svar.
Kontrol to: en VPC-tilsluttet tjeneste som ElastiCache
Cache af den slags adresseres inde i din egen VPC og har slet ingen internetvendt lytter. En klient-VPN, der slutter i samme VPC, kan nå dem, men kun når tre betingelser passer sammen. Cache-endepunktet skal være knyttet til undernet, som din tunnel kan se, dens sikkerhedsgruppe skal tillade den adresse, dine klienter kommer fra, og klientsiden har brug for en rute, der dækker cacheundernettene.
Den almindelige fejl er at antage, at en forbindelse et sted i nærheden tæller. At knytte VPN'en til en anden VPC eller kun at læne sig op ad peering udvider ikke cacheens sikkerhedsgruppe eller dens undernets rutetabel til dine klienter. Når den eksisterende tunnel slutter et andet sted, er en jump host eller en VPN-server placeret inde i den VPC den sædvanlige fallback. Den fallback er en omvej snarere end et design, og den bør mærkes som sådan i runbooken.
Kontrol tre: et PaaS-endepunkt med et offentligt navn
Azure Database for PostgreSQL præsenterer et offentligt servernavn. Den giver dig ikke en privat adresse, som du kan fastgøre i en hosts-fil og route gennem en gateway. Tjenesteslutpunkter for virtuelle netværk begrænser, hvilke undernet der kan nå en ressource; de autoriserer ikke en lokal klient, der ankommer over en VPN.
At opnå privat adgang betyder at indføre et privat endepunkt eller et private-link-design og derefter tilføje en privat DNS-zone, så det offentlige navn svarer med det endepunkt i stedet for internettet. En VPN kombineret med en tjenesteslutpunktsregel er en anden arkitektur, som kun ser ens ud i et diagram. App Service følger samme logik fra den anden retning: VNet-integration lader appen foretage udgående kald ind i et VNet, og den skaber ikke en indgående privat vej fra din tunnel. Indgående privat adgang kræver derfor et privat endepunkt, et App Service Environment eller en gateway foran appen, og hvilke af dem du kan bruge afhænger af planen.
Kontrol fire: produkter med deres egen fordør
Firebase Hosting kan ikke knyttes til en Cloud VPN, fordi hostinglaget er en global frontend snarere end noget inde i et projekts VPC. Det dokumenterede alternativ er selv at bygge det kontrollerede indgangspunkt med en proxyinstans eller en load balancer, der bakkes op af en bucket. Uanset hvad holder webstedet op med at være et rent hostingprodukt og bliver infrastruktur, som du nu driver. Den byttehandel er værd at navngive, før nogen lover, at tunnelen dækker den.
Private API Gateway ligger tættere på VPC-tjenestesiden: et interface-VPC-endepunkt offentliggør et værtsnavn, hvis svar er private adresser, og trafik fra dine lokaler ankommer over tunnelen eller en dedikeret interconnect. Endepunktet skal være knyttet til API'en, og certifikatet plus værtsnavnet skal matche det brugerdefinerede domæne, som kalderne bruger.
Google Cloud VPN-tunneler binder til peer-IP-adresser, ikke til navne. DNS-videresendelse konfigureres separat, og derfor kan en tunnel være helt sund, mens opslag i den fjerne private zone stadig fejler.
Lokaliser derefter grænsen
Kør den samme forbindelse fra en VM inde i VPC'en. Når den lykkes der og fejler fra VPN-klienten, ligger hullet mellem klientens vej og tjenestens endepunkt: en rute, en sikkerhedsgruppe, en endepunktsregel eller et navn. Når begge forsøg fejler, kan intet i det netværk nå tjenesten, og VPN'en var aldrig forhindringen.
getent hosts db.internal.example
nc -vz db.internal.example 5432Udfør navneopslaget og portkontrollen hver for sig, fordi de fejler af forskellige grunde, og parret fortæller dig, hvilken halvdel af vejen der er brudt. Et navn, der opløses til en offentlig adresse, fortæller dig, at den private DNS-zone ikke er i spil.