OpenVPN sobre SOCKS5: axusta a versión, o transporte e o DNS

Unha cadea SOCKS falla cando a versión do proxy, o transporte ou a ruta DNS non coinciden. Usa SOCKS5, transporta TCP e mantén a cadea dentro dun namespace.

Unha saída desta estación de traballo é un proxy SOCKS, e OpenVPN detrás del informa dun tempo de espera de conexión sen nada útil. Un navegador na mesma máquina funciona a través dese proxy, as credenciais son correctas e o porto responde. Tres cousas difiren abondo a miúdo para comprobalas primeiro: a versión de SOCKS que fala o proxy, o transporte que escolleu o cliente e onde se fai a resolución de nomes. Confirma cada unha antes de decidir que o devasa ten a culpa.

Axusta a versión de SOCKS antes do devasa

O OpenVPN comunitario fala SOCKS5 para socks-proxy. Apunta a un proxy que só ofrece SOCKS4 e a conexión TCP ábrese, logo queda parada, porque o cliente agarda unha resposta a un saúdo que o outro extremo nunca analiza. Desde fóra, esa parada parece exactamente un porto filtrado, por iso a cuestión da versión vai antes de calquera regra do devasa. Unha consulta compatible con SOCKS decídeo nun só comando.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Unha petición completada demostra dúas cousas á vez: o proxy aceptou a petición SOCKS e resolveu o nome. Non fai falta ningún esquema de URL, porque curl trata un host espido como HTTP, o que abonda para esta proba.

Esa consulta tamén descarta o fallo que oculta o rexistro do cliente. Un proxy pode permitir o navegador e aínda así rexeitar o destino VPN, e nese caso o rexeitamento ocorre en CONNECT, antes de calquera autenticación VPN. OpenVPN só informa dun tempo de espera, así que a resposta do propio proxy é a evidencia que necesitas.

O transporte ten que ser TCP nos dous lados

SOCKS5 transporta aquí un fluxo TCP, así que o túnel mesmo necesita proto tcp-client. Un perfil que siga configurado para UDP non funcionará por esta ruta, porque o cliente non usa o modo de asociación UDP do protocolo. Cambiar o perfil é un cambio real e non unha formalidade: o extremo remoto ten que escoitar en TCP no mesmo porto. A carga pasa entón a ser TCP dentro de TCP, onde un segmento perdido se retransmite dúas veces e o ritmo se degrada, algo que as sesións interactivas notan moito máis que as transferencias grandes.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

A directiva toma o host do proxy, un porto opcional e un ficheiro de credenciais opcional. Ponos no propio perfil para que unha copia se comporte igual noutro sitio.

Confina toda a cadea a un só contedor

Facer a cadea no host significa tomar a súa ruta predeterminada e deixar o resolutor nun estado que ninguén poderá explicar despois. Un namespace ou un contedor acótao no seu lugar, de xeito que o host conserva a súa propia ruta mentres o salto SOCKS e o túnel viven xuntos. Dentro non levanta nada sen un dispositivo de túnel, os permisos para configuralo e un proxy accesible. Un servizo de Compose conségueo con cap_add: NET_ADMIN e un /dev/net/tun montado por bind.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Ese par é máis estreito que executar o contedor con privilexios, e é todo o acceso ao dispositivo que fai falta. Un cliente de Tor ou un contedor de proxy aparte poden proporcionar o escoitante. En calquera caso, átalo a loopback e acádeo desde o namespace a través do host en vez de expor o proxy á rede.

A resolución de nomes é onde falla o illamento

Un túnel que transporta paquetes mentres pregunta ao resolutor do host non illou nada. Dúas cousas fan real o illamento: o namespace ten un resolutor propio e as súas consultas viaxan polo proxy ou polo túnel, nunca pola interface física. Usa dous nomes para a proba: un que só exista detrás do túnel e un público que debería seguir a mesma ruta.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Se o nome do lado remoto se resolve e o público non, a cadea é selectiva e non está rota, e a diferenza diche que ruta tomou cada consulta. Se ambos se resolven desde o host pero ningún dentro do contedor, o contedor segue tomando prestado o resolutor do host. Anota o ficheiro de resolutor que atopaches, porque ese é o axuste que hai que cambiar.

Demostra cada salto en orde

A lista é curta. Unha petición SOCKS5 obtén resposta, o túnel alcanza o seu escoitante a través do proxy, e os paquetes que saen do namespace levan o enderezo que o lado remoto agarda. Confirma cada un por separado en lugar de apilar máis configuración. Cando o cliente di conectado e nada se move, a rotura está case sempre no segundo ou no terceiro feito.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

Anota a combinación que funcionou: versión de SOCKS, transporte, resolutor e axustes do namespace. Resolver esta cadea unha segunda vez de memoria custa máis ca nota. Garda eses catro feitos no tícket e non nun fío de chat.

Unha cadea que informa de conexión e non pasa nada adoita fallar no salto que aínda non demostraches. Proba ese salto antes de engadir outra capa.

Artigos relacionados