Fora aliro de programisto al Google Cloud VPC: elektu la ĝustan vojon

Programisto bezonas unu SSH-sesion, unu datumbazan pordon aŭ vastan aliron al dekduo da privataj servoj, kaj ĉiu el tiuj petoj aspektas kiel la sama demando. Ĝi ne estas. La celoj, la protokoloj kaj la koncernaj identecoj decidas, kiu alirvojo en Google Cloud taŭgas, kaj elekti la plej vastan defaŭlte kreas laboron, kiun vi ne devis posedi.

Skribu la celojn kaj protokolojn

Listigu la privatajn adresojn, pordojn kaj protokolojn, kiujn la laboro vere bezonas, poste marku, kiuj identecoj devas esti aŭtentigataj aparte. Datumbaza pordo kaj privata DNS-zono estas malsamaj postuloj, kaj UDP-servo tute ekskludas unu el la subaj opcioj. Skribita listo ankaŭ montras, kion vi ne donas. Tio estas la parto, pri kiu demandas revizantoj.

Faru tion antaŭ ol malfermi aŭskultanton. La listo poste fariĝas la akcepta testo, kaj ĝi estas la sola fidinda maniero distingi mallarĝan tunelon de vasta, kiu hazarde funkcias.

IAP por kelkaj TCP-servoj

TCP-plusendado en Identity-Aware Proxy donas aŭtentigitan tunelon al taŭgaj VM-rimedoj sen malkaŝi la servon al la interreto. La ĉiutaga formo estas gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, kaj unu pordon eblas plusendi loke per gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tri aferoj devas koincidi: la alvokanto bezonas la rolon de aliro al la IAP-tunelo, la fajroŝirmilo devas permesi la IAP-fontogamon, kaj la celo devas esti atingebla sur la instanco. Rajtigo krei la tunelon ne estas datumbaza akreditaĵo, SSH-saluto aŭ RDP-sesio, do tenu la aplikaĵan aŭtentigon tie, kie ĝi apartenas.

TCP-plusendado en IAP ne estas VPN de tria tavolo. Ĝi portas TCP al elektita celo, ne arbitran IP-trafikon aŭ UDP, kaj ĝi malbone taŭgas, kiam aplikaĵo bezonas privatan DNS trans multaj servoj.

Fora alira VPN por pli vasta atingeblo

Kiam necesas pluraj celoj, protokoloj aŭ privataj DNS-zonoj, la pli bona formo estas eksplicite administrata fora alira VPN sur VM aŭ subtenata aparato. Tiu deplojo estas aparta de la Google-administrata Cloud VPN: vi posedas la registriĝon de la klienta identeco, la programajn ĝisdatigojn, la klientajn vojojn kaj la revenajn vojojn en la VPC.

Planu la tutan liston, ne nur la publikan aŭskultanton. Inkluzivu la tunelan provizaron, la VPC-vojon reen al ĝi, la plusendajn kontrolojn, la DNS-rezoluciadon kaj la alirpolitikon por ĉiu servo. VPN, kiu konektiĝas sed ne povas solvi internajn nomojn, fiaskigas la laborfluon de la programisto same komplete kiel tiu, kiu neniam konektiĝas.

Cloud VPN estas pordego de ejo, ne profilo de tekkomputilo

Google Cloud VPN konektas kunulajn pordegojn per IPsec, kaj ĝiaj oftaj demandoj apartigas tiun rolon ejo-al-ejo de klienta aliro al pordego. Krei tunelon ne produktas profilon, kiun dungito importas sur tekkomputilon. La distingo gravas, kiam iu petas profilon de Cloud VPN. La respondo estas alia produkto.

Kion pordego bone faras, estas doni al la maŝinoj malantaŭ oficeja reto vojon en la VPC-on. Ĝi ne aŭtentigas ĉiun dungiton nek donas aplikaĵajn permesojn, do tiuj politikoj restas ĉe la reta kaj aplikaĵa tavoloj, kie oni povas plenumi ilin laŭ identeco.

Kontrolu kaj registru

Testu unue la plej mallarĝan celon, poste tiun, kiu postulas DNS, kaj poste celon, kiu devas resti malpermesita. Rulu ĉiun teston de la sama kliento, kiu uzos la vojon en produkta medio, ĉar funkcianta testo de administranto-laborstacio pruvas malmulte pri tekkomputilo de programisto kun alia reto.

Registru la elektitan modelon, la celojn, kiujn ĝi kovras, la identecojn, kiujn ĝi aŭtentigas, kaj la fiaskan konduton, kiam la vojo ne disponeblas. Tiu registro estas tio, kio malhelpas la sekvan peton silente larĝigi la tunelon anstataŭ aldoni unu celon al dokumentita dezajno.