Roteamento Seletivo via SOCKS5 em Sistemas Linux: Fundamentos, Implementação e Arquitetura de Controle de Fluxo

Deixe um comentário / Artigo, Console, Extremo, Firewall, IPTABLES, PROXY, Redes, Servidores, Tunel / Por

Resumo

Este artigo apresenta uma análise técnica detalhada sobre a utilização de proxies SOCKS5 como infraestrutura de roteamento seletivo em sistemas Linux. A abordagem transcende o uso convencional de SOCKS como proxy de aplicação, explorando técnicas de interceptação e redirecionamento transparente de fluxos TCP através da integração entre subsistemas do kernel e componentes em userspace. São examinadas três arquiteturas distintas: configuração direta por aplicação, redirecionamento via NAT com redsocks, e tunelamento por interface virtual com tun2socks. O trabalho demonstra como essas técnicas permitem controle granular sobre o caminho de tráfego de rede, mantendo transparência para aplicações e previsibilidade operacional.

1. Introdução

1.1 Contexto e Motivação

O protocolo SOCKS (Socket Secure) existe desde os anos 1990 como mecanismo de proxy para atravessar firewalls e redirecionar conexões TCP. Sua versão 5, definida na RFC 1928, introduziu suporte a autenticação, UDP e resolução de nomes remota. Tradicionalmente, SOCKS5 é configurado individualmente em cada aplicação, como navegadores web ou clientes de mensagens, funcionando como intermediário entre cliente e servidor final.

Essa abordagem convencional apresenta limitações significativas em cenários onde é necessário controle sistêmico sobre fluxos de rede. Ambientes corporativos, sistemas de evasão geográfica, redes com múltiplos links de saída e infraestruturas que exigem isolamento de tráfego demandam soluções mais sofisticadas. A questão central abordada neste trabalho é: como utilizar SOCKS5 não apenas como proxy de aplicação, mas como componente de uma arquitetura de roteamento seletivo controlada pelo sistema operacional?

1.2 Objetivos

Este artigo propõe e descreve metodologias para integração de proxies SOCKS5 com o subsistema de rede do kernel Linux, permitindo:

  • Seleção granular de fluxos TCP por destino, origem, processo ou interface
  • Redirecionamento transparente sem modificação de aplicações
  • Coexistência de rotas diretas e roteadas via proxy no mesmo sistema
  • Controle reproduzível e auditável do caminho de tráfego

2. Fundamentos Teóricos

2.1 O Protocolo SOCKS5

SOCKS5 opera na camada de sessão do modelo OSI, estabelecendo um canal entre cliente e servidor através de um intermediário. O handshake básico envolve três fases:

Fase 1 – Negociação de método de autenticação: O cliente envia os métodos suportados, e o servidor responde com o método escolhido. Para conexões sem autenticação, o método 0x00 é utilizado.

Fase 2 – Requisição de conexão: O cliente especifica o comando (CONNECT, BIND ou UDP ASSOCIATE), tipo de endereço (IPv4, IPv6 ou domínio) e porta de destino.

Fase 3 – Estabelecimento de túnel: Após confirmação do servidor, o túnel está estabelecido e os dados fluem bidirecionalmente de forma transparente.

Diferentemente de proxies HTTP que interpretam requisições em nível de aplicação, SOCKS5 opera como relay de bytes, tornando-o protocolo-agnóstico e adequado para qualquer tráfego TCP.

2.2 Arquitetura de Rede do Linux

O subsistema de rede do Linux processa pacotes através de uma pipeline complexa envolvendo múltiplos componentes:

Netfilter: Framework de filtragem e manipulação de pacotes, implementando hooks em diversos pontos da pilha de rede. As tabelas NAT (Network Address Translation) permitem modificar endereços e portas de pacotes.

Policy Routing: Sistema de roteamento baseado em regras que permite decisões de encaminhamento baseadas em múltiplos critérios além do endereço de destino, incluindo origem, marca de pacote (fwmark), interface de entrada e usuário proprietário.

