Udaljeni pristup programera Google Cloud VPC mreži: odaberite pravi put

Programeru treba jedna SSH sesija, port baze podataka ili širok pristup desetak privatnih servisa, i svaki od tih zahtjeva izgleda kao isto pitanje. Nije. Odredišta, protokoli i uključeni identiteti odlučuju koji put pristupa Google Cloudu odgovara, a odabir najšireg po zadanom stvara posao koji niste trebali preuzeti.

Zapišite odredišta i protokole

Popišite privatne adrese, portove i protokole koji su poslu zaista potrebni, zatim označite koji se identiteti moraju provjeravati zasebno. Port baze podataka i privatna DNS zona su različiti zahtjevi, a UDP servis u potpunosti isključuje jednu od opcija u nastavku. Pisani popis pokazuje i što ne odobravate. To je dio koji recenzenti pitaju.

Učinite to prije otvaranja osluškivača. Popis kasnije postaje prihvatni test i jedini je pouzdan način da razlikujete uzak tunel od širokog koji slučajno radi.

IAP za nekoliko TCP servisa

Identity-Aware Proxy TCP prosljeđivanje daje provjereni tunel do prikladnih VM resursa bez izlaganja servisa internetu. Svakodnevni oblik je gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, a jedan port se može lokalno proslijediti pomoću gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tri stvari moraju biti usklađene: pozivatelju treba uloga pristupa IAP tunelu, vatrozid mora propuštati IAP raspon izvora, a odredište mora biti dostupno na instanci. Ovlaštenje za stvaranje tunela nije vjerodajnica baze podataka, SSH prijava ni RDP sesija, zato provjeru aplikacije zadržite gdje joj je mjesto.

IAP TCP prosljeđivanje nije VPN trećeg sloja. Prenosi TCP do odabranog odredišta, a ne proizvoljan IP promet ili UDP, i loše odgovara kad aplikaciji treba privatni DNS kroz mnogo servisa.

VPN za udaljeni pristup radi šire dostupnosti

Kad su potrebna brojna odredišta, protokoli ili privatne DNS zone, bolji je oblik izričito upravljani VPN za udaljeni pristup na VM-u ili podržanom uređaju. To je postavljanje odvojeno od Google upravljanog Cloud VPN-a: vi posjedujete upis identiteta klijenta, ažuriranja softvera, klijentske rute i povratne rute u VPC.

Planirajte cijeli popis, ne samo javni osluškivač. Uključite bazen tunela, VPC rutu natrag prema njemu, kontrole prosljeđivanja, razrješavanje DNS-a i pravila pristupa po servisu. VPN koji se povezuje ali ne može razriješiti interne nazive podbacuje u programerskom toku jednako potpuno kao i onaj koji se nikad ne povezuje.

Cloud VPN je prolaz za lokaciju, a ne profil za prijenosnik

Google Cloud VPN povezuje partnerske prolaze preko IPsec-a, a njegov FAQ odvaja tu ulogu lokacija-lokacija od pristupa klijent-prolaz. Stvaranje tunela ne stvara profil koji zaposlenik uvozi na prijenosnik. Razlika je važna kad netko zatraži Cloud VPN profil. Odgovor je drugi proizvod.

Prolaz dobro radi jedno: daje strojevima iza uredske mreže rutu u VPC. Ne provjerava svakog zaposlenika ni ne daje dozvole aplikacijama, pa ta pravila ostaju na mrežnom i aplikacijskom sloju gdje se mogu provoditi po identitetu.

Provjerite i zapišite

Prvo testirajte najuže odredište, zatim ono kojem treba DNS, pa odredište koje mora ostati odbijeno. Pokrenite svaki test s istog klijenta koji će put koristiti u produkciji, jer uspješan test s administratorske radne stanice malo dokazuje o prijenosniku programera s drugom mrežom.

Zapišite odabrani model, odredišta koja pokriva, identitete koje provjerava i ponašanje pri kvaru kad put nije dostupan. Taj zapis sprječava da sljedeći zahtjev tiho proširi tunel umjesto da doda jedno odredište dokumentiranom dizajnu.