Attālināta izstrādātāja piekļuve Google Cloud VPC: izvēlieties ceļu

Izstrādātājam nepieciešama viena SSH sesija, datubāzes ports vai plaša piekļuve dučiem privātu pakalpojumu, un katrs no šiem pieprasījumiem izskatās pēc viena un tā paša jautājuma. Tas tā nav. Galamērķi, protokoli un iesaistītās identitātes nosaka, kurš Google Cloud piekļuves ceļš ir piemērots, un plašākā izvēle pēc noklusējuma rada darbu, kas jums nebija jāuzņemas.

Pierakstiet galamērķus un protokolus

Uzskaitiet privātās adreses, portus un protokolus, kas darbam patiešām nepieciešami, pēc tam atzīmējiet, kuras identitātes jāautentificē atsevišķi. Datubāzes ports un privātā DNS zona ir dažādas prasības, un UDP pakalpojums pilnībā izslēdz vienu no tālāk minētajām iespējām. Rakstisks saraksts parāda arī to, ko jūs nepiešķirat. Tieši par šo daļu jautā recenzenti.

Izdariet to pirms klausītāja atvēršanas. Saraksts vēlāk kļūst par pieņemšanas testu, un tas ir vienīgais uzticamais veids, kā atšķirt šauru tuneli no plata, kas darbojas nejauši.

IAP dažiem TCP pakalpojumiem

TCP pāradresācija pakalpojumā Identity-Aware Proxy nodrošina autentificētu tuneli uz atbilstošiem VM resursiem, neatsedzot pakalpojumu internetam. Ikdienas forma ir gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, un vienu portu var pāradresēt lokāli ar gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Trīs lietām jāsakrīt: zvanītājam nepieciešama IAP tuneļa piekļuves loma, ugunsmūrim jāļauj IAP avota diapazons, un galamērķim jābūt sasniedzamam instancē. Atļauja izveidot tuneli nav datubāzes akreditācijas dati, SSH pieteikšanās vai RDP sesija, tāpēc atstājiet lietotnes autentifikāciju tur, kur tai jābūt.

IAP TCP pāradresācija nav trešā slāņa VPN. Tā pārraida TCP uz izvēlētu galamērķi, nevis patvaļīgu IP satiksmi vai UDP, un tā slikti piemērota, ja lietotnei nepieciešams privāts DNS daudzos pakalpojumos.

Attālinātās piekļuves VPN plašākai sasniedzamībai

Ja nepieciešami vairāki galamērķi, protokoli vai privātas DNS zonas, labākā forma ir skaidri pārvaldīts attālinātās piekļuves VPN uz VM vai atbalstītas ierīces. Šis izvietojums ir atsevišķs no Google pārvaldītā Cloud VPN: jums pieder klienta identitātes reģistrācija, programmatūras atjauninājumi, klienta maršruti un VPC atgaitas maršruti.

Plānojiet visu sarakstu, ne tikai publisko klausītāju. Iekļaujiet tuneļu kopu, VPC maršrutu atpakaļ uz to, pāradresācijas vadību, DNS atrisināšanu un katras pakalpojuma piekļuves politiku. VPN, kas savienojas, bet nevar atrisināt iekšējos nosaukumus, izstrādātāja darbplūsmā neizdodas tikpat pilnīgi kā tas, kas nekad nesavienojas.

Cloud VPN ir vietnes vārteja, nevis klēpjdatora profils

Google Cloud VPN savieno partneru vārtejas caur IPsec, un tā bieži uzdotie jautājumi atdala šo vietnes-uz-vietni lomu no klienta-uz-vārteju piekļuves. Tuneļa izveide nerada profilu, ko darbinieks importē klēpjdatorā. Šī atšķirība ir svarīga, ja kāds pieprasa Cloud VPN profilu. Atbilde ir cits produkts.

Tas, ko vārteja dara labi, ir piešķirt biroja tīkla aizmugurē esošajām mašīnām maršrutu uz VPC. Tā neautentificē katru darbinieku un nepiešķir lietotņu atļaujas, tāpēc šīs politikas paliek tīkla un lietotnes slāņos, kur tās var piemērot pēc identitātes.

Pārbaudiet un pierakstiet

Vispirms pārbaudiet šaurāko galamērķi, pēc tam to, kuram nepieciešams DNS, un tad galamērķi, kam jāpaliek noraidītam. Katru testu veiciet no tā paša klienta, kas izmantos ceļu ražošanā, jo veiksmīgs tests no administratora darbstacijas maz pierāda par izstrādātāja klēpjdatoru ar citu tīklu.

Pierakstiet izvēlēto modeli, tā aptvertos galamērķus, autentificētās identitātes un kļūmes uzvedību, kad ceļš nav pieejams. Šis ieraksts ir tas, kas neļauj nākamajam pieprasījumam klusi paplašināt tuneli, nevis pievienot vienu galamērķi dokumentētam dizainam.