Wireproxy: cliente WireGuard oferecido como proxy HTTP/SOCKS5

 (github.com/pufferffish)
2 pontos por GN⁺ 2024-04-03 | 1 comentários | Compartilhar no WhatsApp
  • O Wireproxy é um cliente WireGuard completo em espaço de usuário que se conecta a um peer WireGuard e depois é exposto na máquina local como proxy SOCKS5/HTTP ou túnel
  • É voltado para casos em que você quer enviar apenas o tráfego de sites específicos para um peer WireGuard sem configurar uma nova interface de rede, ou não quer usar privilégios de root para alterar a configuração do WireGuard
  • Os recursos incluem roteamento estático TCP, proxy SOCKS5/HTTP e proxy transparente baseado em TLS SNI; no momento, o proxy HTTP oferece suporte apenas a CONNECT
  • A configuração segue a semântica de [Interface] e [Peer] do wg-quick, e é possível importar um arquivo de configuração WireGuard existente com WGConfig ou rotear vários peers por AllowedIPs
  • Para operação em produção, oferece um health endpoint baseado em --info/-i, permitindo verificar o status do WireGuard e a prontidão baseada em CheckAlive por /metrics e /readyz

O que o Wireproxy faz

  • wireproxy é uma aplicação em espaço de usuário que se conecta a um peer WireGuard e expõe na máquina local um proxy SOCKS5/HTTP ou túnel
  • Pode ser usado quando você quer acessar apenas sites específicos por meio de um peer WireGuard, mas não quer criar uma nova interface de rede
  • Funciona de forma totalmente separada da interface de rede e não exige privilégios de root para configuração
  • Usuários que precisam de um uso semelhante ao Amnezia VPN podem usar o fork wireproxy-awg

Recursos suportados e recursos ainda ausentes

  • Recursos suportados
    • Roteamento estático TCP para cliente e servidor
    • Proxy SOCKS5/HTTP
      • Atualmente, HTTP oferece suporte apenas a CONNECT
    • Proxy TLS transparente usando Server Name Indication
  • Recursos que permanecem como TODO
    • Suporte a UDP no SOCKS5
    • Roteamento estático UDP

Execução e instalação

  • O formato básico de execução é ./wireproxy [-c path to config]
  • Principais opções
    • -c, --config: especifica o caminho do arquivo de configuração
      • Os caminhos padrão são /etc/wireproxy/wireproxy.conf, $HOME/.config/wireproxy.conf
    • -s, --silent: silent mode
    • -d, --daemon: execução em segundo plano
    • -i, --info: especifica endereço e porta para expor o health status
    • -v, --version: imprime a versão
    • -n, --configtest: verifica apenas a validade do arquivo de configuração
  • O build é feito clonando o repositório e executando make
  • Exemplos de instalação usam go install github.com/windtf/wireproxy/cmd/wireproxy@v1.1.2 ou @latest

Modelo de configuração

  • As configurações [Interface] e [Peer] seguem a mesma semântica das configurações do wg-quick
  • Address deve usar sub-rede /32 para IPv4 e /128 para IPv6
  • PrivateKey também pode referenciar variáveis de ambiente
  • Se você já tiver uma configuração WireGuard existente, pode importá-la com WGConfig = <path to the wireguard config>

Configuração de túneis e proxies

  • TCPClientTunnel
    • Encaminha o tráfego TCP recebido na máquina local para o destino especificado por meio do WireGuard
    • Um exemplo de fluxo é <app da LAN> → localhost:25565 → WireGuard → play.cubecraft.net:25565
  • TCPServerTunnel
    • Encaminha o tráfego TCP recebido da rede WireGuard para o destino especificado na rede local
    • Um exemplo de fluxo é <app da rede WireGuard> → WireGuard → 172.16.31.2:3422 → localhost:25545
  • STDIOTunnel
    • Conecta a entrada e a saída padrão do processo wireproxy a um destino TCP via WireGuard
    • É útil para uso como parâmetro ProxyCommand do openssh
  • Socks5
    • Cria um proxy SOCKS5 na LAN local e roteia todo o tráfego pelo WireGuard
    • Ao especificar nome de usuário e senha, ativa a autenticação do proxy
  • http
    • Cria um proxy HTTP na LAN local e roteia todo o tráfego pelo WireGuard
    • Ao especificar nome de usuário e senha, ativa a autenticação
    • Ao especificar CertFile e KeyFile, ativa HTTPS
  • SNI
    • Cria um proxy TLS transparente na LAN local e usa o SNI como destino de roteamento para enviar tráfego pelo WireGuard

