Uma rede pode bloquear a sua VPN sem quebrar a criptografia?

Nenhum operador precisa de uma chave de sessão para parar um túnel: descarte os pacotes no caminho e ele falha, enquanto a criptografia permanece exatamente tão forte quanto o seu projeto prometeu. A criptografia protege o que uma conversa transporta, não a disposição de qualquer rede de transportá-la. Separar essas duas propriedades transforma uma discussão sobre a impossibilidade de bloquear numa pergunta sobre qual política está em vigor e até onde ela chega. A comparação abaixo mantém disponibilidade e confidencialidade separadas, porque a maioria das afirmações seguras sobre o bloqueio de VPN as funde sem avisar.

A alcançabilidade é uma decisão do caminho

Todo transporte depende de um caminho que encaminha pacotes, e qualquer questão de política aqui reduz-se a essa decisão de encaminhamento. Uma regra que descarta pacotes altera a disponibilidade sem tocar na confidencialidade, e é assim que um túnel pode estar perfeitamente cifrado e totalmente inutilizável no mesmo instante. Nada desse resultado exige quebrar uma cifra ou recuperar uma chave. Exige apenas controlo sobre o caminho.

A confusão costuma começar com duas propriedades a partilhar uma palavra. A criptografia forte diz de quem pode ler um fluxo; não diz nada sobre se um dispositivo intermédio o deixará passar. Por isso, a afirmação de que uma VPN não pode ser bloqueada precisa de uma segunda afirmação por baixo, nomeadamente que ninguém no caminho está disposto a descartar os pacotes.

Estilos de aplicação e o preço de cada um

Três estilos cobrem a maioria das políticas reais, e diferem no que têm de saber, no que custa mantê-los e em quem mais sofre. Cada um deles pode recusar um túnel sem decifrar nada. As diferenças importam porque a mesma palavra, bloqueio, é usada para os três.

Essa tabela é um mapa de custos, não uma classificação. Uma lista de bloqueio é barata de começar e cara de manter exata; uma lista de permissão troca a descoberta pela manutenção do conjunto permitido, e um corte não precisa de qualquer classificação. O que as separa não é a sofisticação técnica mas onde cada uma coloca o esforço contínuo. Uma política que parece simples no papel tem normalmente uma linha de manutenção escondida noutro sítio.

Uma lista de bloqueio é limitada por quão bem um endereço nomeia um serviço

Uma lista de bloqueio recusa destinos já identificados e deixa os restantes geralmente disponíveis. Para a aplicar são precisos endereços e portas, não texto simples, e é isso que a torna barata de operar no início. O custo chega mais tarde, porque um intervalo que um dia identificava um fornecedor pode depois alojar uma dúzia de inquilinos não relacionados. Cada mudança de endereço obriga a editar a lista, e cada entrada obsoleta leva tráfego inocente consigo.

A precisão neste modelo é limitada por quão bem um destino identifica um serviço, e um ponto final partilhado e muito ocupado é um mau identificador. É um limite estrutural e não um defeito de implementação, por isso melhores ferramentas não o eliminam. Também explica por que as listas de bloqueio tendem a crescer: cada novo ponto final parece uma pequena adição, e o dano colateral cresce com a lista.

Uma lista de permissão transfere o ônus da manutenção

Uma lista de permissão inverte o padrão para que só passem os destinos ou tipos de tráfego escolhidos antecipadamente. Não tem de enumerar cada ponto final proibido, o que ajuda quando o conjunto proibido é grande ou muda depressa. O que precisa, em vez disso, é de uma definição mantida do que é permitido, mais uma aplicação que corresponda a essa definição.

Os números de porta são o ponto fraco habitual numa definição dessas. Permitir uma porta não é o mesmo que identificar cada aplicação que a pode usar, pelo que uma lista de permissão baseada em portas admite frequentemente mais do que o seu autor pretendia. As impressões digitais de protocolo têm o mesmo problema de outro ângulo, porque identificam uma forma de tráfego e não uma intenção. Uma lista de permissão não é, portanto, automaticamente mais precisa do que uma lista de bloqueio; é precisa sobre outra coisa.

O que uma observação pode sustentar e o que não pode

Qualquer afirmação sobre bloqueio deve ser lida com quatro perguntas na mão: que redes de acesso, que destinos, que protocolos e que período de observação. Uma falha vista hoje numa rede móvel não diz nada sobre o mesmo ponto final amanhã a partir de outra rede. Um túnel que funcionou uma vez também não diz nada sobre disponibilidade sustentada.

A forma de uma falha pode ser observada antes de teorizar sobre a sua causa. Um bloqueio silencioso, uma recusa imediata e um reinício após a ligação apontam para estilos de aplicação diferentes, e dois comandos separam-nos:

curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.com

Um bloqueio que termina em tempo limite sugere descarte silencioso, uma recusa rápida sugere um dispositivo que recusa no caminho, e um reinício após a ligação sugere interferência com estado e não uma rota ausente. O inquérito RFC 9505 sobre técnicas de censura descreve os pontos de controlo e os padrões de interferência por trás dessas formas. Nenhum deles diz, porém, até onde se aplica a política. A permanência é uma afirmação mais forte do que a alcançabilidade: pontos finais, software, políticas e serviços permitidos mudam todos, por isso uma eficácia indefinida exige suposições sobre a continuação da aplicação e não uma lista de endereços vistos num só momento.