Kehittäjän etäyhteys Google Cloud VPC:hen: valitse oikea polku

Kehittäjä tarvitsee yhden SSH-istunnon, tietokantaportin tai laajan pääsyn kymmeniin yksityisiin palveluihin, ja jokainen näistä pyynnöistä näyttää samalta kysymykseltä. Se ei ole. Kohteet, protokollat ja mukana olevat identiteetit ratkaisevat, mikä Google Cloudin pääsypolku sopii, ja leveimmän valitseminen oletuksena luo työtä, jota sinun ei olisi tarvinnut omistaa.

Kirjoita kohteet ja protokollat muistiin

Listaa yksityiset osoitteet, portit ja protokollat, joita työ todella tarvitsee, ja merkitse sitten, mitkä identiteetit on todennettava erikseen. Tietokantaportti ja yksityinen DNS-vyöhyke ovat eri vaatimuksia, ja UDP-palvelu sulkee yhden alla olevista vaihtoehdoista kokonaan pois. Kirjallinen luettelo näyttää myös, mitä et myönnä. Se on se osa, jota arvioijat kysyvät.

Tee tämä ennen kuuntelijan avaamista. Luettelosta tulee myöhemmin hyväksymistesti, ja se on ainoa luotettava tapa erottaa kapea tunneli leveästä, joka sattumalta toimii.

IAP muutamalle TCP-palvelulle

Identity-Aware Proxyn TCP-edelleenlähetys antaa todennetun tunnelin kelvollisiin VM-resursseihin paljastamatta palvelua internetiin. Jokapäiväinen muoto on gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, ja yhden portin voi välittää paikallisesti komennolla gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Kolmen asian on oltava linjassa: kutsuja tarvitsee IAP-tunnelin käyttöoikeusroolin, palomuurin on sallittava IAP-lähdeallekirjoitus, ja kohteen on oltava tavoitettavissa instanssissa. Lupa tunnelin luomiseen ei ole tietokannan kirjautumistieto, SSH-kirjautuminen tai RDP-istunto, joten pidä sovelluksen todennus siellä, missä sen kuuluu olla.

IAP:n TCP-edelleenlähetys ei ole kolmannen kerroksen VPN. Se kuljettaa TCP:tä valittuun kohteeseen, ei mielivaltaista IP-liikennettä tai UDP:tä, ja se sopii huonosti, kun sovellus tarvitsee yksityistä DNS:ää monien palvelujen yli.

Etäkäyttö-VPN laajempaan tavoitettavuuteen

Kun tarvitaan useita kohteita, protokollia tai yksityisiä DNS-vyöhykkeitä, parempi muoto on nimenomaisesti hallinnoitu etäkäyttö-VPN VM:ssä tai tuetussa laitteessa. Tämä käyttöönotto on erillinen Googlen hallinnoimasta Cloud VPN:stä: omistat asiakasidentiteetin rekisteröinnin, ohjelmistopäivitykset, asiakasreitit ja VPC:n paluureitit.

Suunnittele koko luettelo, ei vain julkinen kuuntelija. Sisällytä tunnelipooli, VPC-reitti takaisin siihen, edelleenlähetyksen ohjaus, DNS-resoluutio ja palvelukohtainen käyttöoikeuskäytäntö. VPN, joka yhdistää mutta ei pysty ratkaisemaan sisäisiä nimiä, epäonnistuu kehittäjän työnkulussa yhtä täydellisesti kuin se, joka ei koskaan yhdistä.

Cloud VPN on sivuston yhdyskäytävä, ei kannettavan tietokoneen profiili

Google Cloud VPN yhdistää vertaisyhdyskäytäviä IPsecin kautta, ja sen usein kysytyt kysymykset erottavat tämän sivusto-sivusto-roolin asiakas-yhdyskäytävä-pääsystä. Tunnelin luominen ei tuota profiilia, jonka työntekijä tuo kannettavalleen. Ero on tärkeä, kun joku pyytää Cloud VPN -profiilia. Vastaus on eri tuote.

Yhdyskäytävä tekee hyvin yhden asian: se antaa toimistoverkon takana oleville koneille reitin VPC:hen. Se ei todenna jokaista työntekijää eikä myönnä sovellusoikeuksia, joten nämä käytännöt pysyvät verkko- ja sovelluskerroksessa, missä ne voidaan panna täytäntöön identiteettikohtaisesti.

Vahvista ja kirjaa

Testaa ensin kapein kohde, sitten se, joka vaatii DNS:n, ja sitten kohde, jonka on pysyttävä hylättynä. Suorita jokainen testi samasta asiakkaasta, joka käyttää polkua tuotannossa, koska järjestelmänvalvojan työasemalta tehty toimiva testi todistaa vähän kehittäjän kannettavasta, jossa on eri verkko.

Kirjaa valittu malli, sen kattamat kohteet, todentamansa identiteetit ja epäonnistumiskäyttäytyminen, kun polku ei ole käytettävissä. Juuri tämä kirjaus estää seuraavaa pyyntöä laajentamasta tunnelia hiljaa sen sijaan, että dokumentoituun suunnitelmaan lisättäisiin yksi kohde.