wireguard docs
1.0.0
API-Referenzhandbuch für WireGuard, einschließlich Einrichtung, Konfiguration und Verwendung, mit Beispielen.
Der gesamte Dank geht an das WireGuard-Projekt, zx2c4 und die Open-Source-Mitwirkenden für die Originalsoftware.
Dies ist mein einziger inoffizieller Versuch, eine umfassendere Dokumentation, API-Referenzen und Beispiele bereitzustellen.
Quelle für diese Dokumente, Beispielcode und Issue-Tracker: https://github.com/pirate/wireguard-docs Schönere HTML-Seitenversion: https://docs.sweeting.me/s/wireguard
WireGuard ist eine Open-Source-VPN-Lösung, die von Jason Donenfeld und anderen in C geschrieben wurde und darauf abzielt, viele der Probleme zu beheben, die andere moderne Server-zu-Server-VPN-Angebote wie IPSec/IKEv2, OpenVPN oder L2TP plagen. Es weist einige Gemeinsamkeiten mit anderen modernen VPN-Angeboten wie Tinc und MeshBird auf, nämlich gute Verschlüsselungssammlungen und minimale Konfiguration. Ab 2020-01 wurde es in die Version 5.6 des Linux-Kernels integriert, was bedeutet, dass es mit den meisten Linux-Systemen sofort einsatzbereit ist.
Offizielle Links
wg , wg-quickWireGuard-Ziele
Beispielcode und Dokumentationsquelle finden Sie unter https://github.com/pirate/wireguard-docs.
Egal, ob Sie hinter der Chinesischen Mauer leben oder einfach nur versuchen, ein Netzwerk zwischen Ihren Servern aufzubauen, WireGuard ist eine großartige Option und dient als „Lego-Block“ zum Aufbau von Netzwerken (ähnlich wie ZFS ein Lego-Block zum Aufbau von Dateisystemen ist). ).
Dinge, die WireGuard nicht tut:
Aber Sie können Ihre eigenen Lösungen für diese Probleme schreiben, indem Sie WireGuard unter der Haube verwenden (wie Tailscale oder AltheaNet).
Dabei handelt es sich um Demo-Hostnamen, Domänennamen, IP-Adressen und Bereiche, die in der Dokumentation und in Beispielkonfigurationen verwendet werden. Ersetzen Sie sie durch Ihre bevorzugten Werte, wenn Sie Ihr eigenes Setup durchführen.
example-vpn.dev kann durch jede öffentlich zugängliche Domäne ersetzt werden, die Sie kontrollierenpublic-server1 , public-server2 , home-server , laptop , phone können in die Hostnamen Ihres Geräts geändert werden192.0.2.1/24 , 192.0.2.3 , 192.0.2.3/32 , 2001:DB8::/64 können durch Ihre bevorzugten Subnetze und Adressen ersetzt werden (z. B. 192.168.5.1/24 ).Wo immer Sie diese Zeichenfolgen unten sehen, werden sie lediglich als Platzhalterwerte zur Veranschaulichung eines Beispiels verwendet und haben keine besondere Bedeutung.
Stellen Sie sicher, dass Sie die IP-Adressen in Ihren Konfigurationen ändern! Die in diesen Dokumenten verwendeten Blöcke sind der IETF für Beispielzwecke vorbehalten und sollten niemals in realen Netzwerk-Setups verwendet werden.
192.0.2.0/24 (TEST-NET-1) IPv4-Beispielbereich RFC57372001:DB8::/32 IPv6-Beispielbereich RFC3849 Sie können jeden gewünschten privaten Bereich für Ihre eigenen Setups verwenden, z. B. 10.0.44.0/24 . Stellen Sie jedoch sicher, dass dieser nicht mit einem der LAN-Subnetzbereiche in Konflikt steht, in denen sich Ihre Peers befinden.
Ein Host, der sich mit dem VPN verbindet und eine VPN-Subnetzadresse wie 192.0.2.3 für sich registriert. Optional kann es auch Datenverkehr für mehr als seine eigene(n) Adresse(n) weiterleiten, indem es Subnetzbereiche in durch Kommas getrennter CIDR-Notation angibt.
Ein öffentlich erreichbarer Peer/Knoten, der als Fallback für die Weiterleitung des Datenverkehrs für andere VPN-Peers hinter NATs dient. Ein Bounce-Server ist kein spezieller Servertyp, sondern ein normaler Peer wie alle anderen. Der einzige Unterschied besteht darin, dass er über eine öffentliche IP verfügt und die IP-Weiterleitung auf Kernel-Ebene aktiviert ist, wodurch er den Datenverkehr über das VPN zurückleiten kann an andere Kunden.
Weitere Informationen: https://tailscale.com/blog/how-nat-traversal-works/ (Tailscale verwendet Wireguard unter der Haube)
Eine vom öffentlichen Internet getrennte Gruppe von IPs, z. B. 192.0.2.1-255 oder 192.168.1.1/24. Im Allgemeinen hinter einem NAT, das von einem Router bereitgestellt wird, z. B. im Büro-Internet-LAN oder einem Heim-WLAN-Netzwerk.
Eine Möglichkeit, ein Subnetz und seine Größe mit einer „Maske“ zu definieren. Eine kleinere Maske = mehr vom Subnetz nutzbare Adressbits und mehr IPs im Bereich. Die häufigsten:
192.0.2.1/32 (eine einzelne IP-Adresse, 192.0.2.1 ) Netzmaske = 255.255.255.255192.0.2.1/24 (255 IPs von 192.0.2.0 - 192.0.2.255 ) Netzmaske = 255.255.255.0192.0.2.1/16 (65.536 IPs von 192.0.0.0 - 192.0.255.255 ) Netzmaske = 255.255.0.0192.0.2.1/8 (16.777.216 IPs von 192.0.0.0 - 192.255.255.255 ) Netzmaske = 255.0.0.00.0.0.1/0 (4.294.967.296 IPs von 0.0.0.0 - 255.255.255.255 ) Netzmaske = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Für Leute, die gerade erst anfangen, mag 192.0.2.1/32 wie eine seltsame und verwirrende Art erscheinen, auf eine einzelne IP zu verweisen. Dieses Design ist jedoch schön, da es Peers ermöglicht, bei Bedarf mehrere IPs offenzulegen, ohne dass mehrere Notationen erforderlich sind. Denken Sie nur daran, dass überall dort, wo Sie etwas wie 192.0.2.3/32 sehen, in Wirklichkeit nur 192.0.2.3 gemeint ist.
Ein Subnetz mit privaten IPs, das von einem vor ihnen stehenden Router bereitgestellt wird, der Network Address Translation durchführt. Einzelne Knoten sind nicht öffentlich aus dem Internet zugänglich, stattdessen verfolgt der Router ausgehende Verbindungen und leitet Antworten an die richtige interne IP weiter (z. B. Standard-Büronetzwerke). , Heim-WLAN-Netzwerke, kostenlose öffentliche WLAN-Netzwerke usw.)
Die öffentlich zugängliche Adresse:Port für einen Knoten, z. B. 123.124.125.126:1234 oder some.domain.tld:1234 (muss über das öffentliche Internet zugänglich sein, kann im Allgemeinen keine private IP wie 192.0.2.1 oder 192.168.1.1 sein, es sei denn Andere Peers im selben Subnetz können über diese Adresse direkt darauf zugreifen.
Ein privater WireGuard-Schlüssel für einen einzelnen Knoten, generiert mit: wg genkey > example.key (verlässt niemals den Knoten, auf dem er generiert wurde)
Ein öffentlicher WireGuard-Schlüssel für einen einzelnen Knoten, generiert mit: wg pubkey < example.key > example.key.pub (gemeinsam mit anderen Peers)
Domain Name Server, der zum Auflösen von Hostnamen in IPs für VPN-Clients verwendet wird, anstatt zuzulassen, dass DNS-Anfragen außerhalb des VPN durchsickern und Datenverkehr offenlegen. Lecks können mit http://dnsleak.com getestet werden.
Öffentliche Relays sind ganz normale VPN-Peers, die als Zwischen-Relay-Server zwischen VPN-Clients hinter NATs fungieren können. Sie können den empfangenen VPN-Subnetzverkehr an den richtigen Peer auf Systemebene weiterleiten (WireGuard kümmert sich nicht darum, wie das passiert). , es wird vom Kernel net.ipv4.ip_forward = 1 und den iptables-Routing-Regeln gehandhabt.
Wenn alle Peers öffentlich zugänglich sind, müssen Sie sich keine Gedanken über eine Sonderbehandlung machen, um einen von ihnen zu einem Relay-Server zu machen. Dies ist nur erforderlich, wenn sich Peers hinter einem NAT verbinden.
Jeder Client muss lediglich die öffentlich zugänglichen Server/Peers in seiner Konfiguration definieren. Jeglicher Datenverkehr, der an andere Peers hinter NATs gebunden ist, wird an das Catchall-VPN-Subnetz (z. B. 192.0.2.1/24 ) in der AllowedIPs Route des öffentlichen Relays weitergeleitet und entsprechend weitergeleitet sobald es den Relay-Server erreicht.
Zusammenfassend: Es sollten nur direkte Verbindungen zwischen Clients konfiguriert werden. Alle Verbindungen, die zurückgesendet werden müssen, sollten nicht als Peers definiert werden, da sie zuerst zum Bounce-Server geleitet und von dort über das VPN zurück zum richtigen Client weitergeleitet werden sollten.
Komplexere Topologien sind definitiv realisierbar, aber dies sind die grundlegenden Routing-Methoden, die in typischen WireGuard-Setups verwendet werden:
Endpoint und Ports, damit WireGuard direkt eine Verbindung zum offenen Port herstellen und UDP-Pakete ohne Zwischensprünge weiterleiten kann.public-server2 herstellt), definieren Sie den öffentlich zugänglichen Knoten mit einem fest codierten Endpoint und den NAT-fähigen Knoten ohne. Die Verbindung wird vom NAT-Client -> öffentlichem Client geöffnet, dann wird der Datenverkehr direkt zwischen ihnen in beide Richtungen weitergeleitet, solange die Verbindung durch ausgehende PersistentKeepalive Pings vom NAT-Client aufrechterhalten wird.public-server1 öffnen und der Datenverkehr wird über den zwischengeschalteten Bounce-Server weitergeleitet, solange die Verbindungen bestehen werden am Leben gehalten. Spezifischere (normalerweise auch direktere) Routen, die von anderen Peers bereitgestellt werden, haben Vorrang, sofern verfügbar, andernfalls fällt der Datenverkehr auf die am wenigsten spezifische Route zurück und verwendet den Catchall 192.0.2.1/24 , um den Datenverkehr an den Bounce-Server weiterzuleiten, wo er weitergeleitet wird wiederum werden von der System-Routing-Tabelle des Relay-Servers ( net.ipv4.ip_forward = 1 ) zurück über das VPN an den spezifischen Peer weitergeleitet, der Routen für diesen Datenverkehr akzeptiert. WireGuard findet nicht automatisch die schnellste Route und versucht nicht, direkte Verbindungen zwischen Peers herzustellen, sofern dies nicht bereits definiert ist. Es geht lediglich von der spezifischsten Route in [Peers] zur am wenigsten spezifischen Route.
Sie können herausfinden, welche Routing-Methode WireGuard für eine bestimmte Adresse verwendet, indem Sie die Ping-Zeiten messen, um die eindeutige Länge jedes Hops zu ermitteln, und indem Sie die Ausgabe von Folgendem überprüfen:
wg show wg0WireGuard verwendet verschlüsselte UDP-Pakete für den gesamten Datenverkehr. Es gibt keine Garantien für die Zustellung oder Reihenfolge der Pakete, da diese über TCP-Verbindungen innerhalb des verschlüsselten Tunnels abgewickelt werden.
Weiterführende Literatur:
WireGuard verspricht eine höhere Leistung als die meisten anderen konkurrierenden VPN-Lösungen, obwohl die genauen Zahlen manchmal umstritten sind und davon abhängen können, ob für bestimmte kryptografische Verschlüsselungen eine Beschleunigung auf Hardwareebene verfügbar ist.
Die Leistungssteigerungen von WireGuard werden durch die Handhabung des Routings auf Kernel-Ebene und durch die Verwendung moderner Cipher-Suites erreicht, die auf allen Kernen ausgeführt werden, um den Datenverkehr zu verschlüsseln. WireGuard erhält außerdem einen erheblichen Vorteil durch die Verwendung von UDP ohne Liefer-/Bestellgarantien (im Vergleich zu VPNs, die über TCP laufen oder ihre eigenen garantierten Liefermechanismen implementieren).
Weiterführende Literatur:
WireGuard verwendet die folgenden Protokolle und Grundelemente, um den Datenverkehr zu sichern:
Die Kryptografie von WireGuard ist im Wesentlichen eine Instanziierung des Noise-Frameworks von Trevor Perrin. Es ist modern und wiederum einfach. Jede andere VPN-Option ist ein Chaos aus Verhandlungen, Handshaking und komplizierten Zustandsmaschinen. WireGuard ist wie das Signal/Axolotl von VPNs, außer dass es (in diesem Fall kryptografisch) viel einfacher und leichter zu verstehen ist als Double-Ratchet-Messaging-Protokolle. Es ist im Grunde das Qmail der VPN-Software. Und es sind ca. 4000 Codezeilen. Es ist um mehrere Größenordnungen kleiner als seine Konkurrenten.
https://news.ycombinator.com/item?id=14599834
Weiterführende Literatur:
Die Authentifizierung in beide Richtungen wird mit einem einfachen öffentlichen/privaten Schlüsselpaar für jeden Peer erreicht. Jeder Peer generiert diese Schlüssel während der Einrichtungsphase und teilt nur den öffentlichen Schlüssel mit anderen Peers.
Außer den öffentlichen/privaten Schlüsseln für jeden Knoten sind keine weiteren Zertifikate oder vorinstallierten Schlüssel erforderlich.
Die Generierung, Verteilung und Sperrung von Schlüsseln kann in größeren Bereitstellungen mithilfe eines separaten Dienstes wie Ansible oder Kubernetes Secrets erfolgen.
Einige Dienste, die bei der Schlüsselverteilung und -bereitstellung helfen:
Sie können Schlüssel auch aus einer Datei oder per Befehl einlesen, wenn Sie sie nicht in wg0.conf fest codieren möchten. Dies erleichtert die Verwaltung von Schlüsseln über Dienste von Drittanbietern erheblich:
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)Technisch gesehen können mehrere Server denselben privaten Schlüssel teilen, solange Clients nicht gleichzeitig mit zwei Servern mit demselben Schlüssel verbunden sind. Ein Beispiel für ein Szenario, in dem dies eine sinnvolle Einrichtung ist, ist die Verwendung von Round-Robin-DNS zum Lastausgleich von Verbindungen zwischen zwei Servern, die vorgeben, ein einzelner Server zu sein. In den meisten Fällen sollte jedoch jeder Peer über ein eigenes öffentliches/privates Schlüsselpaar verfügen, damit die Peers den Datenverkehr des anderen nicht lesen können und einzeln widerrufen werden können.
Überblick über den allgemeinen Ablauf:
apt install wireguard oder pkg/brew install wireguard-tools auf jedem Knotenwg genkey + wg pubkeywg0.conf WireGuard-Konfigurationsdatei auf dem Haupt-Relay-Server[Interface] Stellen Sie sicher, dass Sie einen CIDR-Bereich für das gesamte VPN-Subnetz angeben, wenn Sie die Adresse definieren, für die der Server Routen akzeptiert: Address = 192.0.2.1/24[Peer] Erstellen Sie einen Peer-Abschnitt für jeden Client, der dem VPN beitritt, und verwenden Sie dabei die entsprechenden öffentlichen Remote-Schlüsselwg0.conf[Interface] Stellen Sie sicher, dass Sie nur eine einzige IP für Client-Peers angeben, die keinen Datenverkehr weiterleiten Address = 192.0.2.3/32 .[Peer] Erstellen Sie einen Peer-Abschnitt für jeden öffentlichen Peer, der sich nicht hinter einem NAT befindet. Stellen Sie sicher, dass Sie einen CIDR-Bereich für das gesamte VPN-Subnetz angeben, wenn Sie den Remote-Peer definieren, der als Bounce-Server fungiert. AllowedIPs = 192.0.2.1/24 . Stellen Sie sicher, dass Sie individuelle IP-Adressen für Remote-Peers angeben, die keinen Datenverkehr weiterleiten und nur als einfache Clients fungieren. AllowedIPs = 192.0.2.3/32 .wg-quick up /full/path/to/wg0.confwg-quick up /full/path/to/wg0.confping 192.0.2.3 zuerst, ob eine direkte Route zu einem Peer mit AllowedIPs = 192.0.2.3/32 , und greift dann auf einen Relay-Server zurück, der IPs akzeptiert im gesamten Subnetz # install on Ubuntu
sudo add-apt-repository ppa:wireguard/wireguard
apt install wireguard
# install on macOS
brew install wireguard-tools
# install on FreeBSD
pkg install wireguard
# install on iOS/Android using Apple App Store/Google Play Store
# install on other systems using https://www.wireguard.com/install/#installation # to enable the kernel relaying/forwarding ability on bounce servers
echo " net.ipv4.ip_forward = 1 " | sudo tee -a /etc/sysctl.conf
echo " net.ipv4.conf.all.proxy_arp = 1 " | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
# to add iptables forwarding rules on bounce servers
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADEnano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems) # generate private key
wg genkey > example.key
# generate public key
wg pubkey < example.key > example.key.pubwg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Note: you must specify the absolute path to wg0.conf, relative paths won't work
# If wg0.conf is in /etc/wireguard you can use the simpler:
wg-quick up wg0 # start/stop VPN network interface
ip link set wg0 up
ip link set wg0 down
# register/unregister VPN network interface
ip link add dev wg0 type wireguard
ip link delete dev wg0
# register/unregister local VPN address
ip address add dev wg0 192.0.2.3/32
ip address delete dev wg0 192.0.2.3/32
# register/unregister VPN route
ip route add 192.0.2.3/32 dev wg0
ip route delete 192.0.2.3/32 dev wg0 # show system LAN and WAN network interfaces
ip address show
# or if ip is not available:
ifconfig
# show system VPN network interfaces
ip link show wg0
# or
ifconfig wg0
# show WireGuard VPN interfaces
wg show all
wg show wg0 # show public IP address
ip address show eth0
# or
ifconfig eth0
# or
dig -4 +short myip.opendns.com @resolver1.opendns.com
# show VPN IP address
ip address show wg0 # show WireGuard routing table and peer connections
wg show
wg show wg0 allowed-ips
# show system routing table
ip route show table main
ip route show table local
# show system route to specific address
ip route get 192.0.2.3So aktivieren Sie die zusätzliche Protokollierung:
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/controlSo folgen Sie Protokollen:
dmesg -wHSysteme mit modernem Kernel und Safe Boot erfordern möglicherweise die Deaktivierung der Secure Boot DKMS Signature Verification, um Zugriff auf Kernel-Protokolle zu ermöglichen.
mokutil --disable-verification
reboot # check that the main relay server is accessible directly via public internet
ping public-server1.example-vpn.dev
# check that the main relay server is available via VPN
ping 192.0.2.1
# check that public peers are available via VPN
ping 192.0.2.2
# check that remote NAT-ed peers are available via VPN
ping 192.0.2.3
# check that NAT-ed peers in your local LAN are available via VPN
ping 192.0.2.4 # install iperf using your preferred package manager
apt/brew/pkg/opkg install iperf
# check bandwidth over public internet to relay server
iperf -s # on public relay server
iperf -c public-server1.example-vpn.dev # on local client
# check bandwidth over VPN to relay server
iperf -s # on public relay server
iperf -c 192.0.2.1 # on local client
# check bandwidth over VPN to remote public peer
iperf -s # on remote public peer
iperf -c 192.0.2.2 # on local client
# check bandwidth over VPN to remote NAT-ed peer
iperf -s # on remote NAT-ed peer
iperf -c 192.0.2.3 # on local client
# check bandwidth over VPN to local NAT-ed peer (on same LAN)
iperf -s # on local NAT-ed peer
iperf -c 192.0.2.4 # on local client Suchen Sie mithilfe von http://dnsleak.com nach DNS-Lecks oder überprüfen Sie den Resolver bei einer Suche:
dig example.com A Die WireGuard-Konfiguration erfolgt in INI-Syntax und wird in einer Datei definiert, die normalerweise wg0.conf heißt. Es kann an einer beliebigen Stelle im System platziert werden, wird jedoch häufig in /etc/wireguard/wg0.conf abgelegt.
Der Konfigurationspfad wird als Argument angegeben, wenn ein wg-quick -Befehl ausgeführt wird, z. B.:
wg-quick up /etc/wireguard/wg0.conf (immer den vollständigen, absoluten Pfad angeben)
Der Name der Konfigurationsdatei muss das Format ${name of the new WireGuard interface}.conf haben. WireGuard-Schnittstellennamen werden normalerweise mit dem Präfix wg versehen und beginnend mit 0 nummeriert. Sie können jedoch jeden Namen verwenden, der mit dem regulären Ausdruck ^[a-zA-Z0-9_=+.-]{1,15}$ übereinstimmt.
Konfigurationsdateien können sich für die Verwendung der begrenzten wg -Konfigurationsoptionen oder der erweiterten wg-quick -Optionen entscheiden, je nachdem, welcher Befehl zum Starten von WireGuard bevorzugt wird. In diesen Dokumenten wird empfohlen, bei wg-quick zu bleiben, da es eine leistungsfähigere und benutzerfreundlichere Konfigurationserfahrung bietet.
Zur Definition springen:
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶ ListenPort = 51820
¶ PrivateKey = localPrivateKeyAbcAbcAbc=
¶ DNS = 1.1.1.1,8.8.8.8
¶ Table = 12345
¶ MTU = 1500
¶ PreUp = /bin/example arg1 arg2 %i
¶ PostUp = /bin/example arg1 arg2 %i
¶ PreDown = /bin/example arg1 arg2 %i
¶ PostDown = /bin/example arg1 arg2 %i
¶ [Peer]
¶ # Name = node2-node.example.tld
¶ AllowedIPs = 192.0.2.1/24
¶ Endpoint = node1.example.tld:51820
¶ PublicKey = remotePublicKeyAbcAbcAbc=
¶ PersistentKeepalive = 25
[Interface]Definiert die VPN-Einstellungen für den lokalen Knoten.
Beispiele
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev> [Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1# NameDies ist lediglich ein Standardkommentar in der INI-Syntax, der dabei hilft, den Überblick darüber zu behalten, welcher Konfigurationsabschnitt zu welchem Knoten gehört. Er wird von WireGuard vollständig ignoriert und hat keine Auswirkung auf das VPN-Verhalten.
HINWEIS: Alle Kommentare, einschließlich # Name , werden durch bestimmte Vorgänge und Anwendungen aus den .conf-Dateien entfernt. Wenn Sie Peers identifizieren müssen, sollten Sie die Verwendung eines Wireguard-Vanity-Schlüsselgenerators wie „wireguard-vanity-keygen“ oder „wireguard-vanity-address“ in Betracht ziehen, der es Ihnen ermöglicht, den Hostnamen in den öffentlichen Schlüssel des Hosts aufzunehmen. Die Schlüsselgenerierung kann Minuten (4 Zeichen), Stunden (5 Zeichen) oder länger dauern. Erwägen Sie daher die Verwendung einer Abkürzung für Hosts mit längeren Namen.
AddressDefiniert, für welchen Adressbereich der lokale Knoten den Datenverkehr weiterleiten soll. Je nachdem, ob es sich bei dem Knoten um einen einfachen Client handelt, der dem VPN-Subnetz beitritt, oder um einen Bounce-Server, der Datenverkehr zwischen mehreren Clients weiterleitet, kann dies auf eine einzelne IP des Knotens selbst (angegeben mit CIDR-Notation) eingestellt werden, z. B. 192.0.2.3/32 ) oder einen Bereich von IPv4/IPv6-Subnetzen, für die der Knoten Datenverkehr weiterleiten kann.
Beispiele
Ein Knoten ist ein Client, der den Datenverkehr nur für sich selbst weiterleitet
Address = 192.0.2.3/32
Node ist ein öffentlicher Bounce-Server, der Datenverkehr an andere Peers weiterleiten kann
Wenn der Knoten als öffentlicher Bounce-Server fungiert, sollte er das gesamte Subnetz festlegen, über das er Datenverkehr weiterleiten kann, und nicht nur eine einzelne IP-Adresse für sich selbst.
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPortWenn der Knoten als öffentlicher Bounce-Server fungiert, sollte er einen Port fest codieren, der auf eingehende VPN-Verbindungen aus dem öffentlichen Internet wartet. Clients, die nicht als Relays fungieren, sollten diesen Wert nicht festlegen.
Beispiele
ListenPort = 51820ListenPort = 7000PrivateKeyDies ist der private Schlüssel für den lokalen Knoten, der niemals mit anderen Servern geteilt wird. Alle Knoten müssen über einen privaten Schlüsselsatz verfügen, unabhängig davon, ob es sich um öffentliche Bounce-Server handelt, die den Datenverkehr weiterleiten, oder um einfache Clients, die dem VPN beitreten.
Dieser Schlüssel kann mit wg genkey > example.key generiert werden
Beispiele
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSDie DNS-Server, die VPN-Clients über DHCP bekannt geben. Die meisten Clients verwenden diesen Server für DNS-Anfragen über das VPN, aber Clients können diesen Wert auch lokal auf ihren Knoten überschreiben
Beispiele
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8TableDefiniert optional, welche Routing-Tabelle für die WireGuard-Routen verwendet werden soll, eine Konfiguration ist für die meisten Setups nicht erforderlich.
Es gibt zwei Sonderwerte: „off“ deaktiviert die Erstellung von Routen insgesamt und „auto“ (Standard) fügt Routen zur Standardtabelle hinzu und ermöglicht eine spezielle Behandlung von Standardrouten.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Beispiele
Table = 1234MTUDefiniert optional die maximale Übertragungseinheit (MTU, auch Paket-/Framegröße genannt), die beim Herstellen einer Verbindung zum Peer verwendet werden soll. Für die meisten Setups ist keine Konfiguration erforderlich.
Die MTU wird automatisch anhand der Endpunktadressen oder der Standardroute des Systems ermittelt, was normalerweise eine vernünftige Wahl ist.
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
Beispiele
MTU = 1500PreUpFühren Sie optional einen Befehl aus, bevor die Schnittstelle aufgerufen wird. Diese Option kann mehrmals angegeben werden, wobei die Befehle in der Reihenfolge ausgeführt werden, in der sie in der Datei erscheinen.
Beispiele
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUpFühren Sie optional einen Befehl aus, nachdem die Schnittstelle aufgerufen wurde. Diese Option kann wie bei PreUp mehrfach erscheinen
Beispiele
Liest einen Konfigurationswert aus einer Datei oder der Ausgabe eines Befehls ein
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
Protokollieren Sie eine Zeile in einer Datei
PostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
Treffen Sie einen Webhook auf einem anderen Server
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
Fügen Sie der System-Routing-Tabelle eine Route hinzu
PostUp = ip rule add ipproto tcp dport 22 table 1234
Fügen Sie eine iptables-Regel hinzu, um die Paketweiterleitung auf der WireGuard-Schnittstelle zu aktivieren
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Erzwingen Sie, dass WireGuard die IP-Adresse für die Peer-Domäne neu auflöst
PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDownFühren Sie optional einen Befehl aus, bevor die Schnittstelle heruntergefahren wird. Diese Option kann wie bei PreUp mehrfach erscheinen
Beispiele
Protokollieren Sie eine Zeile in einer Datei
PostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
Treffen Sie einen Webhook auf einem anderen Server
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDownFühren Sie optional einen Befehl aus, nachdem die Schnittstelle heruntergefahren wurde. Diese Option kann wie bei PreUp mehrfach erscheinen
Beispiele
Protokollieren Sie eine Zeile in einer Datei
PostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
Treffen Sie einen Webhook auf einem anderen Server
PostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
Entfernen Sie die iptables-Regel, die Pakete auf der WireGuard-Schnittstelle weiterleitet
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]Definiert die VPN-Einstellungen für einen Remote-Peer, der Datenverkehr für eine oder mehrere Adressen (sich selbst und/oder andere Peers) weiterleiten kann. Peers können entweder ein öffentlicher Bounce-Server sein, der den Datenverkehr an andere Peers weiterleitet, oder ein direkt über LAN/Internet erreichbarer Client, der sich nicht hinter einem NAT befindet und den Datenverkehr nur für sich selbst weiterleitet.
Alle Clients müssen als Peers auf dem öffentlichen Bounce-Server definiert sein. Einfache Clients, die den Datenverkehr nur für sich selbst weiterleiten, müssen lediglich Peers für das öffentliche Relay und alle anderen direkt zugänglichen Knoten definieren. Knoten, die sich hinter separaten NATs befinden, sollten nicht als Peers außerhalb der öffentlichen Serverkonfiguration definiert werden, da keine direkte Route zwischen separaten NATs verfügbar ist. Stattdessen sollten Knoten hinter NATs nur die öffentlichen Relay-Server und andere öffentliche Clients als ihre Peers definieren und AllowedIPs = 192.0.2.1/24 auf dem öffentlichen Server angeben, der Routen akzeptiert und Datenverkehr für das VPN-Subnetz an das Remote-NAT-ed weiterleitet Gleichaltrige.
Zusammenfassend müssen alle Knoten auf dem Haupt-Bounce-Server definiert werden. Auf Client-Servern sollten nur Peers, die direkt von einem Knoten aus erreichbar sind, als Peers dieses Knotens definiert werden. Alle Peers, die von einem Bounce-Server weitergeleitet werden müssen, sollten weggelassen werden und werden von der Catchall-Route des Relay-Servers verarbeitet.
In der in den folgenden Dokumenten beschriebenen Konfiguration fungiert ein einzelner Server public-server1 als Relay-Bounce-Server für eine Mischung aus öffentlich zugänglichen und NAT-basierten Clients, und Peers werden auf jedem Knoten entsprechend konfiguriert:
in public-server1 wg0.conf (Bounce-Server)
[peer] -Liste: public-server2 , home-server , laptop , phone
in public-server2 wg0.conf (einfacher öffentlicher Client)
[peer] -Liste: public-server1
im home-server wg0.conf (einfacher Client hinter NAT)
[peer] -Liste: public-server1 , public-server2
in laptop wg0.conf (einfacher Client hinter NAT)
[peer] -Liste: public-server1 , public-server2
in phone wg0.conf (einfacher Client hinter NAT)
[peer] -Liste: public-server1 , public-server2
Beispiele
[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32 [Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32 [Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# routes traffic to itself and entire subnet of peers as bounce server
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25# NameDies ist lediglich ein Standardkommentar in der INI-Syntax, der dabei hilft, den Überblick darüber zu behalten, welcher Konfigurationsabschnitt zu welchem Knoten gehört. Er wird von WireGuard vollständig ignoriert und hat keine Auswirkung auf das VPN-Verhalten.
Endpoint Definiert die öffentlich zugängliche Adresse für einen Remote-Peer. Dies sollte für Peers hinter einem NAT oder für Peers, die kein stabiles, öffentlich zugängliches IP:PORT-Paar haben, weggelassen werden. Normalerweise muss dies nur auf dem Haupt-Bounce-Server definiert werden, kann aber auch auf anderen öffentlichen Knoten mit stabilen IPs wie public-server2 in der Beispielkonfiguration unten definiert werden.
Beispiele
Endpoint = 123.124.125.126:51820 (IPv6 wird auch unterstützt)Endpoint = public-server1.example-vpn.tld:51820AllowedIPs Dadurch werden die IP-Bereiche definiert, für die ein Peer den Datenverkehr weiterleitet. Bei einfachen Clients ist dies normalerweise eine einzelne Adresse (die VPN-Adresse des einfachen Clients selbst). Bei Bounce-Servern ist dies ein Bereich der IPs oder Subnetze, für die der Relay-Server Datenverkehr weiterleiten kann. Mehrere IPs und Subnetze können mithilfe der durch Kommas getrennten IPv4- oder IPv6-CIDR-Notation angegeben werden (von einer einzelnen /32- oder /128-Adresse bis hin zu 0.0.0.0/0 und ::/0 um eine Standardroute zum Senden aller anzugeben Internet- und VPN-Verkehr über diesen Peer). Diese Option kann mehrfach angegeben werden.
Bei der Entscheidung, wie ein Paket weitergeleitet werden soll, wählt das System zuerst die spezifischste Route und greift dann auf breitere Routen zurück. Für ein Paket, das an 192.0.2.3 gerichtet ist, würde das System also zunächst nach einem Peer suchen, der speziell 192.0.2.3/32 annonciert, und dann auf einen Peer zurückgreifen, 192.0.2.1/24 oder einen größeren Bereich wie 0.0.0.0/0 als annonciert ein letzter Ausweg.
Beispiele
Peer ist ein einfacher Client, der nur Datenverkehr von/zu sich selbst akzeptiert
AllowedIPs = 192.0.2.3/32
Peer ist ein Relay-Server, der VPN-Verkehr an alle anderen Peers weiterleiten kann
AllowedIPs = 192.0.2.1/24
Peer ist ein Relay-Server, der den gesamten Internet- und VPN-Verkehr (wie ein Proxy) weiterleitet, einschließlich IPv6
AllowedIPs = 0.0.0.0/0,::/0
Peer ist ein Relay-Server, der Routen an sich selbst und nur an einen anderen Peer weiterleitet
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
Peer ist ein Relay-Server, der Routen an sich selbst und alle Knoten in seinem lokalen LAN weiterleitet
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKeyDies ist der öffentliche Schlüssel für den Remote-Knoten, der von allen Peers gemeinsam genutzt werden kann. Alle Knoten müssen über einen öffentlichen Schlüsselsatz verfügen, unabhängig davon, ob es sich um öffentliche Bounce-Server handelt, die den Datenverkehr weiterleiten, oder um einfache Clients, die dem VPN beitreten.
Dieser Schlüssel kann mit wg pubkey < example.key > example.key.pub generiert werden. (siehe oben für die Generierung des privaten Schlüssels example.key )
Beispiele
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepaliveWenn die Verbindung von einem NAT-fähigen Peer zu einem öffentlichen Peer geht, muss der Knoten hinter dem NAT regelmäßig einen ausgehenden Ping senden, um die bidirektionale Verbindung in der Verbindungstabelle des NAT-Routers aufrechtzuerhalten.
Beispiele
vom lokalen öffentlichen Knoten zum entfernten öffentlichen Knoten
Dieser Wert sollte undefiniert bleiben, da dauerhafte Pings nicht erforderlich sind.
vom lokalen öffentlichen Knoten zum Remote-NAT-Knoten
Dieser Wert sollte undefiniert bleiben, da es in der Verantwortung des Clients liegt, die Verbindung aufrechtzuerhalten, da der Server bei einer Zeitüberschreitung eine unterbrochene Verbindung zum Client nicht wieder öffnen kann.
lokaler NAT-ed-Knoten zum entfernten öffentlichen Knoten
PersistentKeepalive = 25 Dadurch wird alle 25 Sekunden ein Ping gesendet, um die Verbindung in der Verbindungstabelle des lokalen NAT-Routers offen zu halten.
Die Beispiele in diesen Dokumenten verwenden in erster Linie IPv4, aber Drahtguard unterstützt nativ IPv6 -CIDR -Notation und adressiert überall, wo es IPv4 unterstützt. Fügen Sie sie einfach so hinzu, wie Sie es in jedem anderen Subnetzbereich oder einer anderen Adresse tun würden.
Beispiel
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0 Wenn Sie den gesamten Internetverkehr über das VPN weiterleiten und nicht nur als Server-zu-Server-Subnetz verwenden möchten, können Sie der Definition des AllowedIPs -Peers, die Sie putzen möchten, 0.0.0.0/0, ::/0 hinzufügen Ihr Verkehr durch.
Stellen Sie sicher, dass Sie auch einen IPv6 -Catchall angeben, auch wenn Sie nur den IPv4 -Datenverkehr weiterleiten, um zu vermeiden, dass IPv6 -Pakete außerhalb des VPN ausgelöst werden, siehe:
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_use_wireguard_to/
Beispiel
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>
[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0Drahtguard kann manchmal nativ Verbindungen zwischen zwei Clients hinter Nats herstellen, ohne dass ein PR -Relay -Server erforderlich ist, aber in den meisten Fällen ist dies nicht möglich. Nat-to-Nat-Verbindungen sind nur möglich, wenn mindestens ein Host eine stabile, öffentlich zugängliche IP-Adresse hat: Portpaar, das im Voraus festgesagt werden kann, unabhängig davon Ein nicht randomisierter NAT-Port, der von ausgehenden Paketen eröffnet wird, funktioniert alles, solange alle Kollegen ihn vorher kommunizieren können, und es ändert sich nicht, sobald die Verbindung eingeleitet wird.
Ein bekannter Port und eine bekannte Adresse müssen im Voraus konfiguriert werden, da Drahtguard keine Signalschicht oder öffentliche Stun -Server verfügt, mit denen dynamisch nach anderen Hosts gesucht werden kann. WEBRTC ist ein Beispiel für ein Protokoll, das eine Verbindung zwischen zwei NATs dynamisch konfigurieren kann. Dies geschieht jedoch, indem ein Signalisierungsserver außerhalb des Bandes verwendet wird, um die IP: Port-Kombination jedes Hosts zu erkennen. Drahtguard hat dies nicht, daher funktioniert es nur mit einem hartgesottenen Endpoint + ListenPort (und PersistentKeepalive sodass es nach der Inaktivität nicht sinkt).
Erfahren Sie mehr aus Tailscales Bibel von Nat Traversal: https://tailscale.com/blog/how-nat-traversal-works/
Endpoint definiert haben. Wenn sie beide ohne stabile IP -Adressen hinter NATs sind, müssen Sie dynamische DNs oder eine andere Lösung verwenden, um eine stabile, öffentlich zugängliche Domäne/IP für mindestens einen Peer zu habenListenPort definiert sein, und der Nat -Router darf die UDP ListenPort -Randomisierung nicht ausführen Nat auf dem ausgehenden PaketPersistentKeepalive ermöglicht werden, damit sie kontinuierlich ausgehende Pings senden, um die Verbindungen in der Routing -Tabelle ihrer NAT festzuhalten Dieser Prozess des Sendens eines anfänglichen Pakets, das abgelehnt wird, und dann wird die Tatsache verwendet, dass der Router jetzt eine Weiterleitungsregel erstellt hat, um Antworten zu akzeptieren, wird als "UDP Hole-Punching" bezeichnet.
Wenn Sie ein UDP -Paket aussenden, erstellt der Router (normalerweise) eine temporäre Regel, die Ihre Quelladresse und Ihren Port an die Zieladresse und den Port zuordnet, und umgekehrt. UDP -Pakete, die von der Zieladresse zurückkehren, und Port (und keines anderen) werden an die ursprüngliche Quelladresse und den Port (und kein anderes) übergeben. So funktionieren die meisten UDP -Anwendungen hinter NATS (z. B. BitTorrent, Skype usw.). Diese Regel wird nach einiger Minuten der Inaktivität ausgerichtet, sodass der Kunde hinter der NAT regelmäßige ausgehende Pakete senden muss, um sie offen zu halten (siehe PersistentKeepalive ).
Wenn beide Endpunkte hinter NATs oder Firewalls liegen, müssen beide Endpunkte ungefähr zur gleichen Zeit auf jeden anderen an andere schicken. Dies bedeutet, dass beide Seiten die öffentlichen IP- und Portnummern eines anderen im Voraus wissen müssen. Im Fall von WireGuard wird dies durch hart codierende vordefinierte Ports für beide Seiten in wg0.conf erreicht.
Ab 2019 sind viele der alten Loch-Punching-Methoden, die früher funktionierten, nicht mehr wirksam. Ein Beispiel war eine neuartige Methode, die von Pwnat Pionierarbeit leitete, die eine ICMP -Zeit vor dem NAT übertraf, um ein Paket wieder an einen Peer zu bringen, wodurch ein eigener Quellanschluss verläuft. Hardcoding UDP-Ports und öffentliche IPs für beide Seiten einer NAT-to-NAT-Verbindung (wie oben beschrieben) funktioniert immer noch auf einem kleinen Prozentsatz der Netzwerke. Je "unternehmerischer" ein Netzwerk ist, desto weniger wahrscheinlich können Sie öffentliche UDP-Anschlüsse lohen (kommerzielle öffentliche Wi-Fi- und Zelldaten-NATs funktionieren zum Beispiel häufig nicht).
NAT-to-NAT-Verbindungen sind nicht möglich, wenn alle Endpunkte hinter NATs mit strikter UDP-Quellanschluss-Randomisierung (z. B. die meisten zellulären Datennetzwerke) stehen. Da keine Seite in der Lage ist, einen ListenPort zu harten und zu garantieren, dass ihr NAT nach dem ausgehenden Ping den Verkehr auf diesem Port akzeptiert, können Sie einen Port für den anfänglichen Lochpolech zwischen Kollegen nicht koordinieren, und Verbindungen werden fehlschlagen. Aus diesem Grund können Sie im Allgemeinen keine Telefon-zu-Telefon-Verbindungen in LTE/3G-Netzwerken herstellen, aber möglicherweise können Sie Telefon-zu-Office- oder Telefon-zu-zu-zu-zu-Zuhause durchführen, wo das Büro oder das Haus über eine stabile öffentliche IP verfügt und nicht Die Quellport -Randomisierung.
Nat-to-Nat-Verbindungen von hinten mit strikter Quell-Port-Randomisierung ist möglich. Sie benötigen nur einen Signalisierungsserver, um jeder Seite das IP: Port-Tuple des anderen mitzuteilen. Hier sind einige Implementierungen, die dies mit WireGuard erreichen:
Viele Benutzer berichten, dass wir Drahtguard neu starten müssen, wenn sich eine dynamische IP ändert, da sie nur Hostnamen beim Start auflöst. Um Drahtguard zu zwingen, dynamische DNS- Endpoint -Hostnamen öfter neu aufzulösen, möchten Sie möglicherweise einen PostUp Haken verwenden, um WireGuard alle paar Minuten oder Stunden neu zu starten.
Sie können sehen, ob ein Loch -Punching -Setup durch die Verwendung von NETCAT auf dem Client und Server möglich ist, um zu sehen, welche Ports und Verbindungsauftrag funktionieren, um eine bidirektionale Verbindung geöffnet zu haben: Führen Sie nc -v -u -p 51820 <address of peer2> 51820 () aus. Auf Peer1) und nc -v -u -l 0.0.0.0 51820 (auf Peer2) geben Sie dann beide Fenster ein, um festzustellen, ob Sie bidirektional erhalten können Verkehr gehen. Wenn es nicht funktioniert, unabhängig davon, welches Peer das erste Paket sendet, kann Wdr -Guard nicht in der Lage sein, ohne PR -Relay -Server zwischen den Gleichaltrigen zu arbeiten.
NAT-to-NAT-Verbindungen sind oft instabiler und haben andere Einschränkungen, weshalb noch ein Fallback-PR-Server mit einem Fallback empfohlen wird.
Beispiel
Peer1:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25Peer2:
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25 Hinweis: In diesem Abschnitt geht es um dynamische Peer -IPs innerhalb des VPN -Subnetzes, nicht um dynamische öffentliche Endpoint .
Die dynamische Zuweisung von Peer-IPs (anstatt nur feste Kollegen) wird entwickelt, die WIP-Implementierung ist hier verfügbar: https://github.com/wireguard/wg-dynamic
Sie können auch selbst ein dynamisches Zuordnungssystem erstellen, indem Sie zur PostUp in IP -Werten von Dateien lesen (siehe unten).
Beispiel
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) https://git.zx2c4.com/wirguard-go/about/
Eine konforme Userland WireGuard -Implementierung in Go.
https://git.zx2c4.com/wirguard-rs/about/
Eine unvollständige, unsichere Userspace -Implementierung von WireGuard in Rost (nicht bereit für die Öffentlichkeit).
https://git.zx2c4.com/wirguard-hs/about/
Eine unvollständige, unsichere Userspace -Implementierung von WireGuard in Haskell (nicht bereit für die Öffentlichkeit).
https://github.com/cloudflare/boringtun
Eine nicht konforme, unabhängige Wireguard-Implementierung in Rust (eine separate Gabel von CloudFlare). Siehe https://blog.cloudflare.com/bororingtun-userspace-reguard-rust/
Plattformspezifische Drahtguard-Apps
https://git.zx2c4.com/wirguard-ios/about/
https://git.zx2c4.com/wirguard-android/about/
https://git.zx2c4.com/wirguard-windows/about/
Alle UserSpace-Implementierungen sind langsamer als die native C-Version, die im Kernel-Land ausgeführt wird, aber andere Vorteile bietet, indem sie in Userland ausgeführt werden (z. B. einfachere Containerisierung, Kompatibilität usw.).
Dies sind einige GUI- und CLI -Tools, die Drahtguard einwickeln, um Konfiguration, Bereitstellung, Schlüsselmanagement und Verbindung zu unterstützen.
Gutschrift für diese Verknüpfungen geht an: https://www.ericlight.com/new-things-i-didnt-know-about-reguard.html
WireGuard wird einen Peer ignorieren, dessen öffentlicher Schlüssel mit dem privaten Schlüssel der Schnittstelle übereinstimmt. Sie können also eine einzige Liste von Kollegen überall verteilen und nur die [Interface] auf jedem Server separat definieren.
Siehe: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003703.html
Sie können dies mit wg addconf wie folgt kombinieren:
Jeder Peer hat eine eigene /etc/wireguard/wg0.conf -Datei, die nur den Abschnitt [Interface] enthält.
Jeder Peer verfügt auch über eine gemeinsame Datei /etc/wireguard/peers.conf , die alle Kollegen enthält.
Die Datei wg0.conf hat auch einen PostUp -Hook: PostUp = wg addconf /etc/wireguard/peers.conf .
Es liegt an Ihnen zu entscheiden, wie Sie die peers.conf teilen möchten, sei es über eine ordnungsgemäße Orchestrierungsplattform, etwas mehr Fußgänger wie Dropbox oder etwas Wildes wie Ceph. Ich weiß nicht, aber es ist ziemlich großartig, dass man einen Peer -Abschnitt nur wild herumschleudert, ohne sich Sorgen zu machen, ob er der Schnittstelle ist.
Sie können Konfigurationswerte aus beliebigen Befehlen oder durch Lesen von Werten aus Dateien festlegen. Dies erleichtert das Schlüsselmanagement und die Bereitstellung viel einfacher, da Sie in Tasten zur Laufzeit von einem Drittanbieterdienst wie Kubernetes Secrets oder AWS -KMS lesen können.
Siehe: https://lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html
Beispiel
Sie können in einer Datei als PrivateKey lesen, indem Sie so etwas wie folgt:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
WireGuard kann in Docker mit unterschiedlichem Maße leichter ausgeführt werden. Im einfachsten Fall --privileged und --cap-add=all Argumente können den Docker-Befehlen hinzugefügt werden, um das Laden des Kernelmoduls zu aktivieren.
Setups können etwas komplex werden und sind stark davon abhängig, was Sie erreichen möchten. Sie können Drahtguard selbst in einem Container ausgeführt und eine Netzwerkschnittstelle dem Host ausgesetzt oder Drahtguard auf dem Host ausgeführt werden, in dem eine Schnittstelle zu bestimmten Containern ausgesetzt wird.
Ein Beispiel eines Docker -Container vpn_test -Beispiels finden Sie unten über einen Drahtguard -Relay -Server.
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
ports :
- 51820:51820/udp
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro wg0.conf :
[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/ UVb7BRqCwad2YMReQgH5tlxz8YmI =
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/ 2Gg =
AllowedIPs = 192.0.2.2/32 In diesem Beispiel wird der gesamte Verkehr aus dem speedtest -Behälter durch das Drahtguard VPN durchlaufen. Um nur etwas Verkehr zu vermitteln, ersetzen Sie 0.0.0.0/0 in wg0.conf unten durch die Subnetzbereiche, die Sie über das VPN weiterleiten möchten.
docker-compose.yml :
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
vpn_test :
image : curlimages/curl
entrypoint : curl -s http://whatismyip.akamai.com/
network_mode : ' service:wireguard ' wg0.conf :
[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/ sgk8 =
DNS = 1.1.1.1,8.8.8.8
[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+ 2um0c0B1s =
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21Weitere Informationen finden Sie im weiteren Abschnitt "Weitere Lektüren: Docker" unten.
Weitere detailliertere Anweisungen finden Sie in der obigen QuickStart -Handbuch und der API -Referenz. Sie können auch das vollständige Beispiel-Setup hier herunterladen: https://github.com/pirate/wireguard-example.
Schlagen Sie Änderungen vor: https://github.com/pirate/wireguard-docs/issues