Interfaces Virtuais: O kernel suporta diversos tipos de interfaces não-físicas, incluindo TUN (camada 3, IP) e TAP (camada 2, Ethernet), que permitem que processos em userspace recebam e injetem pacotes diretamente na pilha de rede.

A interação entre esses componentes permite construir arquiteturas onde o kernel decide quais fluxos devem ser redirecionados, enquanto processos em userspace realizam o encapsulamento SOCKS5.

2.3 Modelo de Três Camadas

A arquitetura proposta estrutura-se em três camadas distintas:

Camada 1 – Decisão (Kernel): Responsável por classificar pacotes e decidir seu destino. Utiliza iptables/nftables para marcação e redirecionamento, e ip rule/ip route para policy routing. Esta camada não conhece SOCKS5, apenas redireciona fluxos TCP para endereços locais.

Camada 2 – Tradução (Userspace Proxy): Recebe conexões TCP redirecionadas pelo kernel, estabelece handshake SOCKS5 com servidor remoto e atua como relay bidirecional. Ferramentas como redsocks implementam essa funcionalidade.

Camada 3 – Destino (Servidor SOCKS5): Recebe requisições SOCKS5 e estabelece conexões reais com os destinos finais. Pode ser local (via túnel SSH) ou remoto (servidor próprio ou comercial).

Essa separação de responsabilidades mantém a complexidade isolada e permite raciocínio independente sobre cada componente.

3. Estabelecendo o Servidor SOCKS5

Antes de implementar qualquer metodologia de roteamento, é necessário ter um servidor SOCKS5 disponível. Existem três abordagens principais, todas utilizando apenas software dos repositórios oficiais das distribuições:

3.1 Túnel SSH Dinâmico (Método Recomendado)

SSH possui suporte nativo a SOCKS5 através da opção -D. Este método cria um túnel criptografado até um servidor remoto onde você possui acesso SSH:

ssh -D 1080 -N -C -q [email protected]

Detalhamento dos parâmetros:

  • -D 1080: cria um servidor SOCKS5 local escutando na porta 1080
  • -N: não executa comandos remotos, apenas mantém o túnel ativo
  • -C: habilita compressão de dados no túnel
  • -q: modo silencioso, suprime mensagens de diagnóstico

Após executar este comando, você tem um proxy SOCKS5 rodando em 127.0.0.1:1080. Todo o tráfego que passar por este proxy será criptografado via SSH e sairá do servidor remoto.

Mantendo o túnel persistente com reconexão automática:

#!/bin/bash
while true; do
    ssh -D 1080 -N -C -q [email protected]
    echo "Conexão perdida. Reconectando em 5 segundos..."
    sleep 5
done

Autenticação por chave SSH (evita digitar senha):

# Gerar par de chaves (se ainda não tiver)
ssh-keygen -t ed25519 -f ~/.ssh/proxy_key -N ""

# Copiar chave pública para o servidor
ssh-copy-id -i ~/.ssh/proxy_key.pub [email protected]

# Conectar usando a chave
ssh -D 1080 -N -C -q -i ~/.ssh/proxy_key [email protected]

Criando um serviço systemd para inicialização automática:

Crie o arquivo /etc/systemd/system/socks-tunnel.service:

[Unit]
Description=SSH SOCKS5 Tunnel
After=network.target

[Service]
Type=simple
User=seu_usuario
ExecStart=/usr/bin/ssh -D 1080 -N -C -q -i /home/seu_usuario/.ssh/proxy_key [email protected]
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Ativar e iniciar:

systemctl daemon-reload
systemctl enable socks-tunnel
systemctl start socks-tunnel
systemctl status socks-tunnel

3.2 Servidor SOCKS5 Próprio com Dante

Para cenários onde você controla o servidor de destino, Dante é a implementação mais robusta, madura e confiável, presente nos repositórios oficiais de todas as distribuições principais.

Instalação no servidor de destino:

# Debian/Ubuntu
apt-get update
apt-get install dante-server

# Fedora/RHEL/CentOS
dnf install dante-server

# Arch Linux
pacman -S dante

Configuração básica funcional:

Edite /etc/danted.conf no servidor:

