Proxy SOCKS5 para OpenVPN: túnel TCP ou fazer proxy das aplicações?

As redes que só permitem saída através de um proxy são onde um perfil que funcionava morre de repente. O endereço do proxy é a variável menos interessante dessa falha. Tudo depende da forma do tráfego que o proxy vai retransmitir, porque estes proxies transportam um fluxo de bytes e um túnel UDP não é isso. Isso deixa duas arquiteturas, e elas quebram em pontos diferentes.

Uma restrição decide o projeto

O SOCKS5 até especifica um modo de associação UDP. O suporte a proxy do cliente OpenVPN é, no entanto, construído em torno de fluxos: socks-proxy está documentado para perfis TCP, e um proxy HTTP CONNECT não tem caminho algum para datagramas. Uma linha de documentação resolve a arquitetura antes de você tocar num ficheiro de configuração.

A pergunta, portanto, não é qual proxy escolher. É se o túnel se torna um fluxo ou continua a ser um datagrama e deixa outra coisa absorver o proxying.

Opção A: transformar o túnel num fluxo

Isto exige um servidor com um ouvinte TCP e um perfil de cliente que nomeie o proxy. As duas peças são necessárias, e o lado do servidor é o que as pessoas esquecem:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Substitua a última linha por http-proxy proxy.internal 8080 quando o proxy fala HTTP, e acrescente um ficheiro de credenciais se ele o exigir. O proxy tem de aceitar executar CONNECT para a sua porta VPN, e o servidor tem de responder em TCP; um ouvinte só UDP ignora a tentativa. Escolher 443 é uma decisão prática, porque muitas redes restritivas o permitem e pouco mais.

O custo é TCP empilhado sobre TCP. Um segmento exterior perdido bloqueia todos os fluxos interiores que partilham essa ligação, por isso uma recuperação que normalmente seria independente passa a ser partilhada. A configuração também demora mais, e um caminho exterior instável torna-se um túnel instável em vez de lento.

Opção B: deixar o túnel em paz

Quando o túnel tem de ficar em UDP, o túnel não é o sítio onde se configura alguma coisa. Em vez disso, o TCP de saída das aplicações é redirecionado para um ouvinte SOCKS local, e as aplicações nunca ficam a saber que existe um proxy. No Linux isso costuma ser redsocks mais uma regra NAT REDIRECT na tabela nat.

Só TCP, outra vez. Um proxy só HTTP como o privoxy não consegue retransmitir protocolos arbitrários, e este projeto também não acrescenta suporte a datagramas para as aplicações.

Dizer a cada aplicação o proxy diretamente costuma ser melhor onde o software o permite. É mais fácil de auditar, e falha num sítio que pode realmente ver.

Onde cada opção falha

A opção A falha quando o servidor não tem um ouvinte TCP, quando o proxy recusa o alvo CONNECT ou quando o fluxo exterior é limitado abaixo do que o túnel precisa. Os dois primeiros deixam uma entrada no registo do proxy; o terceiro deixa uma ligação que se estabelece e depois parece errada. Leia esse registo antes de editar o perfil, porque separa um problema de permissões de um problema de capacidade. Um CONNECT concluído move a investigação para dentro do túnel.

A opção B falha para tudo o que precisa de datagramas, para os protocolos que o proxy não entende, e em silêncio em hosts onde a regra de redirecionamento existe mas o encaminhamento envia o tráfego ao lado.

Nenhuma opção muda o requisito do dispositivo. Os pacotes continuam a precisar de um nó TUN ou TAP antes de o kernel os encaminhar, por isso o processo continua a precisar de permissão em /dev/net/tun. Um invólucro muda o que acontece depois de esse nó estar aberto, não se precisa dele.

Provar que caminho construiu

Olhe para os sockets em vez do ícone da bandeja. O processo VPN deve manter uma ligação estabelecida ao endereço do proxy, e o proxy deve ter registado o alvo que lhe foi pedido para alcançar:

ss -tnp | grep openvpn

Depois procure um destino que só o túnel pode servir, e um nome que só o resolvedor do túnel pode responder. Uma ligação de proxy concluída com um túnel morto costuma significar que o extremo remoto nunca ofereceu o transporte indicado no seu perfil.

Anote o transporte e o proxy que aceita num local duradouro. Quando o mesmo perfil falhar noutra rede, essa nota exclui ou confirma o proxy em segundos.