OpenVPN através de um proxy HTTP: leia primeiro a resposta CONNECT

Aponte um cliente VPN para um proxy HTTP corporativo, e o primeiro facto útil é que o proxy não fala o protocolo da VPN. Abre uma ligação TCP comum para o endereço que indicou e depois afasta-se, deixando o cliente e o servidor fazerem a sua própria troca através desse fluxo. Tudo o que o cliente precisa, do tipo de transporte ao ouvinte do servidor, tem de corresponder a essa disposição. Duas incompatibilidades explicam a maioria das falhas: um perfil UDP dirigido a um proxy CONNECT e uma resposta do proxy tomada por um erro da VPN.

O que o proxy transporta, e o que não transporta

O proxy é apenas um salto de transporte. Não se torna o proxy do navegador, não coloca em cache os sites que visita através do túnel e não vê o tráfego interno, a menos que alguém tenha configurado a inspeção de propósito. O túnel que abre é opaco para ele por conceção.

Isso também significa que o proxy não consegue reparar um servidor sem um ouvinte correspondente. A permissão para chegar a um destino e um serviço que escuta nesse destino são dois factos distintos, e só o primeiro pertence ao administrador do proxy.

O transportador tem de ser TCP nas duas pontas

Um proxy CONNECT convencional apenas retransmite um fluxo de bytes , por isso o cliente tem de usar um transporte de fluxo. Um fragmento de cliente para esse caso tem este aspeto:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

O lado do servidor precisa de um ouvinte TCP real na porta indicada na linha remote. Mudar proto udp para proto tcp-client num perfil cria um cliente que espera um fluxo; não cria o fluxo do outro lado. Se o mesmo servidor também responde por UDP nessa porta, é outro ouvinte, não um segundo modo do mesmo.

Onde existe uma instância TCP separada, o respetivo dispositivo de túnel, conjunto de endereços e encaminhamento são recursos próprios. Copiar uma configuração que funciona e alterar a palavra de transporte deixa esses recursos a apontar para a instância original, o que produz uma ligação que se autentica e depois não encaminha nada.

Leia a resposta do proxy antes do resultado da VPN

A primeira troca do cliente é uma linha de pedido que nomeia o anfitrião e a porta de destino. A resposta a essa linha diz-lhe se existe algum fluxo de bytes, e chega antes de ser verificado qualquer certificado ou credencial:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Uma resposta de classe 200 ao CONNECT significa que o fluxo existe. Não diz nada sobre se o certificado da passagem é de confiança, se a chave partilhada coincide ou se a conta de utilizador é válida. Essas verificações acontecem depois, dentro do fluxo, e falham com as mensagens do próprio cliente em vez de uma linha de estado HTTP. Leia o registo do cliente para o primeiro OpenVPN evento após o aperto de mão com o proxy, não para a última linha antes de a janela fechar.

As credenciais do proxy e as da VPN são frequentemente identidades diferentes nas mãos de equipas diferentes. Um 407 não é uma palavra-passe errada da conta VPN, e um certificado rejeitado não é um problema de permissões do proxy.

O que o CONNECT não expõe

Um túnel CONNECT explícito não é interceção. O proxy reencaminha bytes e não termina a sessão TLS da VPN, pelo que a verificação do certificado do servidor pelo cliente continua a fazer sentido e deve permanecer ativa. Desativar a verificação para passar um proxy resolve um problema diferente do seu.

Existem disposições separadas em que uma organização termina e inspeciona TLS deliberadamente. Essas exigem a sua própria configuração de confiança e a sua própria decisão de política, e não são o que uma linha http-proxy comum pede.

O custo do TCP dentro do TCP

Transportar o túnel sobre TCP mantém o fluxo exterior ordenado e com retransmissão, e o tráfego interior é normalmente também TCP. Os dois mecanismos de recuperação não se coordenam, por isso um único segmento perdido pode bloquear tudo o que partilha esse fluxo exterior até ser retransmitido. É uma troca real por compatibilidade, não uma atualização gratuita.

Use o caminho pelo proxy quando a rede não lhe deixar alternativa, e prefira um caminho UDP direto onde a política o permitir. Em qualquer caso, após uma alteração confirme que o mesmo proxy, destino e perfil chegam à fase seguinte; um navegador que carrega uma página nesse endereço usa outro protocolo e não prova nada sobre o túnel.