# Em qual interface/porta o servidor vai escutar
# 0.0.0.0 significa "todas as interfaces"
# eth0 é apenas um exemplo, use o nome da sua interface real
internal: 0.0.0.0 port = 1080

# Por qual interface o tráfego vai sair
# Use o nome da interface conectada à internet
external: eth0

# Métodos de autenticação
# "none" significa sem autenticação (apenas para testes ou redes confiáveis)
clientmethod: none
socksmethod: none

# Regra de acesso: quem pode se conectar ao servidor
# Esta regra permite qualquer IP se conectar
client pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

# Regra de uso: para onde os clientes podem enviar tráfego
# Esta regra permite qualquer destino
socks pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

Explicação linha por linha:

  • internal: define onde o servidor escuta conexões de clientes
  • external: define por qual interface o tráfego real vai sair para a internet
  • clientmethod/socksmethod: definem como clientes se autenticam
  • client pass: controla quem pode conectar no servidor SOCKS
  • socks pass: controla para quais destinos o servidor fará relay

Configuração com autenticação de usuário (produção):

internal: 0.0.0.0 port = 1080
external: eth0

# Primeira conexão não precisa autenticação
clientmethod: none

# Mas o uso do SOCKS requer usuário/senha do sistema
socksmethod: username

client pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

socks pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    # Esta linha requer autenticação
    socksmethod: username
}

Criar usuário específico para o proxy:

# Criar usuário sem acesso shell (mais seguro)
useradd -r -s /bin/false proxyuser

# Definir senha
passwd proxyuser

Inicializar o serviço:

systemctl enable danted
systemctl start danted
systemctl status danted

Testar do cliente:

curl --socks5 IP_DO_SERVIDOR:1080 https://ifconfig.me

3.3 Verificação e Diagnóstico

Após estabelecer o servidor SOCKS5, teste sua funcionalidade:

Teste básico:

# Verificar seu IP sem proxy
curl https://ifconfig.me

# Verificar IP através do proxy
curl --socks5 127.0.0.1:1080 https://ifconfig.me

Os IPs devem ser diferentes.

Teste de resolução DNS:

# Forçar resolução DNS remota
curl --socks5-hostname 127.0.0.1:1080 https://example.com

Verificar se o proxy está escutando:

ss -tlnp | grep 1080
# ou
netstat -tlnp | grep 1080

Log de debug (útil para troubleshooting):

Para SSH:

ssh -D 1080 -N -v [email protected]

Para Dante, edite /etc/danted.conf:

logoutput: syslog /var/log/danted.log

4. Metodologia 1: Configuração Direta por Aplicação

4.1 Descrição

O método mais simples consiste em configurar cada aplicação individualmente para utilizar o proxy SOCKS5. Não há intervenção do kernel neste caso, a própria aplicação implementa o handshake SOCKS5.

4.2 Implementação Prática

Aplicações com suporte nativo aceitam parâmetros de linha de comando:

# curl
curl --socks5 127.0.0.1:1080 https://ifconfig.me

# wget
wget -e use_proxy=yes -e socks_proxy=127.0.0.1:1080 https://example.com

# git
git config --global http.proxy socks5://127.0.0.1:1080

# ssh
ssh -o "ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p" [email protected]

4.3 Análise

Vantagens:

  • Controle absoluto por processo
  • Simplicidade de implementação
  • Sem requisitos de privilégios administrativos
  • Debugging facilitado

Limitações:

  • Não escalável para múltiplas aplicações
  • Requer suporte ou configuração individual
  • Dificulta políticas centralizadas

Esta abordagem é ideal para casos pontuais ou desenvolvimento, mas inadequada para controle sistêmico.

5. Metodologia 2: Redirecionamento por Destino via NAT

5.1 Arquitetura

Esta técnica utiliza o mecanismo de NAT do netfilter para interceptar conexões TCP destinadas a endereços específicos e redirecioná-las para um proxy local. O processo é completamente transparente para a aplicação original.

5.2 Fluxo de Pacotes

