Nakadepende pa rin ang cloud VPN mo sa hosting provider

Nag-install ka ng operating system, pinatibay ang serbisyo at hawak mo ang mga susi, at nagsisimula nang maramdaman na sa iyo ang server. Sa iyo ito tulad ng isang inuupahang flat na sa iyo: ang kandado ng pinto ay nasa kontrol mo at ang gusali ay hindi. Ang hypervisor, ang network sa harap ng instance at ang account na kayang magtayo muli ng lahat ay pag-aari ng iba. Ang pagkakaibang iyon ang nagtatakda kung ano ang dapat saklawin ng plano sa pagbawi, at ito ang bahaging pinakamaliit na binabago ng self-hosting.

Ang account ang tunay na control plane

Pinamamahalaan ng hosting account ang virtual machine, mga disk, snapshot, pampublikong address at mga panuntunan sa network. Lahat ng ito ay mababago nang hindi umaasa sa guest, na naglalagay sa account sa labas ng threat model na inilalarawan ng karamihan sa mga gabay sa VPN. Ang perpektong configuration ng tunnel ay nakakaligtas sa isang aksyon sa account na nagpapalit ng disk.

Protektahan ang account na iyon bilang hiwalay na asset: mga independiyenteng kredensyal, pangalawang factor na sinusuportahan ng hardware at audit trail na talagang binabasa ng isang tao. Ang pagbabahagi nito sa parehong entry ng password manager sa serbisyo ng VPN ang pagkakamaling nagpapawalang-bisa sa lahat ng iba pang kontrol.

Basahin ang paghahati ng tungkulin ng provider para sa partikular na produkto, hindi para sa cloud sa pangkalahatan. Ang modelo ng shared responsibility ay kapaki-pakinabang na halimbawa kung paano hinahati ang mga layer, at ang ibang provider ay naglalarawan ng sarili nilang hangganan sa halip na manahin ito. Ang hinahanap mo ay kung aling mga pagkabigo ang inaasahang aayusin mo at alin ang maaari mo lamang iulat.

Mga kaganapan sa imprastruktura na hindi mo maaaring pangasiwaan

Ang live migration, maintenance ng host, pagkasira ng hardware sa pisikal na node at kaganapan sa kapasidad ay lahat ng bagay na pinangangasiwaan ng provider ayon sa sarili nitong iskedyul. Maaari kang makakita ng restart, maikling pagkawala ng packet o pagbabago ng address, at hindi mo makikita ang dahilan. Ang disenyong itinuturing na fixed point ang instance ay bibigyang-kahulugan ang bawat isa sa mga ito bilang sira ng VPN. Ang tamang aksyon ay gawing matiisin ang serbisyo sa isang instance na nawawala, sa halip na siyasatin ang dahilan na hindi mo kailanman makikita.

Ang mga backup ay kabilang sa layer na ito, hindi sa tunnel. Itago ang configuration ng server, mga identidad, plano ng address at mga pinapayagang ruta sa lugar na hindi nakadepende sa pagiging maabot ng instance, at tiyakin na maibabalik ang kopya nang walang orihinal na disk.

Ang pag-uugali ng address ay karapat-dapat sa sariling tseke. Kung ang pampublikong address ay nakakaligtas sa paghinto, pagpapalit o pagbura ay nakadepende sa kung paano ito inilaan, at ang tatlong operasyong ito ay hindi mapagpapalit. Isulat kung alin ang pinagkakatiwalaan mo bago gawing apurahan ng isang insidente ang tanong.

Suriin kung ano ang nakakaligtas sa muling pagtatayo

Buuin ang landas ng pagbawi habang gumagana ang lahat. Tukuyin ang console o out-of-band access na iniaalok ng provider, tiyakin na maabot mo ito nang walang tunnel, at itago ang mga kredensyal sa lugar na hindi madadala ng sirang laptop o nawawalang telepono. Kung hinaharangan ng pagbabago sa lokal na firewall ang tunnel, ang console na iyon ang tanging daan pabalik.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

Sinasagot ng metadata service ang mga tanong tungkol sa instance na hindi nakikita ng guest sa ibang paraan, at ang eksaktong mga landas nito ay naiiba sa pagitan ng mga provider at platform, kaya i-verify ang mga ito sa dokumentasyon ng produktong pinapatakbo mo. Pagkatapos ay magsagawa ng isang kontroladong muling pagtatayo ng test instance at sukatin ang oras. Ang pamamaraang pagbawi na walang nakagawa ay isang palagay lamang.

Pansinin kung ano ang ginawa ng muling pagtatayo sa address, mga host key, identidad ng disk at anumang ipinupunto ng mga kliyente. Ang mga kliyenteng nag-cache ng host key ay magrereklamo pagkatapos ng muling pagtatayo, at ang reklamong iyon ay tamang pag-uugali at hindi bug na dapat patahimikin.

Magpasya kung ano talaga ang binabago ng self-hosting

Ang pagpapatakbo ng sarili mong VPN ay naglilipat ng tiwala mula sa isang operator ng VPN patungo sa hosting provider at sa iyo. Tunay na pagbabago iyon, at hindi ito katulad ng pag-alis ng third party. Kung ang layunin ay pigilan ang isang komersyal na VPN na maobserbahan ang trapiko, maaari pa ring obserbahan ng provider ang network ng instance, ang disk at ang mga talaan ng pagsingil.

Inilalarawan ng sarili mong mga log ang iyong software, at hindi nila inilalarawan ang bawat talaan ng imprastrukturang itinatago ng provider. Totoo rin ang kabaligtaran: hindi pinatutunayan ng visibility ng imprastruktura kung ano ang itinatago ng provider. Ang parehong tanong ay nangangailangan ng patakaran ng provider at ng iyong configuration, at walang isa ang sumasagot sa isa.

Isulat ang sagot bilang paghahati ng trabaho: aling layer ang nabigo, sino ang makakapag-ayos at gaano katagal ang pag-aayos na iyon. Binabago ng self-hosting kung sino ang pinagkakatiwalaan mo, at ang kapaki-pakinabang na bahagi ng pagsasanay ay ang malaman nang eksakto kung aling layer ang pinagkakatiwalaan mo sa kanila.