Ekstern utviklaratkomst til eit Google Cloud VPC: vel vegen

Ein utviklar treng éi SSH-økt, ein databaseport eller brei atkomst til eit dusin private tenester, og kvar av desse førespurnadene ser ut som det same spørsmålet. Det er det ikkje. Måla, protokollane og identitetane som er involverte avgjer kva atkomstveg i Google Cloud som passar, og å velje den breiaste som standard skapar arbeid du ikkje trongde å eige.

Skriv ned måla og protokollane

List opp dei private adressene, portane og protokollane som arbeidet faktisk treng, og merk deretter kva identitetar som må autentiserast separat. Ein databaseport og ei privat DNS-sone er ulike krav, og ei UDP-teneste utelukkar heilt eitt av alternativa nedanfor. Ei skriftleg liste viser òg kva du ikkje gir. Det er den delen meldarane spør om.

Gjer dette før du opnar ein lyttar. Lista blir seinare akseptansetesten, og ho er den einaste pålitelege måten å skilje ein smal tunnel frå ein brei som tilfeldigvis verkar.

IAP for nokre få TCP-tenester

TCP-vidaresending i Identity-Aware Proxy gir ein autentisert tunnel til eigna VM-ressursar utan å eksponere tenesta mot internett. Den daglege forma er gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, og éin einaste port kan vidaresendast 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 kallar treng IAP-tunnelatkomstrolla, brannmuren må tillate IAP-kjeldeområdet, og målet må vere nåbart på instansen. Løyve til å opprette tunnelen er ikkje ein databaslegitimasjon, ei SSH-innlogging eller ei RDP-økt, så hald applikasjonsautentiseringa der ho høyrer heime.

TCP-vidaresending i IAP er ikkje eit VPN på lag tre. Ho ber TCP til eit valt mål, ikkje vilkårleg IP-trafikk eller UDP, og ho passar dårleg når ein applikasjon treng privat DNS på tvers av mange tenester.

Eit VPN for ekstern atkomst for breiare nåbarheit

Når fleire mål, protokollar eller private DNS-soner er nødvendige, er den betre forma eit eksplisitt administrert VPN for ekstern atkomst på ein VM eller eining som er støtta. Den utrullinga er skild frå Googles administrerte Cloud VPN: du eig klientidentitetsregistreringa, programvareoppdateringane, klientrutene og VPC-returrutene.

Planlegg heile lista, ikkje berre den offentlege lyttaren. Ta med tunnelpoolen, VPC-ruta tilbake til han, vidaresendingskontrollar, DNS-oppløysing og tilgangspolicy per teneste. Eit VPN som koplar til, men ikkje kan løyse interne namn, feilar arbeidsflyten til utviklaren like fullstendig som eit som aldri koplar til.

Cloud VPN er ein nettstadsporter, ikkje ein laptop-profil

Google Cloud VPN koplar peer-portar over IPsec, og dei vanlege spørsmåla hans skil den nettstad-til-nettstad-rolla frå klient-til-port-atkomst. Å opprette ein tunnel gir ikkje ein profil som ein tilsett importerer på ein laptop. Skilnaden betyr noko når nokon ber om ein Cloud VPN-profil. Svaret er eit anna produkt.

Det ein port gjer godt, er å gi maskinene bak eit kontornettverk ei rute inn i VPC-en. Han autentiserer ikkje kvar tilsett og gir ikkje applikasjonstilgangar, så desse retningslinjene blir på nettverks- og applikasjonslaget der dei kan handhevast per identitet.

Stadfest og registrer

Test det smalaste målet først, deretter det som krev DNS, og så eit mål som må halde fram med å vere avvist. Køyr kvar test frå den same klienten som skal bruke vegen i produksjon, fordi ein fungerande test frå ein administratorarbeidsstasjon beviser lite om ein utviklarlaptop med eit anna nettverk.

Registrer den valde modellen, måla han dekkjer, identitetane han autentiserer og feilåtferda når vegen ikkje er tilgjengeleg. Den registreringa er det som hindrar den neste førespurnaden i å utvide tunnelen i det stille i staden for å leggje til eitt mål i eit dokumentert design.