Wireproxy: WireGuard-Client, bereitgestellt als HTTP-/SOCKS5-Proxy

 (github.com/pufferffish)
2 Punkte von GN⁺ 2024-04-03 | 1 Kommentare | Auf WhatsApp teilen
  • Wireproxy ist ein vollständiger WireGuard-Client im Userspace, der sich mit einem WireGuard-Peer verbindet und auf dem lokalen Rechner als SOCKS5-/HTTP-Proxy oder Tunnel bereitgestellt wird
  • Gedacht für Fälle, in denen nur der Traffic bestimmter Websites an einen WireGuard-Peer gesendet werden soll, ohne ein neues Netzwerk-Interface einzurichten, oder wenn für Änderungen an der WireGuard-Konfiguration keine Root-Rechte verwendet werden sollen
  • Zu den Funktionen gehören statisches TCP-Routing, SOCKS5-/HTTP-Proxys und ein transparenter Proxy auf Basis von TLS SNI; der HTTP-Proxy unterstützt derzeit nur CONNECT
  • Die Konfiguration folgt der Bedeutung von [Interface] und [Peer] aus wg-quick; bestehende WireGuard-Konfigurationsdateien können über WGConfig importiert oder mehrere Peers per AllowedIPs geroutet werden
  • Für den Betrieb stellt es über --info/-i einen Health-Endpoint bereit; über /metrics und /readyz lassen sich der WireGuard-Status und der Bereitschaftsstatus auf Basis von CheckAlive prüfen

Was Wireproxy macht

  • wireproxy ist eine Userspace-Anwendung, die sich mit einem WireGuard-Peer verbindet und auf dem lokalen Rechner einen SOCKS5-/HTTP-Proxy oder Tunnel bereitstellt
  • Sie kann genutzt werden, wenn nur bestimmte Websites über einen WireGuard-Peer erreichbar sein sollen, aber kein neues Netzwerk-Interface angelegt werden soll
  • Sie arbeitet vollständig getrennt von Netzwerk-Interfaces und benötigt für die Konfiguration keine Root-Rechte
  • Nutzer, die einen ähnlichen Einsatzzweck wie bei Amnezia VPN benötigen, können den Fork wireproxy-awg verwenden

Unterstützte Funktionen und noch fehlende Funktionen

  • Unterstützte Funktionen
    • Statisches TCP-Routing für Client und Server
    • SOCKS5-/HTTP-Proxys
      • HTTP unterstützt derzeit nur CONNECT
    • Transparenter TLS-Proxy mit Server Name Indication
  • Funktionen, die noch auf der TODO-Liste stehen
    • UDP-Unterstützung für SOCKS5
    • Statisches UDP-Routing

Ausführung und Installation

  • Das grundlegende Ausführungsformat ist ./wireproxy [-c path to config]
  • Wichtige Optionen
    • -c, --config: Pfad zur Konfigurationsdatei festlegen
      • Standardpfade sind /etc/wireproxy/wireproxy.conf, $HOME/.config/wireproxy.conf
    • -s, --silent: Silent Mode
    • -d, --daemon: Im Hintergrund ausführen
    • -i, --info: Adresse und Port zum Bereitstellen des Health-Status angeben
    • -v, --version: Version ausgeben
    • -n, --configtest: Nur die Gültigkeit der Konfigurationsdatei prüfen
  • Der Build erfolgt nach dem Klonen des Repositorys mit make
  • Als Installationsbeispiel wird go install github.com/windtf/wireproxy/cmd/wireproxy@v1.1.2 oder @latest verwendet

Konfigurationsmodell

  • Die Einstellungen [Interface] und [Peer] haben dieselbe Bedeutung wie in einer wg-quick-Konfiguration
  • Address muss für IPv4 ein /32- und für IPv6 ein /128-Subnetz verwenden
  • PrivateKey kann auch über eine Umgebungsvariable referenziert werden
  • Wenn bereits eine WireGuard-Konfiguration vorhanden ist, kann sie mit WGConfig = <path to the wireguard config> importiert werden

Tunnel- und Proxy-Konfiguration

  • TCPClientTunnel
    • Leitet auf dem lokalen Rechner empfangenen TCP-Traffic über WireGuard an ein angegebenes Ziel weiter
    • Ein Beispielablauf ist <LAN-App> → localhost:25565 → WireGuard → play.cubecraft.net:25565
  • TCPServerTunnel
    • Leitet im WireGuard-Netzwerk empfangenen TCP-Traffic an ein angegebenes Ziel im lokalen Netzwerk weiter
    • Ein Beispielablauf ist <WireGuard-Netzwerk-App> → WireGuard → 172.16.31.2:3422 → localhost:25545
  • STDIOTunnel
    • Verbindet Standardeingabe und -ausgabe des wireproxy-Prozesses mit einem TCP-Ziel über WireGuard
    • Nützlich für den ProxyCommand-Parameter von openssh
  • Socks5
    • Erstellt einen SOCKS5-Proxy im lokalen LAN und routet den gesamten Traffic über WireGuard
    • Werden Benutzername und Passwort angegeben, wird Proxy-Authentifizierung aktiviert
  • http
    • Erstellt einen HTTP-Proxy im lokalen LAN und routet den gesamten Traffic über WireGuard
    • Werden Benutzername und Passwort angegeben, wird Authentifizierung aktiviert
    • Wenn CertFile und KeyFile angegeben werden, wird HTTPS aktiviert
  • SNI
    • Erstellt einen transparenten TLS-Proxy im lokalen LAN und sendet den Traffic über WireGuard, wobei SNI als Routing-Ziel verwendet wird

