Wireproxy
v1.0.9
Ein Wireguard-Client, der sich als Socks5/http-Proxy oder Tunnel ausgibt.
wireproxy ist eine vollständige Userspace-Anwendung, die eine Verbindung zu einem Wireguard-Peer herstellt und einen Socks5/http-Proxy oder Tunnel auf dem Computer verfügbar macht. Dies kann nützlich sein, wenn Sie über einen Wireguard-Peer eine Verbindung zu bestimmten Standorten herstellen müssen, sich aber aus irgendeinem Grund nicht die Mühe machen, eine neue Netzwerkschnittstelle einzurichten.
Derzeit verwende ich Wireproxy, das mit einem Wireguard-Server in einem anderen Land verbunden ist, und habe meinen Browser so konfiguriert, dass er Wireproxy für bestimmte Websites verwendet. Das ist ziemlich nützlich, da Wireproxy vollständig von meinen Netzwerkschnittstellen isoliert ist und ich keinen Root benötige, um etwas zu konfigurieren.
Benutzer, die etwas Ähnliches wollen, außer für Amnezia VPN, können diesen Fork von Wireproxy von @artem-russkikh verwenden.
./wireproxy [-c path to config]
usage: wireproxy [-h|--help] [-c|--config ""] [-s|--silent]
[-d|--daemon] [-i|--info ""] [-v|--version]
[-n|--configtest]
Userspace wireguard client for proxying
Arguments:
-h --help Print help information
-c --config Path of configuration file
Default paths: /etc/wireproxy/wireproxy.conf, $HOME/.config/wireproxy.conf
-s --silent Silent mode
-d --daemon Make wireproxy run in background
-i --info Specify the address and port for exposing health status
-v --version Print version
-n --configtest Configtest mode. Only check the configuration file for
validity.
git clone https://github.com/octeep/wireproxy
cd wireproxy
make
Anweisungen zur Verwendung von Wireproxy mit Firefox-Container-Tabs und Autostart unter MacOS finden Sie hier.
# The [Interface] and [Peer] configurations follow the same semantics and meaning
# of a wg-quick configuration. To understand what these fields mean, please refer to:
# https://wiki.archlinux.org/title/WireGuard#Persistent_configuration
# https://www.wireguard.com/#simple-network-interface
[Interface]
Address = 10.200.200.2/32 # The subnet should be /32 and /128 for IPv4 and v6 respectively
# MTU = 1420 (optional)
PrivateKey = uCTIK+56CPyCvwJxmU5dBfuyJvPuSXAq1FzHdnIxe1Q=
# PrivateKey = $MY_WIREGUARD_PRIVATE_KEY # Alternatively, reference environment variables
DNS = 10.200.200.1
[Peer]
PublicKey = QP+A67Z2UBrMgvNIdHv8gPel5URWNLS4B3ZQ2hQIZlg=
# PresharedKey = UItQuvLsyh50ucXHfjF0bbR4IIpVBd74lwKc8uIPXXs= (optional)
Endpoint = my.ddns.example.com:51820
# PersistentKeepalive = 25 (optional)
# TCPClientTunnel is a tunnel listening on your machine,
# and it forwards any TCP traffic received to the specified target via wireguard.
# Flow:
# --> localhost:25565 --(wireguard)--> play.cubecraft.net:25565
[TCPClientTunnel]
BindAddress = 127.0.0.1:25565
Target = play.cubecraft.net:25565
# TCPServerTunnel is a tunnel listening on wireguard,
# and it forwards any TCP traffic received to the specified target via local network.
# Flow:
# --(wireguard)--> 172.16.31.2:3422 --> localhost:25545
[TCPServerTunnel]
ListenPort = 3422
Target = localhost:25545
# STDIOTunnel is a tunnel connecting the standard input and output of the wireproxy
# process to the specified TCP target via wireguard.
# This is especially useful to use wireproxy as a ProxyCommand parameter in openssh
# For example:
# ssh -o ProxyCommand='wireproxy -c myconfig.conf' ssh.myserver.net
# Flow:
# Piped command -->(wireguard)--> ssh.myserver.net:22
[STDIOTunnel]
Target = ssh.myserver.net:22
# Socks5 creates a socks5 proxy on your LAN, and all traffic would be routed via wireguard.
[Socks5]
BindAddress = 127.0.0.1:25344
# Socks5 authentication parameters, specifying username and password enables
# proxy authentication.
#Username = ...
# Avoid using spaces in the password field
#Password = ...
# http creates a http proxy on your LAN, and all traffic would be routed via wireguard.
[http]
BindAddress = 127.0.0.1:25345
# HTTP authentication parameters, specifying username and password enables
# proxy authentication.
#Username = ...
# Avoid using spaces in the password field
#Password = ...
Wenn Sie bereits über eine Wireguard-Konfiguration verfügen, können Sie diese alternativ wie folgt in die Wireproxy-Konfigurationsdatei importieren:
WGConfig =
# Same semantics as above
[TCPClientTunnel]
...
[TCPServerTunnel]
...
[Socks5]
...
Es wird auch unterstützt, mehrere Peers zu haben. AllowedIPs müssten angegeben werden, damit Wireproxy weiß, an welchen Peer er weiterleiten soll.
[Interface]
Address = 10.254.254.40/32
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
[Peer]
Endpoint = 192.168.0.204:51820
PublicKey = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
AllowedIPs = 10.254.254.100/32
PersistentKeepalive = 25
[Peer]
PublicKey = ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ=
AllowedIPs = 10.254.254.1/32, fdee:1337:c000:d00d::1/128
Endpoint = 172.16.0.185:44044
PersistentKeepalive = 25
[TCPServerTunnel]
ListenPort = 5000
Target = service-one.servicenet:5000
[TCPServerTunnel]
ListenPort = 5001
Target = service-two.servicenet:5001
[TCPServerTunnel]
ListenPort = 5080
Target = service-three.servicenet:80
Wireproxy kann auch Peers die Verbindung ermöglichen:
[Interface]
ListenPort = 5400
...
[Peer]
PublicKey = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
AllowedIPs = 10.254.254.100/32
# Note there is no Endpoint defined here.
Wireproxy unterstützt die Offenlegung eines Gesundheitsendpunkts zu Überwachungszwecken. Das Argument --info/-i gibt eine Adresse und einen Port an (z. B. localhost:9080 ), wodurch ein HTTP-Server verfügbar gemacht wird, der eine Gesundheitsstatusmetrik des Servers bereitstellt.
Derzeit sind zwei Endpunkte implementiert:
/metrics : Stellt Informationen des Wireguard-Daemons bereit. Dies liefert die gleichen Informationen, die Sie mit wg show erhalten würden. Dies zeigt ein Beispiel dafür, wie die Antwort aussehen würde.
/readyz : Dies antwortet mit einem JSON, das anzeigt, wann das letzte Mal ein Pong von einer mit CheckAlive angegebenen IP empfangen wurde. Wenn CheckAlive festgelegt ist, wird über Wireguard pro CheckAliveInterval Sekunden (Standard: 5) ein Ping an Adressen in CheckAlive gesendet. Wenn innerhalb der letzten CheckAliveInterval Sekunden (+2 Sekunden für etwas Spielraum zur Berücksichtigung der Latenz) kein Pong von einer der Adressen empfangen wurde, würde mit 503 geantwortet, andernfalls mit 200.
Zum Beispiel:
[Interface]
PrivateKey = censored
Address = 10.2.0.2/32
DNS = 10.2.0.1
CheckAlive = 1.1.1.1, 3.3.3.3
CheckAliveInterval = 3
[Peer]
PublicKey = censored
AllowedIPs = 0.0.0.0/0
Endpoint = 149.34.244.174:51820
[Socks5]
BindAddress = 127.0.0.1:25344
/readyz würde mit antworten
< HTTP/1.1 503 Service Unavailable
< Date: Thu, 11 Apr 2024 00:54:59 GMT
< Content-Length: 35
< Content-Type: text/plain; charset=utf-8
<
{"1.1.1.1":1712796899,"3.3.3.3":0}
Und für:
[Interface]
PrivateKey = censored
Address = 10.2.0.2/32
DNS = 10.2.0.1
CheckAlive = 1.1.1.1
/readyz würde mit antworten
< HTTP/1.1 200 OK
< Date: Thu, 11 Apr 2024 00:56:21 GMT
< Content-Length: 23
< Content-Type: text/plain; charset=utf-8
<
{"1.1.1.1":1712796979}
Wenn für CheckAlive nichts eingestellt ist, wird ein leeres JSON-Objekt mit 200 als Antwort zurückgegeben.
Der Peer, an den das ICMP-Ping-Paket weitergeleitet wird, hängt von den für jeden Peer festgelegten AllowedIPs ab.
