Isang Azure VM ang nangangailangan ng tunnel: guest client o VPN gateway?

Isang workload sa isang Azure VM ang kailangang makarating sa isang pribadong network sa pamamagitan ng tunnel. Ang tanong na nagpapasya sa disenyo ay hindi kung aling VPN product ang mas mahusay, kundi kung may ibang makina pang mangangailangan ng landas na iyon. Sagutin iyon muna at ang natitirang arkitektura ay karaniwang pumipili mismo. Kapag nagkamali, mamanahin mo ang isang VM na tahimik na naging router na walang nagdokumento.

Dalawang trabahong magkamukha

Ang VM ay maaaring endpoint o transit point, at ang pagkakaiba ay hindi ang software na ini-install mo kundi kung sino ang gumagamit ng tunnel. Bilang endpoint, ang guest ay nagpapatakbo ng client para sa sarili nitong mga proseso. Bilang transit point, ipinapasa nito ang mga packet ng ibang workload, kaya nagiging bahagi ito ng topology ng iyong network.

Karamihan sa mga kahilingan para sa isang VM ay ang unang trabahong nakasuot ng wika ng pangalawa. May nagsasabing “ang VM ang aming VPN” kapag ang ibig sabihin ay isang application dito ang kailangang makarating sa database sa kabilang panig.

Kundisyon isa: may iba pa bang nangangailangan ng malayong panig?

Kung ang sagot ay hindi, i-install ang client sa guest at itigil ang pagdidisenyo. Wala sa pagpipiliang iyon ang nangangailangan ng managed gateway, at wala rin itong ginagawang gateway ang VM para sa mga kapitbahay nito. Nagdadagdag ka ng ruta sa loob ng isang operating system.

Kung ang sagot ay oo, o malamang oo sa loob ng isang taon, ituring ito bilang disenyo ng network ngayon. Ang ibang VM ay nakakarating sa transit VM lamang kapag ipinadala sila ng talahanayan ng ruta ng subnet doon at tinatanggap ng NIC ang ipinasa na trapiko, kaya ang trabaho ay mga talahanayan ng ruta at mga pahintulot sa forwarding, hindi isa pang pag-install ng client.

Kundisyon dalawa: mapapanatili mo ba ang landas ng administrasyon?

Ang isang VPN client na nag-install ng malawak na ruta ay maaaring makuha ang landas na ginagamit mo upang pamahalaan ang VM. Kung ang listahan ng destinasyon ng tunnel ay nagsasapawan sa network ng pamamahala, bumabagsak ang iyong SSH o RDP session sa sandaling kumonekta ang client, at ang pagwawasto ay kailangang ilapat sa pamamagitan ng serial console o muling pagbuo.

Suriin bago at pagkatapos. Sa Linux, ip route get <management-ip> ay nagpapakita kung aling interface at pinagmulan ang gagamitin ng kernel ngayon; ihambing iyon sa sagot habang nakaupo ang tunnel. Ang split tunnel na may tahasang listahan ng destinasyon ay mas madaling ipagtanggol kaysa default na ruta, at karaniwang iyon ang talagang kailangan ng workload.

Kundisyon tatlo: sino ang nagpa-patch nito sa hatinggabi?

Ang guest client ay ang iyong operating system, ang bersyon ng iyong client at ang iyong mga sertipiko. Iyon ay maayos kapag pinapatakbo mo na ang VM at ang patch cycle nito. Iyon ay masamang palitan kapag ang VM ay umiiral lamang upang hawakan ang tunnel. Bilangin ang mga oras ng patch bago mong tawaging mas mura ang guest client. Ang pag-upgrade ng client na nangangailangan ng restart ay isang pagkaantala na ikaw mismo ang nag-iskedyul para sa isang makinang umiiral upang panatilihing buhay ang tunnel.

Inililipat ng managed gateway ang maintenance na iyon sa platform. Pag-aari mo pa rin ang identity, authorization at ang mga landas ng network sa likod nito, ngunit hindi ka nagre-restart ng makina upang gamitin ang update ng client.

Ano ang hindi ginagawa ng managed gateway

Ang Azure VPN Gateway ay isang serbisyo ng konektibidad ng VNet na may sariling mga kaayusan ng site-to-site at point-to-site. Hindi ito patakarang nagbabawal sa VPN software sa guest, at hindi ito direktang kapalit para sa client na kailangan ng isang application.

Ang ibinibigay nito ay koneksyon sa layer ng network, na naaabot ng maraming workload sa pamamagitan ng routing. Ang hindi nito ibinibigay ay tunnel na ginagamit lamang ng isang proseso sa isang VM, at limitado sa identity ng prosesong iyon. Ang saklaw na iyon ay hindi kakulangan na dapat hingan ng paumanhin; iyon mismo ang punto ng disenyong may guest client. Isang application, isang ruta, isang set ng credential, walang epekto sa ibang VM sa subnet.

Kaya ang paghahambing ay hindi managed laban sa software. Ito ay konektibidad na may saklaw ng network laban sa konektibidad na may saklaw ng proseso, at ang pangalawa ay lehitimo kapag isang proseso lamang ang nangangailangan nito.

Planuhin ang landas ng paglaki bago mo ito kailanganin

Kung ang pangangailangan ay lumaki mula sa isang VM patungo sa isang subnet, muling buuin ang disenyo sa halip na palawakin ang mga pinapayagang prefix ng client. Ang muling paggamit ng maginhawang session bilang hindi dokumentadong router ay nagtatali sa bawat gumagamit sa buhay ng VM na iyon, sa mga credential nito at sa window ng patch nito.

Ang tamang panimulang punto, kapag ang koneksyon ay saklaw ng network at hindi ng workload, ay ang pangkalahatang-tanaw ng Azure VPN Gateway.

Bago ka pumili, magsulat ng tatlong linya: ano ang nangangailangan ng malayong panig, sino ang namamahala ng VM, at sino ang nagpa-patch ng tunnel. Kung ang tatlong sagot ay tumuturo sa isang workload, ang guest client ay ang tapat na disenyo. Kung ang alinman sa mga ito ay tumuturo sa isang subnet, idisenyo ang network layer ngayon.