O WireGuard está pronto para produção? A resposta não é o protocolo

As pessoas perguntam se o WireGuard está pronto para produção, o que soa como uma pergunta sobre criptografia e na verdade é uma pergunta sobre o seu ambiente. O protocolo é examinado há anos; a implantação ainda tem de responder se as suas redes transportam o tráfego dele, quem inscreve e retira dispositivos e quem aplica correções ao pacote nas duas pontas. Essas respostas diferem entre dois servidores num rack e mil portáteis. O protocolo é o mesmo nos dois casos; as operações não.

A pergunta por trás da pergunta

O que as pessoas costumam querer saber é se podem comprometer-se com um desenho que não as deixe em apuros dentro de seis meses. É uma pergunta de implantação com quatro partes, e cada parte pode falhar independentemente das outras. Responder bem a três delas não compensa a quarta.

Um aviso antigo sobre uma versão de pré-lançamento é um facto sobre essa versão, não um rótulo permanente em cada pacote posterior. Da mesma forma, nenhum artigo de blog pode declarar pronta a sua combinação específica de kernel, cliente, rede e equipa. O trabalho é tornar a combinação explícita e verificá-la.

Trate a prontidão como um conjunto de portões que ou se passam ou se registam como abertos. Isso transforma uma discussão numa lista de verificação com responsáveis. Também torna os pontos abertos visíveis para quem aprova, em vez de enterrados num relatório piloto.

Portão um: o caminho tem de transportar UDP

O WireGuard transporta o seu tráfego sobre UDP e documenta que não oferece um modo TCP nem ofuscação de tráfego. Um desenho que depende de parecer tráfego web comum, ou de mudar a porta para obter comportamento TCP, assenta numa suposição que o software não suporta.

Por isso o primeiro portão é um levantamento, não um teste numa única máquina. Liste os ambientes de acesso em que os seus utilizadores realmente trabalham, depois verifique o caminho UDP aprovado em cada um e decida o que acontece quando ele não está disponível.

Uma ligação que funciona a partir do escritório não prova nada sobre uma rede de hotel, uma firewall de campus ou um operador móvel que trata o UDP de forma diferente. São esses ambientes a razão pela qual as implantações de acesso remoto falham depois de um piloto bem-sucedido. O piloto não estava errado; era estreito. Alargá-lo é o portão.

Escreva também o plano alternativo. Se a resposta for que não há plano alternativo, é uma decisão que vale a pena declarar de antemão em vez de a descobrir durante uma viagem de trabalho.

Portão dois: alguém tem de ser dono das chaves

Os pares do WireGuard autenticam-se com chaves, um par por participante. É simples de descrever e exigente em operação, porque nada no protocolo inscreve um dispositivo, acompanha quem tem que chave ou retira o acesso quando um portátil se perde. O protocolo assume que as chaves já estão corretas, e a correção é trabalho de alguém.

Nomeie a pessoa que inscreve um dispositivo, o registo que associa uma chave pública a uma pessoa e a um dispositivo, e o procedimento de remoção. Se a remoção depende de recordar onde foram instaladas cópias de um ficheiro de configuração, o procedimento não está terminado.

Escolha um dispositivo durante o piloto e retire-o de princípio a fim. Esse exercício produz informação mais útil do que outro teste de conectividade, porque expõe as lacunas nos seus registos.

Portão três: o pacote precisa de um mantenedor

O WireGuard pode chegar como implementação no kernel, como pacote de distribuição ou como cliente no espaço de utilizador, e cada um tem o seu próprio caminho de atualização. A pergunta operacional é qual executa, de onde veio e quem aplica um boletim de segurança.

Usamos WireGuard não é um inventário. Não identifica o pacote a corrigir, a versão na gateway nem a pessoa capaz de reverter uma atualização má.

Portão quatro: aceite a carga de trabalho, não o handshake

Os critérios de aceitação devem descrever o que os utilizadores fazem. Chegar a uma aplicação interna, resolver o seu nome privado, ser recusado num destino não autorizado e seguir o comportamento definido quando o túnel está em baixo são todos observáveis, e um handshake bem-sucedido não é nenhum deles.

Execute essas verificações através de uma mudança de rede, de um reinício do dispositivo e de uma janela de manutenção da gateway, porque é nessas transições que as implantações se quebram.

Guarde as provas ao lado dos critérios, incluindo o estado local que as produziu:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Um teste verde numa rede calma com um único portátil é uma observação inicial. Não é uma afirmação de fiabilidade, e tratá-lo como tal é como um desenho que funciona se torna um desenho em que se confia.