Vários peers e roteamento

  • É possível usar vários peers WireGuard
  • Ao usar vários peers, é necessário especificar AllowedIPs para que o wireproxy saiba para qual peer encaminhar
  • O exemplo de configuração usa vários [Peer] com AllowedIPs diferentes junto com vários TCPServerTunnel
  • Também inclui um exemplo de UDPProxyTunnel
    • BindAddress especifica o endereço de bind local
    • Target especifica o endereço de destino
    • Se InactivityTimeout for 0, não há timeout
  • [Resolve] configura a estratégia de resolução DNS
    • ipv4: prioriza registros A
    • ipv6: prioriza registros AAAA
    • auto: valor padrão; se a interface WireGuard tiver apenas endereço IPv4, equivale a ipv4; caso contrário, equivale a ipv6
  • Uma configuração [Peer] sem Endpoint pode permitir que um peer se conecte ao wireproxy

Health endpoint

  • --info/-i recebe um endereço e porta, como localhost:9080, e expõe um servidor HTTP que fornece métricas de health status
  • Atualmente, dois endpoints estão implementados
    • /metrics: expõe informações do daemon WireGuard e fornece as mesmas informações de wg show
    • /readyz: retorna em JSON o horário em que o último pong foi recebido do IP especificado em CheckAlive
  • Quando CheckAlive é configurado, um ping é enviado via WireGuard para o endereço especificado a cada CheckAliveInterval segundos
    • O CheckAliveInterval padrão é de 5 segundos
    • Retorna 503 se não receber um pong dentro do último CheckAliveInterval somado a uma margem de 2 segundos de atraso
    • Retorna 200 se a condição for satisfeita
  • Se CheckAlive não estiver configurado, /readyz retorna um objeto JSON vazio e 200
  • O peer para o qual os pacotes de ping ICMP são roteados depende da configuração de AllowedIPs de cada peer

Leituras relacionadas

