Malayuang pag-access ng developer sa isang Google Cloud VPC: piliin ang landas

Ang isang developer ay nangangailangan ng isang sesyon ng SSH, isang port ng database o malawak na pag-access sa isang dosenang pribadong serbisyo, at bawat isa sa mga kahilingang iyon ay mukhang parehong tanong. Hindi. Ang mga destinasyon, protocol at pagkakakilanlang kasangkot ang nagpapasya kung aling landas ng pag-access sa Google Cloud ang angkop, at ang pagpili ng pinakamalawak bilang default ay lumilikha ng trabahong hindi mo kailangang pagmay-arian.

Isulat ang mga destinasyon at protocol

Ilista ang mga pribadong address, port at protocol na talagang kailangan ng trabaho, pagkatapos ay markahan kung aling mga pagkakakilanlan ang dapat i-verify nang hiwalay. Ang isang port ng database at isang pribadong DNS zone ay magkaibang pangangailangan, at ang isang serbisyong UDP ay ganap na nag-aalis ng isa sa mga pagpipilian sa ibaba. Ang nakasulat na listahan ay nagpapakita rin ng hindi mo ibinibigay. Iyon ang bahaging itinatatanong ng mga tagasuri.

Gawin ito bago magbukas ng tagapakinig. Ang listahan ay magiging pagsubok sa pagtanggap mamaya, at ito ang tanging maaasahang paraan upang makilala ang makitid na lagusan mula sa malawak na nagkataong gumagana.

IAP para sa ilang serbisyong TCP

Ang pagpapasa ng TCP sa Identity-Aware Proxy ay nagbibigay ng na-verify na lagusan patungo sa mga karapat-dapat na VM resource nang hindi inilalantad ang serbisyo sa internet. Ang pang-araw-araw na anyo ay gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, at ang isang port ay maaaring ipasa nang lokal gamit ang gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tatlong bagay ang dapat magtugma: ang tumatawag ay nangangailangan ng role sa pag-access ng IAP tunnel, ang firewall ay dapat tumanggap ng IAP source range, at ang destinasyon ay dapat maabot sa instance. Ang pahintulot na gumawa ng lagusan ay hindi kredensyal ng database, login ng SSH o sesyon ng RDP, kaya panatilihin ang pagpapatotoo ng aplikasyon sa nararapat na lugar.

Ang pagpapasa ng TCP sa IAP ay hindi VPN sa ikatlong antas. Dinadala nito ang TCP sa piniling destinasyon, hindi arbitraryong trapik ng IP o UDP, at hindi ito angkop kapag ang isang aplikasyon ay nangangailangan ng pribadong DNS sa maraming serbisyo.

Isang VPN para sa malayuang pag-access para sa mas malawak na maabot

Kapag kailangan ang maraming destinasyon, protocol o pribadong DNS zone, ang mas mabuting anyo ay isang tahasang pinamamahalaang VPN para sa malayuang pag-access sa isang VM o sinusuportahang kagamitan. Ang deployment na iyon ay hiwalay sa Cloud VPN na pinamamahalaan ng Google: pagmamay-ari mo ang pagpapatala ng pagkakakilanlan ng kliyente, ang mga update ng software, ang mga ruta ng kliyente at ang mga rutang pabalik sa VPC.

Planuhin ang buong listahan, hindi lamang ang pampublikong tagapakinig. Isama ang pool ng lagusan, ang rutang pabalik ng VPC, mga kontrol sa pagpapasa, resolusyon ng DNS at patakaran sa pag-access bawat serbisyo. Ang VPN na kumokonekta ngunit hindi malutas ang mga panloob na pangalan ay binibigo ang workflow ng developer nang kasingbuo ng isa na hindi kailanman kumokonekta.

Ang Cloud VPN ay isang gateway ng site, hindi profile ng laptop

Ang Google Cloud VPN ay nagkokonekta ng mga peer gateway sa pamamagitan ng IPsec, at ang mga madalas itanong nito ay naghihiwalay sa papel na site-sa-site mula sa pag-access na kliyente-sa-gateway. Ang paggawa ng lagusan ay hindi gumagawa ng profile na inaangkat ng empleyado sa isang laptop. Mahalaga ang pagkakaiba kapag may humiling ng profile ng Cloud VPN. Ang sagot ay ibang produkto.

Ang mahusay na ginagawa ng isang gateway ay bigyan ang mga makina sa likod ng network ng opisina ng ruta papasok sa VPC. Hindi nito pinapatunayan ang bawat empleyado o nagbibigay ng mga pahintulot ng aplikasyon, kaya ang mga patakarang iyon ay nananatili sa antas ng network at aplikasyon kung saan maipapatupad ang mga ito ayon sa pagkakakilanlan.

I-verify at itala

Subukan muna ang pinakamakitid na destinasyon, pagkatapos ang nangangailangan ng DNS, at pagkatapos isang destinasyong dapat manatiling tinatanggihan. Patakbuhin ang bawat pagsubok mula sa parehong kliyente na gagamit ng landas sa produksiyon, dahil ang gumaganang pagsubok mula sa workstation ng administrador ay nagpapatunay ng kaunti tungkol sa laptop ng developer na may ibang network.

Itala ang piniling modelo, ang mga destinasyong saklaw nito, ang mga pagkakakilanlang pinapatunayan nito at ang pag-uugali kapag may kabiguan kapag hindi available ang landas. Ang talaang iyon ang pumipigil sa susunod na kahilingan na tahimik na palawakin ang lagusan sa halip na magdagdag ng isang destinasyon sa isang dokumentadong disenyo.