Una VPN de igual a igual conserva dependencias centrales
Una ruta de datos directa entre pares puede seguir necesitando inscripción, descubrimiento y un relé. Compare esas tres tareas por separado antes de llamar descentralizada a una VPN.
De igual a igual describe cómo viajan los paquetes de las aplicaciones, y nada más. Los pares seguían teniendo que encontrarse, demostrar quiénes son y, a veces, recurrir a un relé cuando no se podía construir una ruta directa. Son tres servicios separados, y un despliegue puede ser de igual a igual para los datos mientras está por completo centralizado para todo lo demás. Comparar diseños significa comparar esas tareas, no la flecha del diagrama.
Un diagrama sin una flecha central de reenvío puede ocultar una autoridad de inscripción, un servicio de descubrimiento y un relé, que son dependencias operativas.
Ruta directa, plano de control compartido
Dos máquinas que intercambian paquetes directamente pueden seguir dependiendo de una autoridad común que emitió sus certificados y de un servicio que dijo a cada una dónde está la otra. Ninguno de los dos papeles reenvía el tráfico de las aplicaciones, por eso el dibujo de topología los omite. Cuando esa autoridad o ese servicio está caído, las sesiones existentes pueden continuar mientras un nuevo par no puede unirse. La diferencia entre iniciar una sesión y continuarla es la primera pregunta que hay que hacerle a cualquier diseño.
Dibuje cada tarea por separado aunque un solo host las realice todas. De lo contrario, el dibujo muestra un plano de datos descentralizado y oculta la realidad operativa de que cada nuevo par necesita los mismos dos servicios.
Descubrimiento, confianza y relé son tres tareas
El diseño de Nebula es un ejemplo útil porque su documentación los mantiene separados. Los hosts llevan certificados para la identidad, los faros responden a la pregunta de dónde y ayudan con el traspaso de NAT, y los relés reenvían tráfico cuando no se puede establecer una ruta directa. El papel del relé es deliberadamente distinto del papel del faro, así que un faro accesible no promete que un par concreto pueda hablar. Otros productos trazan las fronteras en otro sitio, por eso esto es un ejemplo y no una plantilla.
Para un despliegue propuesto, anote el respaldo admitido para un par que no puede conectarse directamente. Un perforado de agujeros fallido es un dato sobre una red, no una prueba de que dos pares tras NAT nunca puedan encontrarse; la afirmación contraria, que la conectividad directa funciona con cualquier política, está igual de infundada.
En qué falla cada dependencia
Evalúe cuatro casos por separado mientras la dependencia sometida a prueba no está disponible: el tráfico existente entre pares, una conexión de par completamente nueva, un par cuyo extremo cambió y un acceso que acaba de revocarse. Cada uno depende de servicios distintos y falla de forma distinta. Las sesiones existentes pueden sobrevivir a una caída de descubrimiento mientras una clave revocada sigue siendo rechazada, y un nuevo par puede fallar por motivos que no tienen nada que ver con el reenvío. Pruébelos individualmente en lugar de concluir a partir de uno solo.
Una conexión que sobrevive a una sola caída no establece una independencia indefinida. Establece que la caída que usted provocó no era la que rompe esa ruta, lo que sigue siendo información útil siempre que haya anotado lo que provocó.
Pregunte qué caída puede sobrevivir
Requisitos que suenan parecidos llevan a diseños distintos. Evitar un único cuello de botella de reenvío no es lo mismo que evitar un plano de control alojado por un proveedor, y ninguno de los dos equivale a seguir funcionando mientras un coordinador está caído. Nombre cuál de esos tres debe cumplir el despliegue y luego compruebe la correspondencia. Un diseño que cumple el primero y falla el segundo es común y no es deshonesto, siempre que nadie lo llame totalmente descentralizado.
Anote quién opera el descubrimiento, la confianza y los relés, y cómo se sustituye cada uno. Ese registro es lo que permite a la siguiente persona responder a una pregunta real: qué fallos sobrevive esta red y quién mantiene el estado que sigue siendo compartido.
La palabra descentralizado se gana su lugar cuando nombra esos fallos. Sin esa lista, describe un diagrama y no un sistema.