¿Debería su bóveda de Vaultwarden ser solo por VPN? Tres condiciones

El primer inicio de sesión en un teléfono de sustitución es donde una bóveda solo por VPN muestra su coste: la aplicación no tiene caché, el servidor está detrás de un túnel y la credencial del túnel puede estar dentro de la bóveda que no puede abrir. Es una cuestión de diseño y no una caída, y sale más barato responderla antes del despliegue que después. Tres condiciones deciden si una bóveda privada es práctica para sus usuarios. Si alguna falla, la respuesta correcta suele ser una exposición más estrecha y no un muro de VPN.

Condición 1: sus usuarios llegan al servidor el primer día

Un dispositivo nuevo no tiene caché, ni sesión, ni confianza. Necesita que se resuelva el nombre de host del servidor, la ruta para llegar a él y un perfil de VPN ya instalado antes de que el usuario intente iniciar sesión. Si cualquiera de esos tres llega solo después del primer inicio de sesión, el despliegue falla en el peor momento posible. Cuente cuántos pasos debe completar una persona nueva antes de poder abrir su bóveda.

Un túnel dividido suele encajar mejor aquí: transporte solo el extremo de la bóveda y la ruta de DNS que necesita, y deje tranquilo el resto del tráfico del usuario. Es una decisión de enrutamiento que se toma con el propietario de la VPN, no una suposición de que cada cliente móvil respeta la misma política. Ambas familias de direcciones y el nombre de host del servicio deben ser coherentes con esa elección.

Si los usuarios no pueden llegar al servidor antes de tener credenciales que funcionen, esta condición falla y el muro de VPN tiene la forma equivocada.

Condición 2: el acceso en caché es de solo lectura, y eso basta

Los clientes de Bitwarden pueden mostrar una bóveda ya desbloqueada sin llegar al servidor, y esa copia sin conexión es de solo lectura. Sirve para leer una contraseña durante una caída; no es un inicio de sesión nuevo ni es edición. Decida si la solo lectura es aceptable para sus usuarios antes de diseñar en torno a ella.

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

Bloquear y cerrar sesión son estados distintos, y la diferencia importa aquí. Un cliente bloqueado mantiene la bóveda local cifrada y puede desbloquearla de nuevo con la contraseña maestra o la biometría; cerrar sesión elimina esa copia local y exige el servidor. Si un script de soporte dice a los usuarios que cierren sesión y vuelvan a entrar para arreglar un problema de sincronización, también elimina su acceso sin conexión. Revise la acción de tiempo de espera en cada cliente en lugar de suponer el valor predeterminado.

Una copia en caché no es una copia de seguridad. Vive en un solo dispositivo, está atada a una sola cuenta y desaparece con un cierre de sesión o un borrado.

Condición 3: la recuperación no pasa por la propia bóveda

El caso circular es fácil de construir por accidente: la credencial de la VPN se guarda en la bóveda, la bóveda está detrás de la VPN y el único dispositivo con caché es el que se perdió. Entonces la recuperación depende de un documento o de una persona fuera del sistema. Escriba esa ruta de arranque y pruébela con una cuenta recuperable antes de que alguien la necesite. Un procedimiento de emergencia que nadie ha practicado es solo una esperanza.

Pruebe la secuencia de forma controlada: confirme qué elementos existentes siguen siendo legibles sin conexión, después restaure la ruta de red y verifique que un inicio de sesión nuevo y una sincronización funcionan. Evite cerrar sesión en la única copia en caché como experimento, salvo que exista otra ruta de vuelta. Anote lo que observó, incluida la versión del cliente.

Si la recuperación requiere la bóveda, esta condición falla. La solución es una ruta fuera de banda documentada, no un aviso más fuerte en el documento de incorporación.

Lo que conserva en cualquier caso: HTTPS, copias de seguridad y actualizaciones

HTTPS sigue en su sitio incluso detrás de la VPN. Da al servicio web una identidad que el navegador puede comprobar y mantiene la conexión de la aplicación protegida con independencia de dónde termine el túnel. Un extremo privado no debería enseñar a los usuarios a saltarse los avisos de certificado, porque ese hábito les sigue a los sitios públicos.

Las copias de seguridad son una disciplina distinta de la disponibilidad. Vaultwarden guarda sus datos en una base de datos, y una copia coherente tomada con el servicio detenido, o una copia a nivel de base de datos, vale más que un archivo copiado de un proceso en marcha. Mantenga la copia fuera del host de la bóveda y pruebe una restauración. El material exportado de la bóveda necesita la misma protección que el original, porque una exportación no está cifrada como el almacenamiento del servidor.

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

Después mantenga actualizados el servidor y los clientes. El acceso solo por VPN reduce la exposición; no hace inofensiva una implementación vulnerable ni protege un extremo comprometido. Las tres condiciones deciden el modelo de acceso, y el mantenimiento decide si ese modelo sobrevive el año.