Dapat Bang Makita ang Iyong Vaultwarden Vault sa VPN Lang? Tatlong Kundisyon

Ang unang pag-log in sa isang kapalit na telepono ang sandaling ipinapakita ng vault na maaabot lamang sa VPN ang halaga nito: walang cache ang app, nasa likod ng tunnel ang server, at maaaring nasa loob ng vault na hindi mo mabuksan ang kredensyal ng tunnel. Isa itong tanong sa disenyo at hindi pagkawala ng serbisyo, at mas mura itong sagutin bago ang deployment kaysa pagkatapos. Tatlong kundisyon ang nagtatakda kung praktikal ang pribadong vault para sa iyong mga user. Kung mabibigo ang alinman sa mga ito, ang tamang sagot ay karaniwang mas makitid na pagkakalantad at hindi pader ng VPN.

Kundisyon 1: naaabot ng iyong mga user ang server sa unang araw

Walang cache, sesyon at tiwala ang bagong device. Kailangan nitong maresolba ang hostname ng server, ang ruta patungo roon, at isang VPN profile na naka-install na bago subukan ng user na mag-sign in. Kung ang alinman sa tatlong ito ay darating lamang pagkatapos ng unang pag-log in, mabibigo ang deployment sa pinakamasamang sandali. Bilangin kung ilang hakbang ang kailangang tapusin ng bagong empleyado bago niya mabuksan ang kanyang vault.

Mas madalas na mas bagay dito ang split tunnel: dalhin lamang ang endpoint ng vault at ang DNS path na kailangan nito, at hayaang manatili ang natitirang trapiko ng user. Ito ay desisyon sa ruta na ginagawa kasama ng may-ari ng VPN, hindi isang palagay na sinusunod ng bawat mobile client ang parehong patakaran. Dapat na tugma sa pagpipiliang ito ang dalawang pamilya ng address at ang hostname ng serbisyo.

Kung hindi maabot ng mga user ang server bago sila magkaroon ng gumaganang kredensyal, mabibigo ang kundisyong ito at mali ang hugis ng pader ng VPN.

Kundisyon 2: read-only ang naka-cache na access, at sapat na iyon

Maaaring ipakita ng mga Bitwarden client ang isang vault na nakabukas na nang hindi umaabot sa server, at ang offline na kopya ay read-only. Kapaki-pakinabang ito sa pagbasa ng password habang may pagkawala ng serbisyo; hindi ito bagong pag-log in at hindi ito pag-edit. Magpasya kung katanggap-tanggap ang read-only para sa iyong mga user bago magdisenyo sa paligid nito.

curl -sI https://vault.example.com/alive
openssl s_client -connect vault.example.com:443 -servername vault.example.com </dev/null

Magkaibang estado ang pag-lock at pag-log out, at mahalaga ang pagkakaiba dito. Pinapanatili ng naka-lock na client na naka-encrypt ang lokal na vault at maaari niyang buksan itong muli sa master password o biometrics; inaalis ng pag-log out ang lokal na kopyang iyon at kailangan ang server. Kung sasabihin ng support script sa mga user na mag-log out at mag-log in muli para ayusin ang problema sa sync, inaalis din nito ang offline na access nila. Suriin ang aksyon sa timeout sa bawat client sa halip na ipagpalagay ang default.

Ang naka-cache na kopya ay hindi backup. Nabubuhay ito sa isang device, nakatali sa isang account, at nawawala sa pag-log out o pag-wipe.

Kundisyon 3: hindi dumadaan ang pagbawi sa vault mismo

Madaling mabuo ang pabilog na kaso nang aksidente: nakaimbak sa vault ang kredensyal ng VPN, nasa likod ng VPN ang vault, at ang tanging device na may cache ay ang nawala. Nakadepende noon ang pagbawi sa isang dokumento o tao sa labas ng sistema. Isulat ang bootstrap path na iyon at subukan ito gamit ang account na maaaring mabawi bago ito kailanganin ng sinuman. Ang emergency procedure na walang sinumang nagsanay ay pag-asa lamang.

Subukan ang pagkakasunod-sunod nang kontrolado: tiyakin kung aling umiiral na item ang nananatiling nababasa offline, pagkatapos ay ibalik ang network path at tiyakin na gumagana ang bagong pag-log in at ang sync. Iwasang mag-log out mula sa tanging naka-cache na kopya bilang eksperimento, maliban kung may ibang daan pabalik. Itala ang napansin mo, kasama ang bersyon ng client.

Kung kailangan ng pagbawi ang vault, mabibigo ang kundisyong ito. Ang solusyon ay dokumentadong out-of-band na daan, hindi mas malakas na babala sa onboarding document.

Ang pinapanatili mo sa anumang kaso: HTTPS, backup at update

Nananatili ang HTTPS sa lugar nito kahit sa likod ng VPN. Binibigyan nito ang web service ng pagkakakilanlang masusuri ng browser at pinapanatiling protektado ang koneksyon ng app anuman ang dulo ng tunnel. Hindi dapat turuan ng pribadong endpoint ang mga user na lampasan ang mga babala sa certificate, dahil sinusundan sila ng ugaliing iyon sa mga pampublikong site.

Ang backup ay hiwalay na disiplina sa availability. Iniimbak ng Vaultwarden ang data nito sa isang database, at ang pare-parehong kopyang kinuha habang naka-stop ang serbisyo, o backup sa antas ng database, ay mas mahalaga kaysa file na kinopya mula sa tumatakbong proseso. Itago ang kopya sa labas ng host ng vault at subukan ang pag-restore. Kailangan ng na-export na materyal ng vault ang parehong proteksyon tulad ng orihinal, dahil ang export ay hindi naka-encrypt tulad ng imbakan ng server.

sqlite3 /data/db.sqlite3 ".backup '/backup/vault-2026-11-03.sqlite3'"
docker compose ps

Pagkatapos, panatilihing napapanahon ang server at mga client. Binabawasan ng access sa VPN lamang ang pagkakalantad; hindi nito ginagawang walang panganib ang mahinang implementasyon at hindi nito pinoprotektahan ang kompromisadong endpoint. Ang tatlong kundisyon ang nagtatakda ng modelo ng access, at ang maintenance ang nagtatakda kung lalampasan ng modelong iyon ang taon.