Fjernadgang for udviklere til en Google Cloud VPC: vælg vejen

En udvikler har brug for én SSH-session, en databaseport eller bred adgang til et dusin private tjenester, og hver af de anmodninger ligner det samme spørgsmål. Det er det ikke. Destinationerne, protokollerne og identiteterne afgør, hvilken adgangsvej i Google Cloud der passer, og at vælge den bredeste som standard skaber arbejde, du ikke havde brug for at eje.

Skriv destinationerne og protokollerne ned

List de private adresser, porte og protokoller, som arbejdet faktisk har brug for, og markér derefter, hvilke identiteter der skal godkendes separat. En databaseport og en privat DNS-zone er forskellige krav, og en UDP-tjeneste udelukker helt en af mulighederne nedenfor. En skriftlig liste viser også, hvad du ikke giver. Det er den del, anmelderne spørger om.

Gør dette, før du åbner en lytter. Listen bliver senere accepttesten, og den er den eneste pålidelige måde at skelne en smal tunnel fra en bred, der tilfældigvis virker.

IAP til et par TCP-tjenester

TCP-videresendelse i Identity-Aware Proxy giver en godkendt tunnel til egnede VM-ressourcer uden at eksponere tjenesten på internettet. Den daglige form er gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, og en 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 skal passe sammen: den kaldende skal have IAP-tunneladgangsrollen, firewallen skal tillade IAP-kildeområdet, og destinationen skal være nåbar på instansen. Tilladelse til at oprette tunnelen er ikke en databaselegitimering, et SSH-login eller en RDP-session, så hold applikationsgodkendelsen, hvor den hører til.

TCP-videresendelse i IAP er ikke en VPN på lag tre. Den bærer TCP til en valgt destination, ikke vilkårlig IP-trafik eller UDP, og den passer dårligt, når en applikation har brug for privat DNS på tværs af mange tjenester.

En VPN til fjernadgang til bredere nåbarhed

Når der kræves flere destinationer, protokoller eller private DNS-zoner, er den bedre form en eksplicit administreret VPN til fjernadgang på en VM eller en understøttet enhed. Den udrulning er adskilt fra Googles administrerede Cloud VPN: du ejer klientidentitetsregistreringen, softwareopdateringerne, klientruterne og VPC-returruterne.

Planlæg hele listen, ikke kun den offentlige lytter. Medtag tunnelpuljen, VPC-ruten tilbage til den, videresendelseskontroller, DNS-opløsning og adgangspolitik per tjeneste. En VPN, der forbinder, men ikke kan opløse interne navne, fejler udviklerens arbejdsgang lige så fuldstændigt som en, der aldrig forbinder.

Cloud VPN er en stedsgateway, ikke en bærbar profil

Google Cloud VPN forbinder peer-gateways over IPsec, og dens ofte stillede spørgsmål skiller den sted-til-sted-rolle fra klient-til-gateway-adgang. At oprette en tunnel giver ikke en profil, som en medarbejder importerer på en bærbar computer. Forskellen betyder noget, når nogen beder om en Cloud VPN-profil. Svaret er et andet produkt.

En gateway gør én ting godt: den giver maskinerne bag et kontornetværk en rute ind i VPC'en. Den godkender ikke hver medarbejder og giver ikke applikationstilladelser, så disse politikker bliver på netværks- og applikationslaget, hvor de kan håndhæves per identitet.

Bekræft og registrér

Test den smalleste destination først, derefter den, der kræver DNS, og så en destination, der skal forblive afvist. Kør hver test fra den samme klient, som skal bruge vejen i produktion, fordi en fungerende test fra en administratorarbejdsstation beviser lidt om en udviklers bærbare computer med et andet netværk.

Registrér den valgte model, de destinationer, den dækker, de identiteter, den godkender, og fejladfærden, når vejen ikke er tilgængelig. Den registrering er det, der forhindrer den næste anmodning i lydløst at udvide tunnelen i stedet for at føje én destination til et dokumenteret design.