Proxy SOCKS5 para OpenVPN: túnel TCP ou facer proxy das aplicacións?

Un proxy retransmite un fluxo, non un datagrama. Compare un túnel TCP detrás de socks-proxy cunha redirección redsocks e vexa onde falla primeiro cada deseño.

As redes que só permiten saír a través dun proxy son onde un perfil que funcionaba morre de súpeto. O enderezo do proxy é a variable menos interesante dese fallo. Todo o decide a forma do tráfico que o proxy retransmitirá, porque estes proxies envían un fluxo de bytes e un túnel UDP non o é. Iso deixa dúas arquitecturas, e rompen en lugares distintos.

Unha restrición decide o deseño

SOCKS5 si especifica un modo de asociación UDP. A compatibilidade con proxy do cliente OpenVPN está, con todo, construída arredor de fluxos: socks-proxy está documentado para perfís TCP, e un proxy HTTP CONNECT non ten ningunha ruta para datagramas. Unha liña de documentación resolve a arquitectura antes de que toque un ficheiro de configuración.

A pregunta, xa que logo, non é que proxy escoller. É se o túnel se converte nun fluxo ou segue a ser un datagrama e deixa que outra cousa absorba o proxying.

Opción A: converter o túnel nun fluxo

Isto require un servidor cun oínte TCP e un perfil de cliente que nomee o proxy. Ambas as pezas son necesarias, e o lado do servidor é o que a xente esquece:

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

Substitúa a última liña por http-proxy proxy.internal 8080 cando o proxy fala HTTP, e engada un ficheiro de credenciais se o esixe. O proxy debe aceptar facer CONNECT ao seu porto VPN, e o servidor debe responder en TCP; un oínte só UDP ignora o intento. Escoller 443 é unha decisión práctica, porque moitas redes restritivas o permiten e pouco máis.

O custo é TCP sobre TCP. Un segmento exterior perdido bloquea todos os fluxos interiores que comparten esa conexión, así que unha recuperación que normalmente sería independente pasa a ser compartida. A configuración tamén tarda máis, e unha ruta exterior inestable convértese nun túnel inestable en lugar dun lento.

Opción B: deixar o túnel en paz

Cando o túnel debe quedar en UDP, o túnel non é onde se configura nada. No seu lugar, o TCP saínte das aplicacións rediríxese a un oínte SOCKS local, e as aplicacións nunca saben que existe un proxy. En Linux iso adoita ser redsocks máis unha regra NAT REDIRECT na táboa nat.

Só TCP, outra vez. Un proxy só HTTP como privoxy non pode retransmitir protocolos arbitrarios, e este deseño tampouco engade compatibilidade con datagramas para as aplicacións.

Dicirlle a cada aplicación o do proxy directamente adoita ser mellor cando o software o admite. É máis fácil de auditar, e falla nun sitio que realmente pode ver.

Onde falla cada opción

A opción A falla cando ao servidor lle falta un oínte TCP, cando o proxy rexeita o obxectivo CONNECT ou cando o fluxo exterior se limita por baixo do que o túnel necesita. As dúas primeiras deixan unha entrada no rexistro do proxy; a terceira deixa unha conexión que se establece e despois se sente mal. Lea ese rexistro antes de editar o perfil, porque separa un problema de permisos dun de capacidade. Un CONNECT completado traslada a investigación ao interior do túnel.

A opción B falla para todo o que necesite datagramas, para os protocolos que o proxy non entende, e en silencio en hosts onde a regra de redirección existe pero o encamiñamento envía o tráfico por outro lado.

Ningunha opción cambia o requisito do dispositivo. Os paquetes seguen necesitando un nodo TUN ou TAP antes de que o núcleo os encamiñe, así que o proceso segue necesitando permiso en /dev/net/tun. Un envoltorio cambia o que ocorre despois de que ese nodo estea aberto, non se o necesita.

Demostrar que camiño construíu

Mire os sockets en lugar da icona da bandexa. O proceso VPN debería manter unha conexión establecida co enderezo do proxy, e o proxy debería ter rexistrado o destino ao que se lle pediu chegar:

ss -tnp | grep openvpn

Despois busque un destino que só o túnel poida servir, e un nome que só o resolutor do túnel poida responder. Unha conexión de proxy completada cun túnel morto adoita significar que o extremo remoto nunca ofreceu o transporte indicado no seu perfil.

Anote o transporte e o proxy que acepta nun lugar duradeiro. Cando o mesmo perfil falle noutra rede, esa nota descarta ou confirma o proxy en segundos.

Artigos relacionados