Antes de substituir o IPsec pelo Shadowsocks, liste os trabalhos que faltam

Três serviços, um túnel: uma aplicação web, uma base de dados e uma partilha de ficheiros. Alguém propõe trocar o IPsec pelo Shadowsocks porque é mais simples de operar. O debate sobre cifra que se segue falha o essencial, porque o túnel faz várias tarefas ao mesmo tempo e só uma delas é sobre cifras. Anote essas tarefas antes de comparar produtos. A lista é curta, e qualquer ponto pode invalidar a troca.

Comece por como o tráfego é capturado

O protocolo tem duas metades. Um componente local aceita uma ligação, cifra um fluxo que começa com o endereço de destino e envia-o para um componente remoto. A metade remota abre uma ligação a esse destino e reencaminha os bytes. O UDP segue a mesma forma com datagramas. Isto é encaminhamento para os fluxos que captura, e não diz nada sobre os fluxos que não captura. Uma aplicação que fala um proxy de forma explícita é fácil; tudo o resto precisa de um adaptador ou de regras de encaminhamento para ser capturado.

Documente o método de captura por aplicação antes de comparar qualquer outra coisa. O tráfego não capturado sai pelo caminho habitual, e ninguém nota até um serviço se comportar de forma diferente fora do escritório.

Nomeie cada destino e cada protocolo

A metade remota tem de conseguir alcançar cada serviço interno. Uma sessão cifrada a funcionar até esse anfitrião não acrescenta uma rota dele para a base de dados, nem faz os nomes internos resolverem-se no cliente. Liste endereços, portas e protocolos em vez de escrever que a LAN está incluída.

Acrescente os casos que quebram projetos arrumados: DNS interno, aplicações que ignoram as definições de proxy e qualquer fluxo que tenha de ser iniciado do servidor para o cliente. Cada um precisa de um acordo explícito, não de uma suposição.

Cifra não é autorização

Os métodos AEAD documentados no Shadowsocks oferecem cifra autenticada, por isso rejeitar toda a família como insegura está errado. Deixar esse facto responder à pergunta do acesso é igualmente errado. Alguém tem de decidir quem chega a que serviço, como o acesso é retirado quando uma pessoa sai, onde ficam guardados os segredos e que componente aplica a fronteira. Um único segredo partilhado dá a cada detentor o mesmo alcance, e a saída de uma pessoa torna-se uma rotação para todos.

Meça a configuração atual de IPsec com o mesmo critério. O rótulo não prova que as regras estão certas, e comparar uma versão polida de um desenho com uma versão vaga do outro não decide nada.

Liste os controlos que existem hoje de ambos os lados e depois julgue com que lacunas consegue viver.

Conte o trabalho de operação

Cada substituição precisa de um responsável pelos pacotes de cliente, pelas atualizações do servidor, pela rotação de credenciais e pelo tratamento de falhas. Repare no que cada aplicação faz quando o túnel não está disponível: falha, tenta de novo pelo caminho local ou espera. Esse comportamento vem da instalação, não do nome do protocolo.

Para uma aplicação web, um proxy estreito pode bastar. Para acesso a toda a rede com permissões por pessoa, as peças adicionais costumam custar mais do que o túnel que substituíram.

A decisão não é qual produto soa mais seguro. É qual desenho termina os trabalhos listados com controlos que a equipa vai realmente manter.