Ekstern utvikleratkomst til et Google Cloud VPC: velg veien

En utvikler trenger én SSH-økt, en databaseport eller bred atkomst til et dusin private tjenester, og hver av disse forespørslene ser ut som det samme spørsmålet. Det er det ikke. Målene, protokollene og identitetene som er involvert avgjør hvilken atkomstvei i Google Cloud som passer, og å velge den bredeste som standard skaper arbeid du ikke trengte å eie.

Skriv ned målene og protokollene

List opp de private adressene, portene og protokollene som arbeidet faktisk trenger, og marker deretter hvilke identiteter som må autentiseres separat. En databaseport og en privat DNS-sone er ulike krav, og en UDP-tjeneste utelukker helt ett av alternativene nedenfor. En skriftlig liste viser også hva du ikke gir. Det er den delen anmelderne spør om.

Gjør dette før du åpner en lytter. Listen blir senere akseptansetesten, og den er den eneste pålitelige måten å skille en smal tunnel fra en bred som tilfeldigvis virker.

IAP for noen få TCP-tjenester

TCP-videresending i Identity-Aware Proxy gir en autentisert tunnel til egnede VM-ressurser uten å eksponere tjenesten mot internett. Den daglige formen er gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, og én enkelt port kan videresendes lokalt med gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tre ting må stemme: den som kaller trenger IAP-tunnelatkomstrollen, brannmuren må tillate IAP-kildeområdet, og målet må være nåbart på instansen. Tillatelse til å opprette tunnelen er ikke en databaselegitimasjon, en SSH-innlogging eller en RDP-økt, så hold applikasjonsautentiseringen der den hører hjemme.

TCP-videresending i IAP er ikke en VPN på lag tre. Den bærer TCP til et valgt mål, ikke vilkårlig IP-trafikk eller UDP, og den passer dårlig når en applikasjon trenger privat DNS på tvers av mange tjenester.

En VPN for ekstern atkomst for bredere nåbarhet

Når flere mål, protokoller eller private DNS-soner er nødvendige, er den bedre formen en eksplisitt administrert VPN for ekstern atkomst på en VM eller en støttet enhet. Den utrullingen er atskilt fra Googles administrerte Cloud VPN: du eier klientidentitetsregistreringen, programvareoppdateringene, klientrutene og VPC-returrutene.

Planlegg hele listen, ikke bare den offentlige lytteren. Ta med tunnelpoolen, VPC-ruten tilbake til den, videresendingskontroller, DNS-oppløsning og tilgangspolicy per tjeneste. En VPN som kobler til, men ikke kan løse interne navn, feiler utviklerens arbeidsflyt like fullstendig som en som aldri kobler til.

Cloud VPN er en nettstedsporter, ikke en laptop-profil

Google Cloud VPN kobler peer-porter over IPsec, og dens vanlige spørsmål skiller den nettsted-til-nettsted-rollen fra klient-til-port-atkomst. Å opprette en tunnel gir ikke en profil som en ansatt importerer på en laptop. Forskjellen betyr noe når noen ber om en Cloud VPN-profil. Svaret er et annet produkt.

Det en port gjør godt, er å gi maskinene bak et kontornettverk en rute inn i VPC-en. Den autentiserer ikke hver ansatt og gir ikke applikasjonstillatelser, så disse retningslinjene blir på nettverks- og applikasjonslaget der de kan håndheves per identitet.

Bekreft og registrer

Test det smaleste målet først, deretter det som krever DNS, og så et mål som må forbli avvist. Kjør hver test fra den samme klienten som skal bruke veien i produksjon, fordi en fungerende test fra en administratorarbeidsstasjon beviser lite om en utviklers laptop med et annet nettverk.

Registrer den valgte modellen, målene den dekker, identitetene den autentiserer og feilatferden når veien ikke er tilgjengelig. Den registreringen er det som hindrer den neste forespørselen i å utvide tunnelen i det stille i stedet for å legge til ett mål i et dokumentert design.