Wireproxy: cliente WireGuard ofrecido como proxy HTTP/SOCKS5

 (github.com/pufferffish)
2 puntos por GN⁺ 2024-04-03 | 1 comentarios | Compartir por WhatsApp
  • Wireproxy es un cliente WireGuard completo en espacio de usuario que se conecta a un peer de WireGuard y luego se expone en la máquina local como proxy SOCKS5/HTTP o túnel
  • Está pensado para casos en los que se quiere enviar solo el tráfico de ciertos sitios hacia un peer de WireGuard sin configurar una nueva interfaz de red, o cuando no se quiere usar permisos de root para cambiar la configuración de WireGuard
  • Sus funciones incluyen enrutamiento estático TCP, proxy SOCKS5/HTTP y proxy transparente basado en TLS SNI; el proxy HTTP actualmente solo admite CONNECT
  • La configuración sigue la semántica de [Interface] y [Peer] de wg-quick, y permite importar un archivo de configuración WireGuard existente con WGConfig o enrutar varios peers mediante AllowedIPs
  • Para operación, ofrece un health endpoint basado en --info/-i, y permite consultar el estado de WireGuard y la disponibilidad basada en CheckAlive mediante /metrics y /readyz

Qué hace Wireproxy

  • wireproxy es una aplicación en espacio de usuario que se conecta a un peer de WireGuard y expone en la máquina local un proxy SOCKS5/HTTP o un túnel
  • Puede usarse cuando se quiere acceder solo a ciertos sitios a través de un peer de WireGuard, pero no se quiere crear una nueva interfaz de red
  • Funciona completamente separado de la interfaz de red y no requiere permisos de root para la configuración
  • Los usuarios que necesiten un uso similar a Amnezia VPN pueden usar el fork wireproxy-awg

Funciones soportadas y funciones que aún no están disponibles

  • Funciones soportadas
    • Enrutamiento estático TCP para cliente y servidor
    • Proxy SOCKS5/HTTP
      • HTTP actualmente solo admite CONNECT
    • Proxy TLS transparente que usa Server Name Indication
  • Funciones pendientes en TODO
    • Soporte UDP para SOCKS5
    • Enrutamiento estático UDP

Ejecución e instalación

  • El formato básico de ejecución es ./wireproxy [-c path to config]
  • Opciones principales
    • -c, --config: especifica la ruta del archivo de configuración
      • Las rutas predeterminadas son /etc/wireproxy/wireproxy.conf, $HOME/.config/wireproxy.conf
    • -s, --silent: silent mode
    • -d, --daemon: ejecución en segundo plano
    • -i, --info: especifica la dirección y el puerto para exponer el health status
    • -v, --version: muestra la versión
    • -n, --configtest: solo verifica la validez del archivo de configuración
  • La compilación se realiza clonando el repositorio y luego ejecutando make
  • Como ejemplo de instalación, se usa go install github.com/windtf/wireproxy/cmd/wireproxy@v1.1.2 o @latest

Modelo de configuración

  • La configuración de [Interface] y [Peer] sigue el mismo significado que la configuración de wg-quick
  • Address debe usar la subred /32 para IPv4 y /128 para IPv6
  • PrivateKey también puede referenciar variables de entorno
  • Si ya existe una configuración de WireGuard, puede importarse con WGConfig = <path to the wireguard config>

Configuración de túneles y proxies

  • TCPClientTunnel
    • Reenvía el tráfico TCP recibido en la máquina local hacia el destino especificado a través de WireGuard
    • Un flujo de ejemplo es <LAN app> → localhost:25565 → WireGuard → play.cubecraft.net:25565
  • TCPServerTunnel
    • Reenvía el tráfico TCP recibido desde la red WireGuard hacia el destino especificado en la red local
    • Un flujo de ejemplo es <WireGuard network app> → WireGuard → 172.16.31.2:3422 → localhost:25545
  • STDIOTunnel
    • Conecta la entrada y salida estándar del proceso wireproxy a un destino TCP a través de WireGuard
    • Es útil para usarlo como parámetro ProxyCommand de openssh
  • Socks5
    • Crea un proxy SOCKS5 en la LAN local y enruta todo el tráfico por WireGuard
    • Si se especifican nombre de usuario y contraseña, activa la autenticación del proxy
  • http
    • Crea un proxy HTTP en la LAN local y enruta todo el tráfico por WireGuard
    • Si se especifican nombre de usuario y contraseña, activa la autenticación
    • Si se especifican CertFile y KeyFile, activa HTTPS
  • SNI
    • Crea un proxy TLS transparente en la LAN local y usa SNI como destino de enrutamiento para enviar el tráfico a través de WireGuard

