Una cuenta VPN en dos servidores: tres libros de estado

Una cuenta que puede iniciar sesión en cualquiera de dos nodos VPN plantea una pregunta de diseño mucho antes de plantear una pregunta de software. La vista de la cuenta, la red que posee cada nodo y la sesión que mantiene un cliente conectado son tres tipos distintos de estado, y fallan de maneras distintas cuando se copian de un lado a otro. Copiar los tres en un solo sistema es una forma habitual de perder uno de ellos.

Recorra los tres libros siguientes en orden. Cada uno pregunta qué es autoritativo, qué es local y qué ocurre cuando el otro nodo no está, y las respuestas no se deducen unas de otras.

Quién puede conectarse: una autoridad, muchos nodos

Empiece por el libro de admisión: qué origen de identidad es autoritativo, qué emisores de certificados son de confianza, qué cuentas son elegibles, qué segundo factor se aplica y a qué puede llegar cada cuenta. Después anote cómo se entera cada nodo de los cambios y con qué rapidez.

Una base de datos compartida es un componente posible de esa respuesta. No es prueba de que toda política relevante viva allí ni de que cada nodo aplique un cambio en el mismo instante. Una cuenta desactivada en el nodo A pero todavía aceptada en el nodo B significa que el proceso de baja no ha terminado.

Decida qué hace un nodo cuando la autoridad no es accesible. Aceptar credenciales en caché durante una caída es una decisión de política con un coste de seguridad, y rechazarlas es una decisión de política con un coste de disponibilidad. Ambas son defendibles; dejarlo sin documentar no lo es.

Mantenga la autoridad del emisor separada de los datos de la cuenta. Varias pasarelas pueden confiar en la misma CA sin tener su clave de firma, y cada nodo sigue necesitando su propio certificado de servidor y su propia relación de confianza en el lado del cliente.

Qué posee un nodo: direcciones y rutas

El segundo libro es local de cada nodo: dirección de escucha, identidad del servidor, grupo de direcciones, rutas hacia recursos privados, política del resolutor y cómo sale el tráfico hacia internet. La misma cuenta puede ser atendida por cualquiera de los dos nodos mientras estos objetos siguen siendo distintos.

El camino de vuelta es la parte que se olvida. Si ambos nodos reparten direcciones del mismo grupo, la red privada no puede saber a qué nodo pertenece un cliente dado y la respuesta puede enviarse al lugar equivocado. Los grupos distintos también necesitan rutas y permisos, así que un rango de números distinto no es un diseño completo.

Dirija a los clientes a un nodo deliberadamente. La selección de DNS, las listas de puntos finales del cliente y un servicio de frontal son mecanismos distintos con comportamientos distintos de salud y de conmutación por fallo. Elegir uno está bien; tratar el «equilibrio de carga» como el diseño deja el camino de vuelta y el comportamiento ante fallos sin definir.

Un ejemplo de producto documentado ayuda aquí. La documentación de replicación de Pritunl trata la red VPN como un objeto por réplica, y los clientes de réplicas distintas necesitan rutas y conectividad adicionales para alcanzarse. Es un arreglo específico del producto, no una receta para Community OpenVPN, pero muestra por qué añadir una réplica cambia la red y no solo el almacén de cuentas.

Qué es una sesión: estado activo, no una fila

El tercer libro es la sesión activa. Un cliente conectado tiene estado de protocolo y una asignación de red en el nodo que lo aceptó. Que la cuenta sea conocida en el otro nodo no le da a ese nodo la sesión, las claves ni la capacidad de continuar los paquetes.

Sea explícito sobre qué ocurre cuando falla un nodo. El resultado admitido puede ser una reconexión al otro nodo con autenticación nueva y una dirección nueva, tras lo cual la aplicación se recupera a su manera. Si se exige un traspaso ininterrumpido, ese requisito necesita apoyo explícito en la implementación, no una inferencia de la replicación de la base de datos. Escriba la respuesta donde el ingeniero de guardia pueda encontrarla.

Las reglas de capacidad necesitan el mismo trato. Un límite de dos sesiones simultáneas por cuenta solo puede aplicarse entre nodos si alguna autoridad tiene una visión coordinada de las plazas ocupadas. Las listas locales de cada nodo y un registro histórico de la cuenta no suman esa visión.

Probar los tres libros

Ejercite cada uno por separado. Inicie sesión por el nodo A, luego por el nodo B, y confirme que ambos lo consiguen con los rangos de direcciones esperados. Retire una identidad y compruebe los dos nodos, no solo el que probó por casualidad. Después detenga un nodo y observe qué hacen realmente el cliente y la aplicación privada.

Incluya el camino de vuelta en la prueba de aceptación. Un cliente que se conecta a B pero no puede recibir respuestas de un recurso detrás de A ha superado la comprobación de admisión y ha fallado la de red, y esa distinción debería aparecer en el informe.

El diseño de cuenta multinodo solo está completo cuando los tres libros tienen un propietario explícito, un camino de cambio y un comportamiento ante fallos. Copiar un archivo de configuración entre nodos no responde ninguna de esas preguntas.