Enrutamento por políticas fronte a SOCKS: que capa fai realmente de proxy

Engadiu unha ruta por políticas que envía o tráfico dun cliente VPN a un servidor que executa un escoitador SOCKS no porto 1080. Os paquetes chegan, o escoitador non rexistra nada e a conexión queda colgada. A ruta non ten nada malo: o seguinte salto escolle a onde vai un paquete, e SOCKS é unha conversa que o cliente debe iniciar. Compare as tres arquitecturas que a xente adoita querer dicir cando envía tráfico a través dun proxy e quedará claro que peza falta na súa configuración.

O enrutamento, DNAT e SOCKS cambian cousas distintas

Unha ruta por políticas reescribe unha decisión de capa 3. Dúas liñas abondan para enviar o tráfico dun cliente a un seguinte salto escollido:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Despois, o núcleo entrega o paquete a 10.50.0.2 co destino orixinal aínda na cabeceira IP. Se 10.50.0.2 é un encamiñador, reenvía o paquete. Se é un servidor cun demo SOCKS no 1080, o paquete non está dirixido a nada que poida aceptalo, e o DNAT ao porto 1080 tampouco axuda, porque un paquete traducido segue levando a carga útil orixinal da aplicación en lugar dun saúdo SOCKS.

SOCKS5 comeza cun byte de versión, unha lista de métodos, un intercambio de autenticación e unha petición que nomea o destino. Eso son datos de aplicación. Nin unha entrada de enrutamento nin un obxectivo de netfilter os xeran, e esa é a comparación nunha liña: o enrutamento escolle un camiño, SOCKS pide a un servidor que faga unha segunda conexión.

Caso un: a aplicación pode falar SOCKS por si mesma

Cando o programa ten un axuste de proxy, este é o camiño máis curto e non necesita ningún cambio no núcleo. Apúnteo ao escoitador, forneza credenciais se o servidor as pide e decida se os nomes se resolven localmente ou se pasan ao proxy. Con curl son indicadores distintos, e a diferenza importa cando o destino só se resolve desde o lado do proxy:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

As aplicacións que ignoran as variables de contorno de proxy, ou que abren sockets en bruto, non poden recibir axuda así. Os navegadores e a maioría das ferramentas HTTP están ben; un cliente de xogos, un demo de correo ou un binario calquera dun provedor normalmente non. O límite é por aplicación e por protocolo, por iso esta opción é excelente para probar e feble como resposta para todo o VPN.

Caso dous: un adaptador que converte fluxos IP en sesións de proxy

Para os programas que non poden falar SOCKS, a conversión ten que ocorrer en algo que remate o tráfico IP e abra sesións de proxy no seu nome. Ese compoñente posúe unha interface de túnel, acepta os fluxos que seleccionou o enrutamento por políticas, realiza o aperto de mans SOCKS para cada un e reconstrúe as respostas. A ruta dirixe o tráfico cara a el; o adaptador é o que crea a sesión.

Lea a súa documentación antes de lle confiar unha subrede enteira. Moitos adaptadores transportan ben TCP e só manexan UDP mediante unha asociación UDP de SOCKS5, e ningún converte ICMP en tráfico de proxy, así que un ping correcto non di nada sobre a ruta do proxy. O DNS é a outra trampa: se o adaptador resolve nomes localmente, os rexistros só internos resólvense a unha resposta equivocada, ou a nada de nada.

A prevención de bucles é o detalle operativo que morde. As conexións propias do adaptador ao servidor SOCKS non deben enrutarse de volta ao adaptador, así que o seu tráfico necesita unha excepción na regra ou un enderezo de orixe dedicado. Se se fai mal, a sesión de proxy tentará facer de proxy de si mesma.

Caso tres: o servidor é en realidade unha pasarela encamiñada

Ás veces a configuración que funciona non contén ningún SOCKS. O servidor remoto reenvía os paquetes ou lles aplica NAT, e a regra baseada na orixe simplemente o elixe como saída. Ese deseño é lexítimo, e explica por que unha configuración copiada funciona nunha rede e falla noutra: a regra é idéntica, a peza que falta é un servizo de reenvío no outro lado.

Os tres casos sepáranse axiña. Comprobe que está escoitando realmente e despois mire os primeiros bytes que chegan ao servidor:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

O primeiro byte de carga útil dun cliente SOCKS real é 0x05, a versión do saúdo. Se a captura mostra no seu lugar datos orixinais da aplicación, ningún demo SOCKS responderá, porque a negociación nunca comezou. Se nada escoita no 1080, o servidor é unha pasarela e a pregunta pasa a ser se reenvía e se existe un camiño de volta.

Escolla a capa con catro preguntas

O programa ten un axuste de proxy? Úseo e detéñase aí. O tráfico inclúe UDP ou ICMP que deben sobrevivir? Só unha pasarela encamiñada ou con NAT transporta ICMP, e UDP necesita unha asociación SOCKS5 que ambos extremos admitan. Debe cubrirse cada proceso da máquina, incluídos os que non pode configurar? Entón necesita un adaptador que posúa a interface e remate fluxos. Pode asumir tamén o seu enrutamento, DNS e excepcións de prevención de bucles? Se non, a pasarela simple custará menos de operar.

Unha distinción merece manterse clara. A propia opción socks-proxy dun cliente VPN describe como a conexión do túnel exterior chega ao seu servidor, e non di nada sobre converter os fluxos internos do cliente. As dúas confúndense constantemente no mesmo tícket. Decida que relación necesita antes de tocar unha ruta.