Uma VPN ponto a ponto ainda tem dependências centrais

Ponto a ponto descreve como os pacotes das aplicações viajam, e nada mais. Os pares ainda tinham de se encontrar, provar quem são e, por vezes, recorrer a um retransmissor quando não era possível construir um caminho direto. São três serviços separados, e uma implementação pode ser ponto a ponto para os dados enquanto está totalmente centralizada para todo o resto. Comparar projetos significa comparar essas tarefas, não a seta do diagrama.

Um diagrama sem uma seta central de encaminhamento pode esconder uma autoridade de inscrição, um serviço de descoberta e um retransmissor, que são dependências operacionais.

Caminho direto, plano de controlo partilhado

Duas máquinas que trocam pacotes diretamente podem ainda depender de uma autoridade comum que emitiu os seus certificados e de um serviço que disse a cada uma onde está a outra. Nenhum dos dois papéis encaminha o tráfego das aplicações, razão pela qual o desenho da topologia os omite. Quando essa autoridade ou esse serviço está em baixo, as sessões existentes podem continuar enquanto um novo par não consegue entrar. A diferença entre iniciar uma sessão e continuá-la é a primeira pergunta a fazer a qualquer projeto.

Desenhe cada tarefa separadamente, mesmo quando um único anfitrião as executa todas. Caso contrário, o desenho mostra um plano de dados descentralizado e esconde a realidade operacional de que cada novo par precisa dos mesmos dois serviços.

Descoberta, confiança e retransmissor são três tarefas

O projeto do Nebula é um exemplo útil porque a sua documentação os mantém separados. Os anfitriões transportam certificados para a identidade, os faróis respondem à pergunta de onde e ajudam na travessia de NAT, e os retransmissores encaminham tráfego quando não é possível estabelecer um caminho direto. O papel de retransmissor é deliberadamente distinto do papel de farol, por isso um farol acessível não promete que um determinado par consiga falar. Outros produtos traçam as fronteiras noutro lugar, e é por isso que isto é um exemplo e não um modelo.

Para uma implementação proposta, registe a alternativa suportada para um par que não consegue ligar-se diretamente. Uma perfuração de buraco falhada é um dado sobre uma rede, não uma prova de que dois pares atrás de NAT nunca possam encontrar-se; a afirmação contrária, de que a conetividade direta funciona sob qualquer política, é igualmente infundada.

Em que falha cada dependência

Avalie quatro casos separadamente enquanto a dependência em teste está indisponível: o tráfego existente entre pares, uma ligação de par totalmente nova, um par cujo ponto final mudou e um acesso que acabou de ser revogado. Cada um depende de serviços diferentes e falha de forma diferente. As sessões existentes podem sobreviver a uma falha de descoberta enquanto uma chave revogada continua a ser recusada, e um novo par pode falhar por razões que nada têm a ver com o encaminhamento. Teste-os individualmente em vez de concluir a partir de um só.

Uma ligação que sobrevive a uma única falha não estabelece uma independência indefinida. Estabelece que a falha que provocou não era a que quebra esse caminho, o que continua a ser informação útil desde que tenha registado o que provocou.

Pergunte a que falha consegue sobreviver

Requisitos que soam parecidos levam a projetos diferentes. Evitar um único estrangulamento de encaminhamento não é o mesmo que evitar um plano de controlo alojado num fornecedor, e nenhum dos dois equivale a continuar a funcionar enquanto um coordenador está em baixo. Nomeie qual desses três a implementação tem de cumprir e depois verifique a correspondência. Um projeto que cumpre o primeiro e falha o segundo é comum e não é desonesto, desde que ninguém o chame totalmente descentralizado.

Registe quem opera a descoberta, a confiança e os retransmissores, e como cada um é substituído. Esse registo é o que permite à pessoa seguinte responder a uma pergunta real: que falhas esta rede sobrevive, e quem mantém o estado que continua a ser partilhado?

A palavra descentralizado ganha o seu lugar quando nomeia essas falhas. Sem essa lista, descreve um diagrama e não um sistema.