Onde o TLS fica dentro do OpenVPN e o que muda a forma

OpenVPN usa mesmo TLS, e as pessoas costumam estender isso a uma afirmação que ele não suporta: que um túnel, por isso, se parece com um navegador a visitar um site. A primeira parte é verdadeira. A segunda não. Aqui o TLS pertence a um canal de controlo que viaja dentro do próprio contentor do OpenVPN, ao lado de um canal de carga com criptografia completamente diferente, pelo que quem inspeciona os bytes iniciais vê OpenVPN.

Duas conversas num só envelope

Pense numa sessão como duas conversas que partilham um envelope. Uma valida certificados e deriva material de chave. A outra cifra o que está realmente a enviar, usando o que a primeira produziu.

O envelope é o protocolo. Cada pacote começa com um pequeno cabeçalho que nomeia o seu tipo, e esse cabeçalho chega antes de tudo o resto.

O que chega realmente primeiro

Por causa dessa ordenação, a primeira coisa no fio não é um registo TLS. É o cabeçalho do OpenVPN, seguido do conteúdo do canal que o cabeçalho anuncia. Um ClientHello existe lá dentro, só que não no byte zero. Não é preciso qualquer decifragem para notar a diferença, porque a forma por si só a denuncia.

Os valores por omissão também contam. O fluxo é UDP para 1194, a menos que o perfil escolha TCP. Em ambos os casos a aparência exterior é um túnel e não um pedido web.

Três formas honestas de mudar a forma

Um terminador TLS como o stunnel aceita TLS numa porta em cada extremidade e entrega o fluxo decifrado ao OpenVPN localmente, pelo que a rede vê TLS para essa porta. Um protocolo que é TLS desde o primeiro byte comporta-se de outra maneira: a troca compatível com AnyConnect que o ocserv implementa assemelha-se ao acesso remoto empresarial que muitas redes já esperam. O SSTP, que vem com o Windows, tem a mesma propriedade noutro produto.

No Linux, a opção -w do SSH transporta uma ligação ponto a ponto dentro de uma sessão SSH, o que é útil quando o SSH é o único protocolo permitido. É a mais barata das quatro se o SSH já funcionar a partir dessa rede, e a menos útil se não funcionar.

O que nenhuma delas muda

Nenhuma destas muda o que o túnel pode alcançar. Não tornam alcançável um endereço bloqueado, não autenticam ninguém e não decidem rotas.

Um invólucro também lhe custa um componente. Dois ouvintes e dois ficheiros de configuração significam dois locais de falha, e ambos parecem idênticos do lugar do utilizador. Orçamente isso antes de adotar um. A sessão continua a ser um único fluxo cifrado de longa duração para um destino, e o seu volume e timing continuam visíveis.

Diagnostique primeiro, escolha depois

Por isso, diagnostique primeiro. O UDP descartado responde-se com o modo TCP, e uma assinatura reconhecida responde-se com outro protocolo ou um invólucro. Escolher uma ferramenta antes de conhecer o bloqueio é como as pessoas acabam a manter três camadas que falham todas pela mesma razão.

Uma rede que só permite portas web restringe a escolha a um protocolo baseado em TLS na 443. Aplicar as três de uma vez dá uma pilha que ninguém consegue depurar, por isso mude uma coisa e reteste o mesmo fluxo.

Se nenhuma se aplicar, a resposta exata é que esta rede não vai transportar um túnel para si. Isso é uma constatação e não um falhanço do esforço. Percorrer mais opções não reverte uma decisão política tomada mais acima.

Um limite está à frente de tudo isto. A autorização para executar um túnel na rede de outra pessoa é uma questão de política, decidida em separado de o mecanismo funcionar. Estes factos explicam o que um observador vê, e não concedem autorização.