Unha VPN de igual a igual aínda ten dependencias centrais

De igual a igual describe como viaxan os paquetes das aplicacións, e nada máis. Os pares seguían tendo que atoparse, demostrar quen son e, ás veces, recorrer a un repetidor cando non se podía construír un camiño directo. Son tres servizos separados, e un despregamento pode ser de igual a igual para os datos mentres está completamente centralizado para todo o demais. Comparar deseños significa comparar esas tarefas, non a frecha do diagrama.

Un diagrama sen unha frecha central de reenvío pode ocultar unha autoridade de inscrición, un servizo de descuberta e un repetidor, que son dependencias operativas.

Camiño directo, plano de control compartido

Dúas máquinas que intercambian paquetes directamente poden seguir dependendo dunha autoridade común que emitiu os seus certificados e dun servizo que dixo a cada unha onde está a outra. Ningún dos dous papeis reenvía o tráfico das aplicacións, por iso o debuxo de topoloxía os omite. Cando esa autoridade ou ese servizo está caído, as sesións existentes poden continuar mentres un novo par non pode unirse. A diferenza entre iniciar unha sesión e continuar é a primeira pregunta que hai que facer a calquera deseño.

Debuxade cada tarefa por separado aínda que un só host as realice todas. Se non, o debuxo mostra un plano de datos descentralizado e oculta a realidade operativa de que cada novo par necesita os mesmos dous servizos.

Descubierta, confianza e repetidor son tres tarefas

O deseño de Nebula é un exemplo útil porque a súa documentación os mantén separados. Os hosts levan certificados para a identidade, os faros responden á pregunta de onde e axudan coa travessía de NAT, e os repetidores reenvían tráfico cando non se pode establecer un camiño directo. O papel de repetidor é deliberadamente distinto do papel de faro, así que un faro accesible non promete que un par concreto poida falar. Outros produtos trazan as fronteiras noutro lugar, por iso isto é un exemplo e non un modelo.

Para un despregamento proposto, anotade a alternativa admitida para un par que non se pode conectar directamente. Unha perforación de burato fallida é un dato sobre unha rede, non unha proba de que dous pares tras NAT nunca poidan atoparse; a afirmación contraria, que a conectividade directa funciona baixo calquera política, está igual de infundada.

En que falla cada dependencia

Avaliade catro casos por separado mentres a dependencia en proba non está dispoñible: o tráfico existente entre pares, unha conexión de par completamente nova, un par cuxo extremo cambiou e un acceso que acaba de ser revogado. Cada un depende de servizos distintos e falla de xeito distinto. As sesións existentes poden sobrevivir a unha caída de descuberta mentres unha clave revogada segue a ser rexeitada, e un novo par pode fallar por motivos que non teñen nada que ver co reenvío. Probádeos individualmente en lugar de concluír a partir dun só.

Unha conexión que sobrevive a unha soa caída non establece unha independencia indefinida. Establece que a caída que provocastes non era a que rompe ese camiño, o que segue sendo información útil sempre que anotásedes o que provocastes.

Preguntade a que caída podedes sobrevivir

Requisitos que soan igual levan a deseños distintos. Evitar un único pescozo de botella de reenvío non é o mesmo que evitar un plano de control aloxado por un provedor, e ningún dos dous equivale a seguir funcionando mentres un coordinador está caído. Nomeade cal deses tres debe cumprir o despregamento e despois comprobade a correspondencia. Un deseño que cumpre o primeiro e falla o segundo é habitual e non é deshonesto, sempre que ninguén o chame totalmente descentralizado.

Anotade quen opera a descuberta, a confianza e os repetidores, e como se substitúe cada un. Ese rexistro é o que permite á persoa seguinte responder unha pregunta real: a que fallos sobrevive esta rede, e quen mantén o estado que segue sendo compartido?

A palabra descentralizado gaña o seu lugar cando nomea esos fallos. Sen esa lista, describe un diagrama e non un sistema.