Quando uma aplicação tenta conectar a um endereço marcado para redirecionamento:

  1. Aplicação executa connect() para 203.0.113.10:443
  2. Kernel cria entrada na tabela de conexões (conntrack)
  3. Regra REDIRECT na cadeia OUTPUT da tabela nat modifica destino para 127.0.0.1:12345
  4. Pacote é entregue ao processo redsocks escutando na porta 12345
  5. Redsocks extrai destino original via getsockopt(SO_ORIGINAL_DST)
  6. Redsocks estabelece conexão SOCKS5 com servidor proxy
  7. Redsocks envia requisição CONNECT para 203.0.113.10:443
  8. Após confirmação, redsocks atua como relay bidirecional

5.3 Implementação com Redsocks

Instalação (repositórios oficiais):

# Debian/Ubuntu
apt-get install redsocks

# Fedora/RHEL
dnf install redsocks

# Arch Linux
pacman -S redsocks

Configuração clara e objetiva:

Edite /etc/redsocks.conf:

base {
    log_debug = off;
    log_info = on;
    log = "syslog:daemon";
    daemon = on;
    redirector = iptables;
}

redsocks {
    # Porta local onde redsocks vai escutar conexões redirecionadas
    local_ip = 127.0.0.1;
    local_port = 12345;
    
    # Endereço do servidor SOCKS5 real
    ip = 127.0.0.1;
    port = 1080;
    
    # Tipo de proxy
    type = socks5;
}

Explicação da configuração:

  • base: configurações gerais do redsocks
  • local_ip/local_port: onde o redsocks escuta tráfego redirecionado do iptables
  • ip/port: onde está o servidor SOCKS5 real (pode ser 127.0.0.1:1080 se for túnel SSH)
  • type: tipo de proxy (socks5, socks4, http-connect)

Configuração de redirecionamento iptables:

# Criar cadeia personalizada para organização
iptables -t nat -N REDSOCKS

# Não redirecionar tráfego local (essencial!)
iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN

# Redirecionar destino específico para redsocks
iptables -t nat -A REDSOCKS -d 203.0.113.0/24 -p tcp -j REDIRECT --to-ports 12345

# Aplicar cadeia ao tráfego de saída
iptables -t nat -A OUTPUT -p tcp -j REDSOCKS

Salvar regras permanentemente:

# Debian/Ubuntu
iptables-save > /etc/iptables/rules.v4

# Fedora/RHEL
iptables-save > /etc/sysconfig/iptables

# Instalar persistência automática
apt-get install iptables-persistent

Inicialização:

systemctl enable redsocks
systemctl start redsocks
systemctl status redsocks

5.4 Seleção Granular

Redirecionar destino específico:

iptables -t nat -A REDSOCKS -d 1.2.3.4 -j REDIRECT --to-ports 12345

Redirecionar por porta de destino:

iptables -t nat -A REDSOCKS -p tcp --dport 443 -j REDIRECT --to-ports 12345

Redirecionar apenas tráfego de usuário específico:

iptables -t nat -A REDSOCKS -m owner --uid-owner 1000 -j REDIRECT --to-ports 12345

Combinação complexa:

iptables -t nat -A REDSOCKS -d 203.0.113.0/24 -p tcp --dport 443 -m owner --uid-owner 1000 -j REDIRECT --to-ports 12345

6. Metodologia 3: Tunelamento via Interface Virtual

6.1 Conceito

Esta abordagem cria uma interface de rede virtual (TUN) onde todo o tráfego é automaticamente encaminhado para um proxy SOCKS5. Os pacotes são roteados para a interface TUN, capturados em userspace, e então encapsulados em SOCKS5.

6.2 Implementação Completa

Instalação (repositórios oficiais):

# Debian/Ubuntu
apt-get install badvpn

# Fedora/RHEL
dnf install badvpn

# Arch Linux
pacman -S badvpn

Criação e configuração da interface:

# Criar interface TUN
ip tuntap add dev tun0 mode tun user $(whoami)

# Atribuir endereço IP à interface
ip addr add 10.0.0.1/24 dev tun0

# Ativar interface
ip link set tun0 up

# Verificar
ip addr show tun0

Inicialização do badvpn-tun2socks:

