Unha conta VPN en dous servidores: tres libros de estado

Unha conta que pode iniciar sesión en calquera de dous nodos VPN expón unha pregunta de deseño moito antes de expoñer unha pregunta de software. A vista da conta, a rede que posúe cada nodo e a sesión que mantén un cliente conectado son tres tipos distintos de estado, e fallan de xeitos distintos cando os copias dun lado a outro. Copiar os tres nun só sistema é unha forma habitual de perder un deles.

Percorra os tres libros seguintes en orde. Cada un pregunta que é autoritativo, que é local e que ocorre cando o outro nodo non está, e as respostas non se deducen unhas doutras.

Quen pode conectarse: unha autoridade, moitos nodos

Empece polo libro de admisión: que orixe de identidade é autoritativa, que emisores de certificados son de confianza, que contas son elixibles, que segundo factor se aplica e a que pode chegar cada conta. Despois anote como se entera cada nodo dos cambios e con que rapidez.

Unha base de datos compartida é un compoñente posible desa resposta. Non é proba de que toda política relevante viva alí nin de que cada nodo aplique un cambio no mesmo instante. Unha conta desactivada no nodo A pero aínda aceptada no nodo B significa que o proceso de baixa non rematou.

Decida que fai un nodo cando a autoridade non é accesible. Aceptar credenciais en caché durante unha caída é unha decisión de política cun custo de seguridade, e rexeitalas é unha decisión de política cun custo de dispoñibilidade. Ambas son defendibles; deixalo sen documentar non o é.

Manteña a autoridade do emisor separada dos datos da conta. Varias pasarelas poden confiar na mesma CA sen ter a súa clave de sinatura, e cada nodo segue necesitando o seu propio certificado de servidor e a súa propia relación de confianza no lado do cliente.

Que posúe un nodo: enderezos e rutas

O segundo libro é local de cada nodo: enderezo de escoita, identidade do servidor, grupo de enderezos, rutas cara a recursos privados, política do resolvedor e como sae o tráfico cara a internet. A mesma conta pode ser atendida por calquera dos dous nodos mentres estes obxectos seguen sendo distintos.

O camiño de volta é a parte que se esquece. Se os dous nodos reparten enderezos do mesmo grupo, a rede privada non pode saber a que nodo pertence un cliente dado e a resposta pode ir ao lugar equivocado. Os grupos distintos tamén necesitan rutas e permisos, así que un rango de números distinto non é un deseño completo.

Dirixa os clientes a un nodo deliberadamente. A selección de DNS, as listas de puntos finais do cliente e un servizo de frontal son mecanismos distintos con comportamentos distintos de saúde e de conmutación por fallo. Escoller un está ben; tratar o «equilibrio de carga» como o deseño deixa o camiño de volta e o comportamento ante fallos sen definir.

Un exemplo de produto documentado axuda aquí. A documentación de replicación de Pritunl trata a rede VPN como un obxecto por réplica, e os clientes de réplicas distintas necesitan rutas e conectividade adicionais para acadarse. É un arranxo específico do produto, non unha receita para Community OpenVPN, pero mostra por que engadir unha réplica cambia a rede e non só o almacén de contas.

Que é unha sesión: estado activo, non unha fila

O terceiro libro é a sesión activa. Un cliente conectado ten estado de protocolo e unha asignación de rede no nodo que o aceptou. Que a conta sexa coñecida no outro nodo non lle dá a ese nodo a sesión, as claves nin a capacidade de continuar os paquetes.

Sexa explícito sobre que ocorre cando falla un nodo. O resultado admitido pode ser unha reconexión ao outro nodo con autenticación nova e un enderezo novo, tras o cal a aplicación se recupera á súa maneira. Se se esixe un traspaso ininterrompido, ese requisito necesita apoio explícito na implementación, non unha inferencia da replicación da base de datos. Escriba a resposta onde o enxeñeiro de garda poida atopala.

As regras de capacidade necesitan o mesmo trato. Un límite de dúas sesións simultáneas por conta só se pode aplicar entre nodos se algunha autoridade ten unha visión coordinada das prazas ocupadas. As listas locais de cada nodo e un rexistro histórico da conta non suman esa visión.

Probar os tres libros

Exercite cada un por separado. Inicie sesión polo nodo A, despois polo nodo B, e confirme que ambos o conseguen cos rangos de enderezos esperados. Retire unha identidade e comprobe os dous nodos, non só o que probou por casualidade. Despois deteña un nodo e observe que fan realmente o cliente e a aplicación privada.

Inclúa o camiño de volta na proba de aceptación. Un cliente que se conecta a B pero non pode recibir respostas dun recurso detrás de A superou a comprobación de admisión e fallou a de rede, e esa distinción debería aparecer no informe.

O deseño de conta multinodo só está completo cando os tres libros teñen un propietario explícito, un camiño de cambio e un comportamento ante fallos. Copiar un ficheiro de configuración entre nodos non responde ningunha desas preguntas.