Mehrere Peers und Routing

  • Es können mehrere WireGuard-Peers verwendet werden
  • Bei mehreren Peers muss AllowedIPs angegeben werden, damit wireproxy weiß, an welchen Peer weitergeleitet werden soll
  • Das Konfigurationsbeispiel verwendet mehrere [Peer] mit unterschiedlichen AllowedIPs zusammen mit mehreren TCPServerTunnel
  • Ein Beispiel für UDPProxyTunnel ist ebenfalls enthalten
    • Mit BindAddress wird die lokale Bind-Adresse festgelegt
    • Mit Target wird die Zieladresse festgelegt
    • Wenn InactivityTimeout 0 ist, tritt kein Timeout ein
  • [Resolve] legt die DNS-Auflösungsstrategie fest
    • ipv4: A-Records bevorzugen
    • ipv6: AAAA-Records bevorzugen
    • auto: Standardwert; entspricht ipv4, wenn das WireGuard-Interface nur eine IPv4-Adresse hat, andernfalls ipv6
  • Mit einer [Peer]-Konfiguration ohne Endpoint kann erlaubt werden, dass sich ein Peer mit wireproxy verbindet

Health-Endpoint

  • --info/-i nimmt eine Adresse und einen Port wie zum Beispiel localhost:9080 entgegen und stellt einen HTTP-Server mit Health-Status-Metriken bereit
  • Derzeit sind zwei Endpoints implementiert
    • /metrics: Gibt Informationen über den WireGuard-Daemon aus und liefert dieselben Informationen wie wg show
    • /readyz: Gibt als JSON den Zeitpunkt zurück, zu dem zuletzt ein Pong von der in CheckAlive angegebenen IP empfangen wurde
  • Wenn CheckAlive gesetzt ist, wird alle CheckAliveInterval Sekunden über WireGuard ein Ping an die angegebene Adresse gesendet
    • Das Standard-CheckAliveInterval beträgt 5 Sekunden
    • Wenn innerhalb der letzten CheckAliveInterval Sekunden plus 2 Sekunden Toleranz kein Pong empfangen wurde, wird 503 zurückgegeben
    • Wenn die Bedingung erfüllt ist, wird 200 zurückgegeben
  • Wenn CheckAlive nicht gesetzt ist, gibt /readyz ein leeres JSON-Objekt und 200 zurück
  • Welcher Peer ICMP-Ping-Pakete routet, hängt von der AllowedIPs-Konfiguration des jeweiligen Peers ab

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-03
Hacker-News-Kommentare

  • Kleines Tool, aber großartig. Ich nutze es mit den Multi-Account-Containern von Firefox, um nur bestimmte Tabs über einen Heimrouter zu proxyen, der WireGuard unterstützt, aber keinen Proxy auf Anwendungsebene oder SSH hat

    • Ich habe gerade erst erfahren, dass Multi-Account-Container Proxy-Einstellungen pro Container unterstützen.
      Ich dachte, dafür bräuchte man eine separate Erweiterung wie https://addons.mozilla.org/en-GB/firefox/addon/container-pro..., aber das war nicht so, und anscheinend ist selbst so ein Irrtum inzwischen ein Grund für Downvotes
    • Falls jemand gutes Material hat, das erklärt, wie man so ein Setup konfiguriert, würde mich das interessieren

  • Für das, was ich mit WireGuard machen wollte, passte https://github.com/dariost/soks besser. Es macht fast dasselbe, verwendet aber eine vorhandene WireGuard-Schnittstelle wieder.
    Die Nutzung habe ich hier ausführlich beschrieben: https://www.nicoco.fr/blog/2023/09/10/wireguard/

    • Das ist ziemlich anders. wireproxy scheint im User Space eine TCP- und WireGuard-Implementierung zu enthalten, während soks eher ein IP-Router ist, der nur TCP verarbeiten kann.
      Statt die Routing-Tabelle als Steuerungsmittel zu verwenden, entscheidet es anscheinend darüber, ob ein SOCKS5-Proxy verwendet wird oder nicht
    • Mich würde interessieren, warum das für dich besser gepasst hat.
      Früher habe ich etwas Ähnliches mit einem Docker-Container auf einem Raspberry Pi gemacht, aber eine User-Space-Lösung scheint die deutlich bessere Wahl zu sein, weil sie auf jedem Betriebssystem laufen kann und garantiert nicht versehentlich die Routing-Tabelle des Hosts kaputtmacht

  • Es gibt auch onetun: https://github.com/aramperes/onetun

  • Ich frage mich, ob es auch eine vollständig im User Space laufende Server-Implementierung gibt. Um ohne tun/tap-Gerät auszukommen, bräuchte man wohl so etwas wie einen IP-Stack im User Space, aber ich bin nicht sicher

  • Das wäre gut als Ersatz für den SSH-Tunnel, den ich bisher genutzt habe, wenn ich eine andere IP brauchte.
    Ein verwandtes Tool ist pproxy, das unter vielen anderen Funktionen verschiedene Tunnel-Protokolle „umwandeln“ kann und auch Routing-Funktionen hat. Ich habe es verwendet, um SSH-SOCKS5 in einen HTTP-Proxy umzuwandeln: https://github.com/moreati/pproxy

  • Ich dachte mir: „So etwas müsste man in Go ziemlich leicht bauen können“, und tatsächlich war es in Go geschrieben

  • Mehrere Multi-Protokoll-Proxy-Clients unterstützen diese Funktion. Repräsentative Open-Source-Beispiele sind sing-box, clash-meta und andere auf clash basierende Clients sowie xray.
    Bei Clients mit proprietärem Quellcode gibt es Surge Mac/iOS

    • Stimmt. Diese Multi-Protokoll-Proxys wurden vermutlich zur Umgehung der chinesischen Firewall entwickelt, und das ist ein interessantes kleines Ökosystem.
      Es gibt viele wenig bekannte Möglichkeiten zur Verkehrslenkung, und es gibt auch Android-Implementierungen. Ich habe so etwas einmal verwendet, um auf einem nicht gerooteten Android-Gerät mit einer SIM ohne Hotspot-Unterstützung einen Hotspot bereitzustellen.
      Allerdings steckt darin viel Code aus allen möglichen Ecken des Internets, und auch die Entwickler-Community ist aus verschiedenen Gründen ziemlich speziell, daher frage ich mich immer, wie vertrauenswürdig das alles ist
    • Auf der proprietären Seite kann auch Cloudflare WARP im Proxy-Modus laufen. Wenn man die WARP-Konfiguration in eine normale WireGuard-Konfiguration umwandelt, kann man das sogar mit einem kostenlosen Konto so nutzen
    • In China scheint clash + v2ray fast das Einzige zu sein, das zuverlässig funktioniert. Die meisten großen VPN-Anbieter behaupten, in China zu funktionieren, tun es in der Praxis aber nicht.
      Ich habe mich nicht tief damit beschäftigt, wie es funktioniert, aber das Konzept von Regelgruppen, die entscheiden, welche Domains über das VPN geproxyt werden, gefällt mir

  • Mich würde die Leistung interessieren. Meiner Erinnerung nach war „vanilla“ SOCKS sehr einfach einzurichten — also einfach SSH mit den passenden Optionen starten und den Anwendungen sagen, sie sollen es verwenden — aber ziemlich langsam.
    Dieses Tool scheint für Fälle gedacht zu sein, in denen es keinen normalen SOCKS/SSH-Server gibt, aber ich frage mich, ob es auch dort Vorteile hat

    • Ich frage mich, was mit „vanilla“ SOCKS gemeint ist. Ich weiß nicht, gegen welche andere SOCKS-Implementierung das abgegrenzt werden soll.
      In meinem Fall war SOCKS über SSH leistungsmäßig immer ziemlich gut und unterschied sich von Ansätzen wie dem TUN-Modus von OpenSSH, bei denen man TCP über TCP schichtet
    • Es wäre gut, beides zu vergleichen. Ich verbinde mich derzeit mit WireGuard und erstelle dann per SSH einen SOCKS-Proxy, und überraschenderweise funktioniert das gut.
      Trotzdem interessiert mich diese Lösung sehr

  • Ich dachte gerade noch, es wäre schön, ein Tool zu haben, das alle E-Mail-Verbindungen von Thunderbird über einen Tailscale-Exit-Node proxyt, ohne gleich den gesamten Traffic über den Exit-Node zu schicken

    • Man kann die tailscale-CLI als SOCKS-Proxy verwenden: https://tailscale.com/kb/1113/aws-lambda
      Wenn man das in ein Container-Image packt und den SOCKS-Port freigibt, auf dem tailscale lauscht, hat man sofort einen Proxy
    • Man kann auch 3proxy oder squid proxy auf dem Rechner installieren, auf dem der Exit-Node läuft. Jede Maschine im Tailnet kann das sehen

  • Wenn man so etwas speziell für Mullvad VPN braucht, hatte ich gute Erfahrungen mit https://github.com/imiric/mullvad-proxy
    Es ist nicht mein Projekt, ich habe es nur für Updates geforkt. Das Gute daran ist, dass das Mullvad-CLI-Tool eingebettet ist, sodass man sehr einfach den Server wechseln kann, und alles vollständig vom Host-Rechner isoliert ist. Außerdem ist es „einfach“ nginx plus ein paar Skripte, daher dürfte auch die SOCKS5-Unterstützung in Ordnung sein