badvpn-tun2socks \
    --tundev tun0 \
    --netif-ipaddr 10.0.0.2 \
    --netif-netmask 255.255.255.0 \
    --socks-server-addr 127.0.0.1:1080 \
    --loglevel info

Explicação dos parâmetros:

  • --tundev tun0: interface TUN a ser usada
  • --netif-ipaddr: IP que o tun2socks vai usar internamente
  • --netif-netmask: máscara de rede
  • --socks-server-addr: endereço do servidor SOCKS5 real

Configuração de roteamento seletivo:

# Criar tabela de roteamento customizada
echo "100 socks_tunnel" >> /etc/iproute2/rt_tables

# Adicionar rota padrão via tun0 nesta tabela
ip route add default dev tun0 table socks_tunnel

# Criar regra: tráfego de sub-rede específica usa esta tabela
ip rule add from 10.0.0.0/24 table socks_tunnel

# Verificar
ip rule list
ip route show table socks_tunnel

Roteamento por processo (avançado):

# Marcar pacotes de usuário específico
iptables -t mangle -A OUTPUT -m owner --uid-owner 1000 -j MARK --set-mark 100

# Rotear pacotes marcados via túnel
ip rule add fwmark 100 table socks_tunnel

Script completo para inicialização:

#!/bin/bash

# Criar interface
ip tuntap add dev tun0 mode tun
ip addr add 10.0.0.1/24 dev tun0
ip link set tun0 up

# Configurar tabela de roteamento
ip route add default dev tun0 table 100
ip rule add from 10.0.0.0/24 table 100

# Iniciar tun2socks em background
badvpn-tun2socks \
    --tundev tun0 \
    --netif-ipaddr 10.0.0.2 \
    --netif-netmask 255.255.255.0 \
    --socks-server-addr 127.0.0.1:1080 \
    --loglevel info &

echo "Túnel SOCKS5 estabelecido via tun0"

6.3 Resolução DNS

Para evitar vazamento de consultas DNS:

# Redirecionar DNS para resolver via túnel
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 10.0.0.2:53

7. Comparação das Metodologias

AspectoDiretoNAT/RedsocksTUN/tun2socks
ComplexidadeBaixaMédiaAlta
TransparênciaNenhumaTotalTotal
Seleção granularPor aplicaçãoPor destino/usuárioPor sub-rede
PrivilégiosNão requerRequer rootRequer root
PerformanceMáximaAlta (5-8% overhead)Média (10-15% overhead)
EscalabilidadeBaixaAltaMáxima

8. Aspectos de Segurança

8.1 Vazamentos de Informação

DNS Leaks:

# Forçar DNS via proxy
iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 5353

IPv6 Leaks:

# Bloquear IPv6 se não roteado
ip6tables -P OUTPUT DROP

8.2 Firewall de Proteção

# Bloquear todo tráfego direto exceto via proxy
iptables -P OUTPUT DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner redsocks -j ACCEPT

9. Conclusão

A integração de SOCKS5 com o subsistema de rede do Linux transforma um simples proxy de aplicação em uma infraestrutura sofisticada de controle de tráfego. As três metodologias apresentadas oferecem diferentes trade-offs entre simplicidade, controle e transparência. A escolha depende dos requisitos específicos: configuração direta para casos isolados, redirecionamento NAT para controle granular com mínimo overhead, e tunelamento TUN para abstração completa do roteamento.

Fundamentalmente, essas técnicas demonstram a flexibilidade da pilha de rede Linux e como componentes bem projetados podem ser combinados para resolver problemas complexos de roteamento seletivo usando apenas software dos repositórios oficiais, sem dependências de terceiros não-confiáveis.

Referências

  • RFC 1928: SOCKS Protocol Version 5
  • Linux Netfilter Documentation
  • Redsocks: Transparent TCP-to-proxy redirector (repositórios oficiais)
  • Badvpn tun2socks Implementation (repositórios oficiais)
  • Linux Advanced Routing & Traffic Control HOWTO

Related Posts

EMPRESA DEVDATA
EMPRESA DEVDATA
Rolar para cima