Varios peers y enrutamiento

  • Se pueden usar varios peers de WireGuard
  • Al usar varios peers, se debe especificar AllowedIPs para que wireproxy sepa a qué peer reenviar
  • El ejemplo de configuración usa varios [Peer] con distintos AllowedIPs junto con varios TCPServerTunnel
  • También se incluye un ejemplo de UDPProxyTunnel
    • BindAddress especifica la dirección local de bind
    • Target especifica la dirección de destino
    • Si InactivityTimeout es 0, no hay timeout
  • [Resolve] configura la estrategia de resolución DNS
    • ipv4: prioriza registros A
    • ipv6: prioriza registros AAAA
    • auto: es el valor predeterminado; si la interfaz WireGuard solo tiene dirección IPv4, equivale a ipv4, y en caso contrario equivale a ipv6
  • Una configuración [Peer] sin Endpoint puede permitir que un peer se conecte a wireproxy

Health endpoint

  • --info/-i recibe una dirección y un puerto, por ejemplo localhost:9080, y expone un servidor HTTP que ofrece métricas de health status
  • Actualmente hay dos endpoints implementados
    • /metrics: expone información del demonio WireGuard y ofrece información equivalente a wg show
    • /readyz: devuelve en JSON la hora en que se recibió por última vez un pong desde la IP especificada en CheckAlive
  • Cuando se configura CheckAlive, envía un ping a la dirección especificada a través de WireGuard cada CheckAliveInterval segundos
    • El CheckAliveInterval predeterminado es de 5 segundos
    • Si no se recibe un pong dentro del último CheckAliveInterval más un margen de latencia de 2 segundos, devuelve 503
    • Si se cumple la condición, devuelve 200
  • Si CheckAlive no está configurado, /readyz devuelve un objeto JSON vacío y 200
  • El peer por el que se enrutan los paquetes ICMP ping depende de la configuración AllowedIPs de cada peer

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-03
Comentarios de Hacker News

  • Herramienta pequeña, pero excelente. La estoy usando con los multi-account containers de Firefox para seleccionar solo ciertas pestañas y proxyearlas hacia un router doméstico que soporta WireGuard, pero no proxies de capa de aplicación ni SSH

    • Recién me entero de que multi-account containers soporta configuración de proxy por contenedor.
      Pensaba que para configurarlo hacía falta una extensión aparte como https://addons.mozilla.org/en-GB/firefox/addon/container-pro..., pero no era así, y ahora parece que incluso esa confusión amerita downvotes
    • Me gustaría saber si hay algún buen recurso que explique cómo configurar algo así

  • Para lo que quería hacer con WireGuard, https://github.com/dariost/soks me quedó mejor. Hace casi lo mismo, pero reutiliza una interfaz WireGuard existente.
    Expliqué en detalle cómo usarlo en este artículo: https://www.nicoco.fr/blog/2023/09/10/wireguard/

    • Esto es bastante distinto. wireproxy parece incluir una implementación de TCP y WireGuard en espacio de usuario, mientras que soks se parece más a un router IP que solo puede manejar TCP.
      Parece que, en vez de usar la tabla de ruteo como mecanismo de control, decide si usar o no un proxy SOCKS5
    • Me da curiosidad por qué ese te resultó mejor.
      Antes hacía algo parecido con un contenedor Docker en una Raspberry Pi, pero una solución en espacio de usuario parece una opción mucho mejor porque se puede ejecutar en cualquier sistema operativo y garantiza que no arruinarás por accidente la tabla de ruteo del host

  • También está onetun: https://github.com/aramperes/onetun

  • Me pregunto si también existe una implementación de servidor completamente en espacio de usuario. Para hacerlo sin dispositivos tun/tap, supongo que haría falta algo como una pila IP en espacio de usuario, aunque no estoy seguro

  • Sería bueno para reemplazar los túneles SSH que usaba cuando necesitaba otra IP.
    Como herramienta relacionada también está pproxy, que entre muchas funciones puede “convertir” entre distintos protocolos de túnel y además tiene funciones de ruteo. Lo usé para convertir SSH SOCKS5 en un proxy HTTP: https://github.com/moreati/pproxy

  • Pensé: “¿esto se podría hacer bastante fácil en Go?”, y efectivamente estaba escrito en Go

  • Varios clientes proxy multiprotocolo soportan esta función. Ejemplos open source representativos son sing-box, clash-meta y otros clientes basados en clash, y xray.
    Como cliente de código cerrado está Surge Mac/iOS

    • Es cierto. Estos proxies multiprotocolo probablemente fueron creados para evadir el firewall de China, pero son un ecosistema pequeño e interesante.
      Tienen muchas posibilidades de ruteo de tráfico poco conocidas y también implementaciones para Android. Hace tiempo los probé para abrir un hotspot en Android sin root con una SIM que no soportaba hotspot.
      Eso sí, incluyen mucho código tomado de distintos lugares de internet y la comunidad de desarrolladores también es bastante peculiar por varias razones, así que siempre me pregunto qué tan confiables son
    • Del lado de código cerrado, Cloudflare WARP también puede funcionar en modo proxy. Si conviertes la configuración de WARP a una configuración WireGuard normal, también puedes usar así una cuenta gratuita
    • Para funcionar de forma estable en China, clash + v2ray parece ser casi lo único. La mayoría de los grandes proveedores de VPN dicen que funcionan en China, pero en la práctica no.
      No he investigado a fondo cómo funciona, pero me gusta el concepto de decidir con grupos de reglas qué dominios proxyear por la VPN

  • Me da curiosidad el rendimiento. Recuerdo que el SOCKS “vanilla” es muy fácil de configurar —es decir, ejecutar SSH con las opciones adecuadas y decirle a la aplicación que lo use—, pero era bastante lento.
    Esta herramienta parece ser para casos donde no hay un servidor SOCKS/SSH normal, pero me pregunto si también tiene ventajas en ese escenario

    • Me pregunto qué significa SOCKS “vanilla”. No sé contra qué otra implementación de SOCKS lo está comparando.
      En mi caso, SOCKS sobre SSH siempre tuvo un rendimiento bastante bueno, y era distinto de enfoques que ponen TCP sobre TCP, como el modo TUN de OpenSSH
    • Sería bueno comparar ambos. Ahora me conecto a WireGuard y luego creo un proxy SOCKS con SSH, y funciona sorprendentemente bien.
      Aun así, esta solución me interesa mucho

  • Justo estaba pensando que sería bueno tener una herramienta para proxyear todas las conexiones de correo de Thunderbird a través de un exit node de Tailscale, pero sin enviar todo el tráfico por ese exit node

    • Puedes usar la CLI de tailscale como proxy SOCKS: https://tailscale.com/kb/1113/aws-lambda
      Si la metes en una imagen de contenedor y expones el puerto SOCKS en el que escucha tailscale, ya tienes un proxy
    • También puedes instalar 3proxy o squid proxy en la máquina donde corre el exit node. Todas las máquinas de la tailnet podrán verlo

  • Si necesitas algo así específicamente para Mullvad VPN, probé https://github.com/imiric/mullvad-proxy y me gustó.
    No es mi proyecto; solo hice un fork para actualizarlo. Lo bueno es que incorpora la herramienta CLI de Mullvad, así que cambiar de servidor es muy fácil, y todo queda aislado de la máquina host. Además, como “solo” es nginx y algunos scripts, probablemente también soporte bien SOCKS5