Nuotolinė kūrėjo prieiga prie Google Cloud VPC: pasirinkite kelią

Kūrėjui reikia vienos SSH sesijos, duomenų bazės prievado arba plačios prieigos prie dešimties privačių paslaugų, ir kiekvienas iš šių prašymų atrodo kaip tas pats klausimas. Tai netiesa. Paskirties vietos, protokolai ir susijusios tapatybės nulemia, kuris Google Cloud prieigos kelias tinka, o plačiausio pasirinkimas pagal nutylėjimą sukuria darbą, kurio jums nereikėjo prisiimti.

Užsirašykite paskirties vietas ir protokolus

Išvardykite privačius adresus, prievadus ir protokolus, kurių darbui tikrai reikia, tada pažymėkite, kurias tapatybes reikia tikrinti atskirai. Duomenų bazės prievadas ir privati DNS zona yra skirtingi reikalavimai, o UDP paslauga visiškai atmeta vieną iš toliau pateiktų variantų. Rašytinis sąrašas taip pat parodo, ko nesuteikiate. Būtent apie šią dalį klausia recenzentai.

Padarykite tai prieš atidarydami klausytoją. Sąrašas vėliau tampa priėmimo testu, ir tai vienintelis patikimas būdas atskirti siaurą tunelį nuo plataus, kuris veikia atsitiktinai.

IAP kelioms TCP paslaugoms

TCP persiuntimas Identity-Aware Proxy suteikia autentifikuotą tunelį į tinkamus VM išteklius neatskleidžiant paslaugos internetui. Kasdienė forma yra gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, o vieną prievadą galima persiųsti vietiškai naudojant gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Trys dalykai turi sutapti: kviečiančiajam reikia IAP tunelio prieigos vaidmens, ugniasienė turi leisti IAP šaltinio diapazoną, o paskirties vieta turi būti pasiekiama egzemplioriuje. Leidimas sukurti tunelį nėra duomenų bazės prisijungimo duomenys, SSH prisijungimas ar RDP sesija, todėl palikite programos autentifikavimą ten, kur jam vieta.

IAP TCP persiuntimas nėra trečiojo sluoksnio VPN. Jis perduoda TCP į pasirinktą paskirties vietą, o ne savavališką IP srautą ar UDP, ir blogai tinka, kai programai reikia privataus DNS per daugelį paslaugų.

Nuotolinės prieigos VPN platesniam pasiekiamumui

Kai reikia kelių paskirties vietų, protokolų ar privačių DNS zonų, geresnė forma yra aiškiai valdomas nuotolinės prieigos VPN VM arba palaikomame įrenginyje. Šis diegimas atskiras nuo Google valdomo Cloud VPN: jūs valdote kliento tapatybės registraciją, programinės įrangos naujinimus, kliento maršrutus ir VPC grąžinimo maršrutus.

Planuokite visą sąrašą, o ne tik viešą klausytoją. Įtraukite tunelių telkinį, VPC maršrutą atgal į jį, persiuntimo valdymą, DNS sprendimą ir kiekvienos paslaugos prieigos politiką. VPN, kuris prisijungia, bet negali išspręsti vidinių pavadinimų, nepavyksta kūrėjo darbo eigoje taip pat visiškai, kaip ir tas, kuris niekada neprisijungia.

Cloud VPN yra svetainės vartai, o ne nešiojamojo kompiuterio profilis

Google Cloud VPN jungia partnerių vartus per IPsec, o jo dažnai užduodami klausimai atskiria tą svetainės-svetainės vaidmenį nuo kliento-vartų prieigos. Sukūrus tunelį nesukuriamas profilis, kurį darbuotojas importuotų nešiojamajame kompiuteryje. Skirtumas svarbus, kai kas nors prašo Cloud VPN profilio. Atsakymas yra kitas produktas.

Tai, ką vartai daro gerai, yra suteikti biuro tinklo užpakalyje esantiems kompiuteriams maršrutą į VPC. Jie neautentifikuoja kiekvieno darbuotojo ir nesuteikia programos leidimų, todėl šios politikos lieka tinklo ir programos sluoksniuose, kur juos galima vykdyti pagal tapatybę.

Patikrinkite ir užrašykite

Pirmiausia išbandykite siauriausią paskirties vietą, tada tą, kuriai reikia DNS, o paskui paskirties vietą, kuri turi likti atmesta. Kiekvieną testą paleiskite iš to paties kliento, kuris naudos kelią produkcijoje, nes sėkmingas testas iš administratoriaus darbo vietos mažai įrodo apie kūrėjo nešiojamąjį kompiuterį su kitu tinklu.

Užrašykite pasirinktą modelį, jo apimamas paskirties vietas, tikrinamas tapatybes ir gedimo elgseną, kai kelias nepasiekiamas. Šis įrašas yra tai, kas neleidžia kitam prašymui tyliai išplėsti tunelio, o ne pridėti vieną paskirties vietą prie dokumentuoto dizaino.