Oddaljeni dostop razvijalca do Google Cloud VPC: izberite pot

Razvijalec potrebuje eno sejo SSH, vrata podatkovne baze ali širok dostop do ducata zasebnih storitev, in vsaka od teh zahtev izgleda kot isto vprašanje. Ni. Cilji, protokoli in vključene identitete odločajo, katera pot dostopa v Google Cloud ustreza, in izbira najširše privzeto ustvari delo, ki ga niste morali imeti.

Zapišite cilje in protokole

Naštejte zasebne naslove, vrata in protokole, ki jih delo resnično potrebuje, nato označite, katere identitete je treba preveriti ločeno. Vrata podatkovne baze in zasebna cona DNS sta različni zahtevi, storitev UDP pa eno od spodnjih možnosti popolnoma izključi. Pisni seznam pokaže tudi, česa ne dodeljujete. To je del, po katerem sprašujejo recenzenti.

To storite pred odpiranjem poslušalca. Seznam pozneje postane sprejemni test in je edini zanesljiv način, da ločite ozek tunel od širokega, ki deluje po naključju.

IAP za nekaj storitev TCP

Posredovanje TCP v Identity-Aware Proxy daje preverjen tunel do primernih virov VM, ne da bi storitev izpostavilo internetu. Vsakodnevna oblika je gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, ena vrata pa je mogoče posredovati lokalno s gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tri stvari se morajo ujemati: klicatelj potrebuje vlogo dostopa do tunela IAP, požarni zid mora prepustiti obseg vira IAP, cilj pa mora biti dosegljiv na instanci. Dovoljenje za ustvarjanje tunela ni poverilnica podatkovne baze, prijava SSH ali seja RDP, zato pustite preverjanje aplikacije tam, kamor sodi.

Posredovanje TCP v IAP ni VPN tretje plasti. Prenese TCP do izbranega cilja, ne poljubnega prometa IP ali UDP, in slabo ustreza, ko aplikacija potrebuje zasebni DNS čez veliko storitev.

VPN za oddaljeni dostop za širšo dosegljivost

Ko je potrebnih več ciljev, protokolov ali zasebnih con DNS, je boljša oblika izrecno upravljani VPN za oddaljeni dostop na VM ali podprti napravi. Ta namestitev je ločena od Cloud VPN, ki ga upravlja Google: imate registracijo identitete odjemalca, posodobitve programske opreme, odjemalske poti in povratne poti v VPC.

Načrtujte celoten seznam, ne le javnega poslušalca. Vključite sklop tunelov, pot VPC nazaj do njega, nadzor posredovanja, razreševanje DNS in politiko dostopa za vsako storitev. VPN, ki se poveže, a ne more razrešiti notranjih imen, spodleti v razvijalčevem delovnem toku prav tako popolnoma kot tisti, ki se nikoli ne poveže.

Cloud VPN je prehod mesta, ne profil prenosnika

Google Cloud VPN povezuje partnerske prehode prek IPsec, in njegova pogosta vprašanja ločujejo to vlogo mesto-na-mesto od dostopa odjemalec-na-prehod. Ustvarjanje tunela ne ustvari profila, ki bi ga zaposleni uvozil v prenosnik. Razlika je pomembna, ko nekdo zahteva profil Cloud VPN. Odgovor je drug izdelek.

Prehod dobro opravi eno: strojem za pisarniškim omrežjem da pot v VPC. Ne preverja vsakega zaposlenega in ne dodeljuje dovoljenj aplikacijam, zato te politike ostanejo na omrežni in aplikacijski plasti, kjer jih je mogoče uveljaviti po identiteti.

Preverite in zabeležite

Najprej preizkusite najožji cilj, nato tistega, ki zahteva DNS, in nazadnje cilj, ki mora ostati zavrnjen. Vsak preizkus izvedite z istega odjemalca, ki bo pot uporabljal v produkciji, ker uspešen preizkus z administratorske delovne postaje malo dokaže o razvijalčevem prenosniku z drugim omrežjem.

Zabeležite izbrani model, cilje, ki jih pokriva, identitete, ki jih preverja, in vedenje ob napaki, ko pot ni na voljo. Prav ta zapis prepreči, da bi naslednja zahteva tiho razširila tunel, namesto da bi dokumentiranemu načrtu dodala en cilj.