Arendaja kaugjuurdepääs Google Cloud VPC-le: valige õige tee

Arendajal on vaja ühte SSH-seanssi, andmebaasi porti või laia juurdepääsu tosinale privaatsele teenusele, ja kõik need taotlused näevad välja nagu sama küsimus. See ei ole. Sihtkohad, protokollid ja kaasatud identiteedid otsustavad, milline Google Cloudi juurdepääsutee sobib, ja vaikimisi kõige laiema valimine loob tööd, mida teil ei olnud vaja omada.

Kirjutage üles sihtkohad ja protokollid

Loetlege privaatsed aadressid, pordid ja protokollid, mida töö tegelikult vajab, seejärel märkige, milliseid identiteete tuleb eraldi autentida. Andmebaasi port ja privaatne DNS-tsoon on erinevad nõuded ning UDP-teenus välistab ühe alloleva valiku täielikult. Kirjalik nimekiri näitab ka seda, mida te ei anna. See on osa, mille kohta ülevaatajad küsivad.

Tehke seda enne kuulaja avamist. Nimekirjast saab hiljem vastuvõtutest ja see on ainus usaldusväärne viis eristada kitsast tunnelit laiast, mis juhtumisi töötab.

IAP mõne TCP-teenuse jaoks

Identity-Aware Proxy TCP edasisaatmine annab autenditud tunneli sobivatele VM-ressurssidele, ilma teenust internetti paljastamata. Igapäevane vorm on gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, ja ühte porti saab kohapeal edasi saata gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a abil.

Kolm asja peavad kokku sobima: kutsujal on vaja IAP-tunneli juurdepääsu rolli, tulemüür peab lubama IAP-i allikavahemikku ja sihtkoht peab olema instantsil kättesaadav. Tunneli loomise luba ei ole andmebaasi mandaat, SSH-sisselogimine ega RDP-seanss, seega hoidke rakenduse autentimine seal, kuhu see kuulub.

IAP TCP edasisaatmine ei ole kolmanda kihi VPN. See kannab TCP-d valitud sihtkohta, mitte suvalist IP-liiklust ega UDP-d, ja sobib halvasti, kui rakendus vajab privaatset DNS-i paljude teenuste lõikes.

Kaugjuurdepääsu VPN laiemaks kättesaadavuseks

Kui on vaja mitut sihtkohta, protokolli või privaatset DNS-tsooni, on parem vorm selgesõnaliselt hallatav kaugjuurdepääsu VPN VM-il või toetatud seadmes. See juurutus on eraldi Google'i hallatavast Cloud VPN-ist: teie omate kliendi identiteedi registreerimist, tarkvaravärskendusi, kliendi marsruute ja VPC tagasiteid.

Planeerige kogu nimekiri, mitte ainult avalik kuulaja. Kaasake tunnelite bassein, VPC marsruut sinna tagasi, edasisaatmise juhtimine, DNS-i lahendamine ja teenusepõhine juurdepääsupoliitika. VPN, mis ühendub, kuid ei suuda sisemisi nimesid lahendada, nurjab arendaja töövoo täpselt sama täielikult kui see, mis ei ühendu kunagi.

Cloud VPN on saidi värav, mitte sülearvuti profiil

Google Cloud VPN ühendab partnerite väravaid IPsec-i kaudu ja selle korduma kippuvad küsimused eristavad seda sait-sait rolli kliendi ja värava vahelisest juurdepääsust. Tunneli loomine ei too kaasa profiili, mille töötaja sülearvutisse impordib. See erinevus loeb, kui keegi küsib Cloud VPN-i profiili. Vastus on teine toode.

Värav teeb hästi üht: annab kontorivõrgu taga olevatele masinatele marsruudi VPC-sse. See ei autendi iga töötajat ega anna rakenduse lubasid, seega need poliitikad jäävad võrgu- ja rakenduskihile, kus neid saab identiteedipõhiselt rakendada.

Kontrollige ja registreerige

Testige esmalt kõige kitsamat sihtkohta, seejärel seda, mis nõuab DNS-i, ja siis sihtkohta, mis peab jääma keelatuks. Käivitage iga test samast kliendist, mis hakkab seda teed tootmises kasutama, sest administraatori tööjaamast tehtud toimiv test tõestab vähe teise võrguga arendaja sülearvuti kohta.

Registreerige valitud mudel, sellega kaetud sihtkohad, autenditavad identiteedid ja tõrkekäitumine, kui tee pole saadaval. Just see kirje takistab järgmisel taotlusel tunnelit vaikselt laiendada, selle asemel et lisada dokumenteeritud kavandisse üks sihtkoht.