OpenVPN remote-random: ordem embaralhada, um único túnel

A suposição é que adicionar remote-random transforma o perfil num conjunto rotativo, de modo que cada conexão sai de um endereço diferente. O que a diretiva faz na verdade é embaralhar a lista de remotes uma vez, quando o cliente começa a conectar-se, e depois tentá-los nessa nova ordem. O túnel que acaba por subir continua a terminar num único extremo e fica lá durante toda a vida da sessão.

Essa diferença importa tanto para testes como para alegações de privacidade.

O que a opção muda no momento da conexão

Um perfil de cliente pode conter várias linhas remote, cada uma com o seu próprio nome de anfitrião e porta. Sem a diretiva, são tentadas pela ordem do ficheiro; com ela, a lista é permutada uma vez no início da sessão e ganha o primeiro endereço que responder. As restantes ficam como alternativas para esta tentativa, não como caminhos paralelos. Um perfil com um único remote não dá nada para embaralhar à diretiva, e essa é a forma mais rápida de ver se pode ter importância.

O manual do OpenVPN documenta a opção como influenciando a ordem das tentativas de conexão, e esse é exatamente o âmbito que se deve esperar no comportamento.

Uma reconexão inicia um novo ciclo de seleção, pelo que uma sessão posterior pode acabar noutro sítio. O túnel ativo não se move enquanto está levantado.

Mito: cada pedido recebe um servidor novo

Depois de estabelecido, o túnel transporta todo o tráfego dessa sessão para o par escolhido. Não há reseleção por pedido, e a diretiva não é um balanceador de carga para ligações individuais: embaralha candidatos, não distribui pacotes. Cada aplicação que partilha esse túnel partilha o mesmo par. Tudo o que um navegador relata sobre a sua saída pertence à sessão, não a um pedido individual.

Se um teste mostrar duas saídas diferentes, procure duas sessões separadas em vez de uma opção engenhosa. Essa distinção também explica porque é que um teste de navegador e um teste de transferência podem discordar quando ocorreu uma reconexão entre eles.

Para que serve remote-random-hostname

Uma segunda diretiva com um nome semelhante altera o nome de anfitrião usado na resolução, não a ordem da lista de remotes. Existe para implementações em que um nome é resolvido em vários endereços através de DNS round-robin, e só deve ser usada quando o serviço está construído para isso. Só o passo de resolução muda; a ordem da lista de candidatos não.

Ativá-la porque os nomes parecem relacionados é um erro comum. Um certificado wildcard ou uma configuração de DNS que não espera o nome alterado simplesmente não vai resolver ou validar.

Leia o extremo selecionado no registo

Registe qual par uma sessão realmente usou antes de tirar conclusões. A saída detalhada indica o endereço que está a ser tentado, e o próprio perfil mostra quantos candidatos existem. Compare esse número com o endereço no registo antes de culpar o embaralhamento.

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

Para uma comparação de desempenho, fixe o extremo comentando os outros remotes, para que a variável em teste seja o protocolo ou o cliente e não o caminho. Para uma questão de privacidade, avalie a identidade do serviço e o seu registo como um todo; uma primeira escolha embaralhada não apaga cookies, não remove o início de sessão da conta e não torna dois operadores equivalentes.

Mantenha juntos o material de confiança fornecido e o conjunto de extremos suportados. O reembaralhamento muda apenas a ordem em que esse conjunto é tentado.