Después del script de configuración, alguien debe ser dueño del servidor VPN
El script puede construir el servidor, pero no puede asumir la política de acceso, la ruta de actualización ni la reversión. Defina el traspaso antes de ejecutarlo.
Se venden dos trabajos distintos como uno: convertir una máquina en un servidor VPN y añadir un cliente VPN a un portátil que debe unirse a la puerta de enlace de otra persona. El script de configuración responde al primero y no puede responder al segundo, diga lo que diga su README. Tome el proyecto setup-ipsec-vpn como ejemplo concreto: construye un servidor IPsec/L2TP, Cisco IPsec o IKEv2 en un host Linux compatible con Libreswan y xl2tpd. Eso es un contrato de despliegue para un servidor, no una receta general para cualquier máquina. Decida qué trabajo tiene antes de que se ejecute el script, porque todo lo posterior trata del servidor.
Sea honesto sobre el host
Una máquina que también termina otra cosa, o cuyo cortafuegos se gestiona desde un plano de control en la nube en lugar del sistema operativo, es una instalación distinta de una máquina virtual limpia. Anote el protocolo que habilita y la versión que utiliza, y luego compruebe ambos contra la lista de compatibilidad del proyecto, no contra una entrada de blog del año pasado.
Habilitar el servicio no abre el camino hacia él. Para IPsec, la red frente al host debe admitir UDP 500 y 4500 y, según el despliegue, el propio protocolo ESP. Un script que termina con éxito detrás de un grupo de seguridad que descarta el protocolo 50 ha producido un servidor al que nadie puede llegar, y nada en la salida del instalador lo dirá.
Qué asume realmente el instalador
Espere un archivo de configuración y secretos de IPsec, una configuración del demonio L2TP, opciones PPP y unidades systemd que ahora poseen esos puertos. El README del proyecto indica que los archivos de configuración existentes se respaldan antes de los cambios, lo cual es útil y no es lo mismo que una copia de seguridad del host. Decida qué componentes se actualizarán con los paquetes de la distribución y cuáles volviendo a ejecutar o reescribiendo el script, porque son dos vías de mantenimiento con modos de fallo distintos.
Fije la revisión que aprobó. Una URL de descarga que sirve la rama predeterminada actual puede devolver contenido distinto el mes que viene, así que anote el commit o la versión que ejecutó y guarde una copia. Ese solo hábito convierte un estado no atribuible en algo sobre lo que una segunda persona puede razonar a las dos de la madrugada.
Lo que el script no puede darle
La automatización produce una instalación funcional y se detiene ahí. No decide qué recursos privados debe alcanzar el túnel, que es una cuestión de política de acceso sobre la que el cortafuegos del host y la red superior tienen opinión. No decide quién recibe credenciales, cómo se entregan ni cómo se retira el acceso de una persona cuando se va. Y no decide cómo se recupera la máquina tras una actualización defectuosa, que es la parte que suele descubrirse en el peor momento posible.
Los perfiles de cliente y los secretos mostrados son material de acceso, no registros de instalación. Un perfil generado pegado en un canal compartido es una cuenta, y el mismo estándar se aplica a las capturas de pantalla del resumen de configuración. Mantenga un inventario protegido del estado de identidad necesario para restaurar el servicio y anote cuáles de esas credenciales se han revocado desde entonces.
El primer cliente es la prueba de aceptación
Acepte el despliegue desde un cliente autorizado, con el protocolo que realmente habilitó. Compruebe que el nombre privado se resuelve, que la ruta de vuelta funciona, que una reconexión se comporta bien y que se rechaza un destino fuera del conjunto permitido. Un inicio de sesión correcto desde otra aplicación cliente no es prueba de la que entregó.
Si la combinación que desea ya no es compatible, elija una vía mantenida antes de la instalación. Revivir una versión antigua, debilitar la autenticación o volver a ejecutar un script sin explicación son aplazamientos, no planes de mantenimiento, y cada uno dificulta el traspaso.
Escriba la página de traspaso
Manténgala corta: el servidor, la revisión que lo construyó, los puertos que necesita, los componentes y sus responsables de actualización, los recursos permitidos, la ruta de las credenciales y el procedimiento de recuperación. Añada la ruta de consola o fuera de banda que usará cuando un cambio en el túnel sea lo que rompió el acceso. Entonces la siguiente persona hereda un servicio en lugar de un comando que teme ejecutar dos veces.
Revise esa página cuando cambie el host, y no solo cuando algo se rompa. Un documento de traspaso que nunca se lee es un documento que dejó de ser cierto en silencio.