1 comentários

 
GN⁺ 2024-04-03
Comentários no Hacker News

  • Ferramenta pequena, mas excelente. Uso com os multi-account containers do Firefox para selecionar apenas certas abas e fazer proxy via WireGuard para um roteador doméstico que oferece suporte a WireGuard, mas não a proxy na camada de aplicação nem SSH

    • Foi a primeira vez que descobri que os multi-account containers oferecem suporte a configurações de proxy por contêiner
      Eu achava que, para configurar isso, era necessária uma extensão separada como https://addons.mozilla.org/en-GB/firefox/addon/container-pro..., mas não era; e agora parece que até esse equívoco já é motivo para downvote
    • Tenho curiosidade se há algum bom material explicando como configurar algo assim

  • Para o que eu queria fazer com WireGuard, https://github.com/dariost/soks serviu melhor. Faz praticamente a mesma coisa, mas reutiliza uma interface WireGuard existente
    Escrevi em detalhes sobre o modo de uso neste post: https://www.nicoco.fr/blog/2023/09/10/wireguard/

    • Isto é bem diferente. O wireproxy parece incluir uma implementação de TCP e de WireGuard em espaço de usuário, enquanto o soks está mais para um roteador IP que só consegue lidar com TCP
      Em vez de usar a tabela de roteamento como mecanismo de controle, parece decidir se usa ou não um proxy SOCKS5
    • Tenho curiosidade sobre por que essa opção serviu melhor para você
      Antigamente eu fazia algo parecido com um contêiner Docker em um Raspberry Pi, mas uma solução em espaço de usuário parece uma escolha muito melhor por poder rodar em qualquer sistema operacional e garantir que não vai estragar acidentalmente a tabela de roteamento do host

  • Também existe o onetun: https://github.com/aramperes/onetun

  • Fico me perguntando se também existe uma implementação de servidor totalmente em espaço de usuário. Para fazer isso sem dispositivo tun/tap, acho que seria preciso algo como uma pilha IP em espaço de usuário, mas não tenho certeza

  • Parece uma boa opção para substituir o túnel SSH que eu usava quando precisava de outro IP
    Como ferramenta relacionada, há também o pproxy, que, entre várias funções, consegue “converter” diferentes protocolos de túnel e também tem recursos de roteamento. Usei para transformar SSH SOCKS5 em proxy HTTP: https://github.com/moreati/pproxy

  • Pensei: “dá para fazer isso com bastante facilidade em Go, não?” E, claro, ele foi escrito em Go

  • Vários clientes proxy multiprotocolo oferecem suporte a esse recurso. Exemplos open source representativos são sing-box, clash-meta e outros clientes baseados em clash, além do xray
    Como cliente de código fechado, há o Surge Mac/iOS

    • Verdade. Esses proxies multiprotocolo provavelmente foram criados para contornar o firewall da China, e formam um pequeno ecossistema interessante
      Há muitas possibilidades pouco conhecidas de roteamento de tráfego, e também existem implementações para Android. No passado, usei isso para tentar abrir um hotspot em um Android sem root com um SIM que não oferecia suporte a hotspot
      Dito isso, há muito código vindo de vários cantos da internet, e a comunidade de desenvolvedores também é bastante peculiar por vários motivos, então sempre fico me perguntando o quanto dá para confiar
    • No lado de código fechado, o Cloudflare WARP também pode operar em modo proxy. Se você converter a configuração do WARP em uma configuração WireGuard comum, até uma conta gratuita pode ser usada assim
    • Na China, parece que praticamente só clash + v2ray funciona de forma estável. A maioria dos grandes provedores de VPN diz que funciona na China, mas na prática não funciona
      Não investiguei a fundo como funciona, mas gosto do conceito de decidir, por grupos de regras, quais domínios serão encaminhados por proxy via VPN

  • Tenho curiosidade sobre o desempenho. Pelo que me lembro, o SOCKS “vanilla” é muito fácil de configurar — basta executar o SSH com as opções certas e dizer à aplicação para usá-lo —, mas era bem lento
    Esta ferramenta parece ser para casos em que não há um servidor SOCKS/SSH comum, mas fico curioso se há vantagem nesse cenário também

    • Fico curioso sobre o que você quer dizer com SOCKS “vanilla”. Não sei com qual outra implementação de SOCKS isso estaria sendo contrastado
      No meu caso, SOCKS sobre SSH sempre teve um desempenho bem bom, e é diferente de uma abordagem que coloca TCP sobre TCP, como o modo TUN do OpenSSH
    • Seria bom comparar os dois. No momento, conecto ao WireGuard e depois crio um proxy SOCKS via SSH, e funciona surpreendentemente bem
      Ainda assim, tenho muito interesse nesta solução

  • Eu estava justamente pensando que seria bom ter uma ferramenta para encaminhar por proxy todas as conexões de e-mail do Thunderbird por um Tailscale exit node, sem mandar todo o tráfego para o exit node

    • A CLI tailscale pode ser usada como proxy SOCKS: https://tailscale.com/kb/1113/aws-lambda
      Se você colocar isso em uma imagem de contêiner e expor a porta SOCKS em que o tailscale escuta, vira um proxy imediatamente
    • Você também pode instalar 3proxy ou squid proxy na máquina onde o exit node está rodando. Todas as máquinas na tailnet conseguem vê-lo

  • Se você precisa de algo assim especificamente para o Mullvad VPN, usei https://github.com/imiric/mullvad-proxy e gostei
    O projeto não é meu; só fiz um fork para atualizações. O ponto positivo é que ele incorpora a ferramenta CLI da Mullvad, então trocar de servidor é muito fácil, e tudo fica isolado da máquina host. Além disso, como é “só” nginx e alguns scripts, o suporte a SOCKS5 também deve ser tranquilo