WireGuard ist kein verbindlicher Leitfaden: Detaillierte Erklärung zur Installation und Konfiguration von WireGuard

1. Schnellstart

Wenn Sie Ihre Arbeit gut machen möchten, müssen Sie zuerst Ihre Werkzeuge schärfen! WireGuard Der allgemeine Ablauf ist wie folgt:

Vorbereitung

Aktuelle Kernel-Version anzeigen

uname -r #4.18.0-348.2.1.el8_5.x86_64 uname -a #Linux mir4 4.18.0-348.2.1.el8_5.x86_64 #1 SMP Di., 16. Nov. 14:42:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux cat /etc/redhat-release #CentOS Linux-Version 8.5.2111

Aktualisieren Sie den Systemkernel

dnf -y aktualisieren

Installieren Sie das EPEL-Repository auf CentOS 8.x

EPEL steht für „Extra Packages for Enterprise Linux“ und ist ein kostenloses Open-Source-Repository mit zusätzlichen Paketen für CentOS- und RHEL-Server. Wie der Name schon sagt, bietet das EPEL-Repository zusätzliche Pakete, die in den Standard-Paket-Repositorys von CentOS 8 und RHEL 8 nicht verfügbar sind.

Offizielle Epel-Website:https://fedoraproject.org/wiki/EPEL/zh-cn

dnf search epel #epel-next-release.noarch : Zusätzliche Pakete für Enterprise Linux Next Repository-Konfiguration #epel-release.noarch : Zusätzliche Pakete für Enterprise Linux Repository-Konfiguration #Überprüfen Sie die Epel-Release-Version im Systemsoftware-Repository dnf info epel-release #Installieren Sie die Epel-Quelle aus dem Systemsoftware-Repository dnf install epel-release #Installieren Sie die Epel-Quelle von der Website über die URL dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm #Aktivieren Sie das PowerTools-Repository, da EPEL-Pakete von Paketen in diesen Repositorys abhängen können dnf config-manager --set-enabled powertools #Testen Sie nach erfolgreicher Installation die Anzahl der Pakete im Repository sudo dnf --disablerepo="*" --enablerepo="epel" Liste verfügbar | wc -l

Installieren Sie das ELRepo-Repository auf CentOS 8.x

Das ELRepo-Repository ist ein Community-basiertes Enterprise-Linux-Repository, das Unterstützung für RedHat Enterprise (RHEL) und andere RHEL-basierte Linux-Distributionen (CentOS, Scientific, Fedora usw.) bietet.
ELRepo konzentriert sich auf hardwarebezogene Softwarepakete, einschließlich Dateisystemtreibern, Grafiktreibern, Netzwerktreibern, Soundkartentreibern und Kameratreibern.

#Importieren Sie den öffentlichen Schlüssel des ELRepo-Repositoryrpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org #Installieren Sie die Yum-Quelle des ELRepo-Repositorydnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm #Überprüfen Sie die Kernel-Versiondnf --disablerepo="*" --enablerepo="elrepo-kernel" Liste verfügbar

Die Eple- und ELRepo-Repositorys müssen auf dem Server installiert werden, bevor Wireguard installiert werden kann.

# Nachdem die Softwarequelle installiert ist, leeren Sie den Cache dnf clean all # Erstellen Sie den Cache des Repositorys neu yum makecache reboot

Installieren

Offizielle Installationsreferenz:https://www.wireguard.com/install/

Im Folgenden finden Sie Installationsmethoden für verschiedene Betriebssysteme, darunter Centos8, Centos7, Ubuntu und MacOS.

#CentOS8 dnf install elrepo-release epel-release dnf config-manager --set-enabled powertools dnf copr enable jdoss/wireguard dnf install wireguard-dkms wireguard-tools #CentOS7 yum install epel-release https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm yum install yum-plugin-elrepo yum install kmod-wireguard wireguard-tools #If Sie einen nicht standardmäßigen Kernel verwenden, müssen Sie das DKMS-Paket installieren yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm curl -o /etc/yum.repos.d/jdoss-wireguard-epel-7.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo yum installiere wireguard-dkms wireguard-tools #Ubuntu≥18.04 apt installiere wireguard #Ubuntu≤16.04 add-apt-repository ppa:wireguard/wireguard apt-get update apt-get installiere wireguard #MacOS brew installiere wireguard-tools

Downloadadresse für den Windows-Client:

Für Android und iOS gibt es den entsprechenden Client im App Store zum Download:

https://www.wireguard.com/install/#installation

Aktivieren Sie die IP-Adressweiterleitung auf dem Relay-Server:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.proxy_arp = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf

Fügen Sie iptables-Regeln hinzu, um die NAT-Übersetzung auf diesem Computer zuzulassen:

iptables -A INPUT -m conntrack --ctstate RELATED, ETABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED, ETABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE

Sie müssen eth0 in den Namen der Netzwerkkartenschnittstelle ändern, die Sie tatsächlich verwenden.

Schreiben von Konfigurationsdateien

Die Konfigurationsdatei kann in einem beliebigen Pfad abgelegt werden, muss aber durch einen absoluten Pfad referenziert werden. Der Standardpfad ist /etc/wireguard/wg0.conf.

# Erstellen Sie eine Konfigurationsdatei vi /etc/wireguard/wg0.conf

Schlüssel generieren

Generieren Sie einen privaten Schlüssel

wg genkey > beispiel.schlüssel

Öffentlichen Schlüssel generieren

wg pubkey < beispiel.schlüssel > beispiel.schlüssel.pub

Starten und Stoppen

$ wg-quick up /vollständiger/Pfad/zu/wg0.conf
$ wg-quick down /vollständiger/Pfad/zu/wg0.conf

# VPN-Netzwerkschnittstelle starten/stoppen
$ IP-Link-Set wg0 aktiv
$ IP-Link-Set wg0 down

# VPN-Netzwerkschnittstelle registrieren/abmelden
$ IP-Link hinzufügen dev wg0 Typ Wireguard
$ IP-Link löschen dev wg0

# Lokale VPN-Adresse registrieren/abmelden
$ IP-Adresse hinzufügen dev wg0 192.0.2.3/32
$ IP-Adresse löschen dev wg0 192.0.2.3/32

# VPN-Routen hinzufügen/löschen
$ IP-Route hinzufügen 192.0.2.3/32 dev wg0
$ IP-Route löschen 192.0.2.3/32 dev wg0

Informationen anzeigen

Schnittstelle:

# Informationen zur System-VPN-Schnittstelle anzeigen
$ IP-Link-Show wg0

# VPN-Schnittstellendetails anzeigen
$ wg alle anzeigen
$ wg show wg0

Adresse:

# VPN-Schnittstellenadresse anzeigen
$ IP-Adresse zeigen wg0

Routenplanung

# System-Routingtabelle anzeigen
$ IP-Route zeigt Haupttabelle an
$ IP-Route zeigt Tabelle lokal an

# Holen Sie sich die Route zu einer bestimmten IP
$ IP-Route erhält 192.0.2.3

Ein-Klick-Installation

Informationen zur Ein-Klick-Installation finden Sie in diesem Projekt: WireGuard-Installationsprogramm^[3]

2. Konfigurationsdetails

WireGuard verwendet INI^[4] Das Konfigurationsdateiformat lautet /etc/wireguard/wg0.conf. Die Konfigurationsdatei kann in einem beliebigen Pfad abgelegt werden, muss aber über einen absoluten Pfad referenziert werden. Der Standardpfad lautet /etc/wireguard/wg0.conf.

Die Konfigurationsdatei muss ${Name der WireGuard-Schnittstelle}.conf heißen. Normalerweise wird dem Namen der WireGuard-Schnittstelle das Präfix wg vorangestellt und die Nummerierung beginnt bei 0. Sie können jedoch auch andere Namen verwenden, solange diese dem regulären Ausdruck ^[a-zA-Z0-9_=+.-]{1,15}$ entsprechen.

Sie können das VPN mit dem Befehl wg manuell konfigurieren. Im Allgemeinen wird jedoch die Verwendung von wg-quick empfohlen, da dieses eine leistungsfähigere und benutzerfreundlichere Konfigurationserfahrung bietet und die Konfiguration über Konfigurationsdateien verwalten kann.

Nachfolgend sehen Sie ein Beispiel für eine Konfigurationsdatei:

[Schnittstelle]
# Name = node1.example.tld
Adresse = 192.0.2.3/32
ListenPort = 51820
Privater Schlüssel = lokaler privater SchlüsselAbcAbcAbc=
DNS = 1.1.1.1,8.8.8.8
Tabelle = 12345
MTU = 1500
PreUp = /bin/Beispiel arg1 arg2 %i
PostUp = /bin/example arg1 arg2 %i
PreDown = /bin/Beispiel arg1 arg2 %i
PostDown = /bin/Beispiel arg1 arg2 %i

[Peer]
# Name = node2-node.example.tld
Erlaubte IPs = 192.0.2.1/24
Endpunkt = node1.example.tld:51820
Öffentlicher Schlüssel = remotePublicKeyAbcAbcAbc=
PersistentKeepalive = 25

[Schnittstelle]

In diesem Abschnitt wird die lokale VPN-Konfiguration definiert. Beispiel:

Der lokale Knoten ist ein Client, der nur seinen eigenen Datenverkehr weiterleitet und nur eine IP verfügbar macht.
[Schnittstelle]
# Name = phone.example-vpn.dev
Adresse = 192.0.2.5/32
Privater Schlüssel =
Der lokale Knoten ist ein Relay-Server, der den Datenverkehr an andere Peers weiterleitet und das Routing des gesamten VPN-Subnetzes offenlegt.
[Schnittstelle]
# Name = public-server1.example-vpn.tld
Adresse = 192.0.2.1/24
ListenPort = 51820
Privater Schlüssel =
DNS = 1.1.1.1

① #-Name

Dies ist ein Standardkommentar in der INI-Syntax, der angibt, zu welchem Knoten dieser Teil der Konfiguration gehört. Dieser Teil der Konfiguration wird von WireGuard vollständig ignoriert und hat keinen Einfluss auf das Verhalten des VPN.

② Adresse

Definiert den Adressbereich, in den der lokale Knoten routen soll. Handelt es sich um einen regulären Client, wird die IP-Adresse des Knotens selbst (angegeben per CIDR, z. B. 192.0.2.3/32) verwendet. Handelt es sich um einen Relay-Server, wird ein routingfähiger Subnetzbereich verwendet.

Zum Beispiel:

Normaler Client, leitet nur seinen eigenen Datenverkehr weiter: Adresse = 192.0.2.3/32
Relay-Server, der den Verkehr an andere Peer-Knoten (Peers) weiterleiten kann: Adresse = 192.0.2.1/24
Sie können auch mehrere Subnetze oder IPv6-Subnetze angeben: Adresse = 192.0.2.1/24,2001:DB8::/64

③ ListenPort

Wenn der lokale Knoten ein Relay-Server ist, müssen Sie über diesen Parameter den Port angeben, der auf eingehende VPN-Verbindungen wartet. Die Standardportnummer ist 51820. Normale Clients benötigen diese Option nicht.

④ Privater Schlüssel

Der private Schlüssel des lokalen Knotens muss für alle Knoten (einschließlich Relay-Server) festgelegt werden. Er kann nicht mit anderen Servern geteilt werden.

Der private Schlüssel kann mit dem Befehl wg genkey > example.key generiert werden.

⑤ DNS

Gibt Clients DNS-Server über DHCP bekannt. Clients verwenden die hier angegebenen DNS-Server für die Bearbeitung von DNS-Anfragen im VPN-Subnetz. Diese Option kann jedoch auch systemseitig überschrieben werden. Beispiel:

Wenn nicht konfiguriert, wird der Standard-DNS des Systems verwendet
Ein einzelner DNS kann angegeben werden: DNS = 1.1.1.1
Sie können auch mehrere DNS angeben: DNS = 1.1.1.1,8.8.8.8

⑥ Tabelle

Definiert die vom VPN-Subnetz verwendete Routing-Tabelle. Standardmäßig sind keine Einstellungen erforderlich. Für diesen Parameter gibt es zwei spezielle Werte, die beachtet werden müssen:

Tabelle = aus : Deaktivieren der Routenerstellung
Tabelle = automatisch (Standard) : Fügen Sie die Route zur Systemstandardtabelle hinzu und aktivieren Sie die spezielle Verarbeitung für die Standardroute.

Beispiel: Tabelle = 1234

⑦ MTU

Definiert die MTU (Maximum Transmission Unit) der mit dem Peer verbundenen Verbindung. Standardmäßig muss diese nicht festgelegt werden und wird in der Regel automatisch vom System ermittelt.

⑧ PreUp

Der Befehl, der vor dem Starten der VPN-Schnittstelle ausgeführt werden soll. Diese Option kann mehrfach angegeben werden und wird der Reihe nach ausgeführt.

Zum Beispiel:

Route hinzufügen: PreUp = IP-Regel hinzufügen ipproto tcp dport 22 Tabelle 1234

⑨ PostUp

Der Befehl, der nach dem Starten der VPN-Schnittstelle ausgeführt werden soll. Diese Option kann mehrfach angegeben werden und wird der Reihe nach ausgeführt.

Zum Beispiel:

Lesen Sie Konfigurationseinstellungen aus einer Datei oder aus der Ausgabe eines Befehls:
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
Fügen Sie der Datei eine Protokollzeile hinzu:
PostUp = echo "$(Datum +%s) WireGuard gestartet" >> /var/log/wireguard.log
WebHook aufrufen:
PostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
Fügen Sie eine Route hinzu:
PostUp = IP-Regel hinzufügen ipproto tcp dport 22 Tabelle 1234
Fügen Sie iptables-Regeln hinzu, um die Paketweiterleitung 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 des Peer-Domänennamens neu auflöst:
PostUp = resolvectl-Domäne %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i ja

⑩ PreDown

Der Befehl, der vor dem Stoppen der VPN-Schnittstelle ausgeführt werden soll. Diese Option kann mehrfach angegeben werden und wird der Reihe nach ausgeführt.

Zum Beispiel:

Fügen Sie der Datei eine Protokollzeile hinzu:
PreDown = echo "$(Datum +%s) WireGuard wird heruntergefahren" >> /var/log/wireguard.log
WebHook aufrufen:
PreDown = Locke https://events.example.dev/wireguard/stopping/?key=abcdefg

⑪ PostDown

Der Befehl, der nach dem Stoppen der VPN-Schnittstelle ausgeführt werden soll. Diese Option kann mehrfach angegeben werden und wird der Reihe nach ausgeführt.

Zum Beispiel:

Fügen Sie der Datei eine Protokollzeile hinzu:
PostDown = echo "$(Datum +%s) WireGuard wird heruntergefahren" >> /var/log/wireguard.log
WebHook aufrufen:
PostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
Löschen Sie die iptables-Regeln und deaktivieren Sie die Paketweiterleitung:
PostDown = iptables -D WEITER -i %i -j AKZEPTIEREN; iptables -D WEITER -o %i -j AKZEPTIEREN; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]

Eine VPN-Einstellung, die Peers definiert, die Datenverkehr für eine oder mehrere Adressen weiterleiten können. Ein Peer kann ein Relay-Server sein, der Datenverkehr an andere Peers weiterleitet, oder ein Client, der eine direkte Verbindung über das öffentliche oder private Netzwerk herstellt.

Der Relay-Server muss alle Clients als Peers definieren. Kein anderer Client als der Relay-Server kann einen Knoten hinter NAT als Peer definieren, da die Route nicht erreichbar ist. Für Clients, die nur ihren eigenen Verkehr weiterleiten, muss nur der Relay-Server Peer sein, und andere Knoten müssen direkt erreichbar sein.

Beispielsweise wird in der folgenden Konfiguration „public-server1“ als Relay-Server verwendet und andere Clients sind entweder direkt verbunden oder hinter NAT:

öffentlicher Server1 (Relay-Server) [Peer]: öffentlicher Server2, Heimserver, Laptop, Telefon
public-server2 (direkt verbundener Client) [Peer] : public-server1
Home-Server (Client befindet sich hinter NAT) [Peer]: öffentlicher Server1, öffentlicher Server2
Laptop (Client hinter NAT) [Peer]: öffentlicher Server1, öffentlicher Server2
Telefon (Client ist hinter NAT) [Peer]: öffentlicher Server1, öffentlicher Server2

Konfigurationsbeispiel:

Ein Peer ist ein routingfähiger Client, der den Datenverkehr nur für sich selbst weiterleitet.
[Peer]
# Name = public-server2.example-vpn.dev
Endpunkt = public-server2.example-vpn.dev:51820
Öffentlicher Schlüssel =
Erlaubte IPs = 192.0.2.2/32
Ein Peer ist ein Client hinter einem NAT, der den Datenverkehr nur für sich selbst weiterleitet.
[Peer]
# Name = Home-Server.Beispiel-VPN.dev
Endpunkt = home-server.example-vpn.dev:51820
Öffentlicher Schlüssel =
Erlaubte IPs = 192.0.2.3/32
Ein Peer-Knoten ist ein Relay-Server, der den Datenverkehr an andere Peer-Knoten weiterleitet.
[Peer]
# Name = public-server1.example-vpn.tld
Endpunkt = public-server1.example-vpn.tld:51820
Öffentlicher Schlüssel =
# leitet den Verkehr für das gesamte VPN-Subnetz weiter
Erlaubte IPs = 192.0.2.1/24
PersistentKeepalive = 25

① Endpunkt

Gibt die öffentliche Netzwerkadresse des entfernten Peers an. Befindet sich der Peer hinter einem NAT oder hat er keine stabile öffentliche Netzwerkadresse, wird dieses Feld ignoriert. Normalerweise nurRelay-ServerAls Endpunkt können natürlich auch Knoten mit stabiler öffentlicher IP angegeben werden. Beispiel:

Nach IP angeben:
Endpunkt = 123.124.125.126:51820
Nach Domänennamen angeben:
Endpunkt = public-server1.example-vpn.tld:51820

② Erlaubte IPs

Der Quelladressbereich des von diesem Peer zugelassenen VPN-Verkehrs. Dieses Feld wird auch als IP-Adressbereich verwendet, der in der lokalen Routing-Tabelle an wg0 gebunden ist. Handelt es sich bei dem Peer um einen regulären Client, wird die IP-Adresse des Knotens selbst verwendet. Handelt es sich bei dem Peer um einen Relay-Server, wird ein routingfähiger Subnetzbereich verwendet. Sie können , verwenden, um mehrere IP-Adressen oder Subnetzbereiche anzugeben. Dieses Feld kann auch mehrfach angegeben werden.

Bei der Entscheidung, wie ein Paket geroutet werden soll, wählt das System zunächst die spezifischste Route. Wenn keine Übereinstimmung gefunden wird, wählt es eine allgemeinere Route. Beispielsweise sucht das System für ein an 192.0.2.3 gesendetes Paket zunächst nach einem Peer mit der Adresse 192.0.2.3/32. Wenn kein Peer vorhanden ist, sucht das System nach einem Peer mit der Adresse 192.0.2.3/32 usw.

Zum Beispiel:

Ein Peer ist ein normaler Client, der nur seinen eigenen Datenverkehr weiterleitet:
Erlaubte IPs = 192.0.2.3/32
Ein Peer ist ein Relay-Server, der Datenverkehr an andere Peers weiterleitet:
Erlaubte IPs = 192.0.2.1/24
Ein Peer-Knoten ist ein Relay-Server, der den gesamten Datenverkehr weiterleitet, einschließlich externem Netzwerkverkehr und VPN-Verkehr. Sie wissen, wofür er verwendet werden kann:
Erlaubte IPs = 0.0.0.0/0,::/0
Ein Peer ist ein Relay-Server, der den Datenverkehr zwischen sich und anderen Peers weiterleitet:
Erlaubte IPs = 192.0.2.3/32,192.0.2.4/32
Ein Peer ist ein Relay-Server, der seinen eigenen Datenverkehr und den Datenverkehr des Intranets, in dem er sich befindet, weiterleiten kann:
Erlaubte IPs = 192.0.2.3/32,192.168.1.1/24

③ Öffentlicher Schlüssel

Der öffentliche Schlüssel des Peer-Knotens (Peer) muss von allen Knoten (einschließlich Relay-Servern) festgelegt werden. Sie können denselben öffentlichen Schlüssel mit anderen Peer-Knoten (Peer) teilen.

Der öffentliche Schlüssel kann über den Befehl wg pubkey abgerufen werden. < beispiel.schlüssel > example.key.pub, wobei example.key der oben generierte private Schlüssel ist.

Beispiel: PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=

④ PersistentKeepalive

Wenn die Verbindung von einem Peer hinter einem NAT zu einem im öffentlichen Netzwerk erreichbaren Peer besteht, muss der Peer hinter dem NAT regelmäßig ein ausgehendes Ping-Paket senden, um die Konnektivität zu überprüfen und den Endpunkt automatisch zu aktualisieren, wenn sich die IP ändert.

Zum Beispiel:

Der lokale Knoten ist direkt mit dem Peer-Knoten verbunden: Dieses Feld muss nicht angegeben werden, da keine Verbindungsprüfung erforderlich ist.
Peer befindet sich hinter NAT: Dieses Feld muss nicht angegeben werden, da die Verantwortung für die Aufrechterhaltung der Verbindung beim Client (dem Initiator der Verbindung) liegt.
Der lokale Knoten befindet sich hinter NAT und der Peer-Knoten ist im öffentlichen Netzwerk erreichbar: Sie müssen das Feld PersistentKeepalive = 25 angeben, was bedeutet, dass alle 25 Sekunden ein Ping gesendet wird, um die Verbindung zu überprüfen.

3. Erweiterte Funktionen

IPv6

Die vorherigen Beispiele verwenden hauptsächlich IPv4, WireGuard unterstützt auch IPv6. Beispiel:

[Schnittstelle]
AllowedIps = 192.0.2.3/24, 2001:DB8::/64

[Peer]
...
Erlaubte IPs = 0.0.0.0/0, ::/0

Leiten Sie den gesamten Datenverkehr weiter

Wenn Sie den gesamten Datenverkehr über VPN weiterleiten möchten, einschließlich VPN-Subnetz und öffentlichem Netzwerkverkehr, müssen Sie 0.0.0.0/0, ::/0 in AllowedIPs von [Peer] hinzufügen.

Auch wenn Sie nur IPv4-Verkehr weiterleiten, sollten Sie ein IPv6-Netzwerksegment angeben, um das Durchsickern von IPv6-Paketen außerhalb des VPN zu verhindern. Weitere Informationen finden Sie unter: reddit.com/r/WireGuard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to^[5]

Zum Beispiel:

[Schnittstelle]
# Name = phone.example-vpn.dev
Adresse = 192.0.2.3/32
Privater Schlüssel =

[Peer]
# Name = public-server1.example-vpn.dev
Öffentlicher Schlüssel =
Endpunkt = public-server1.example-vpn.dev:51820
Erlaubte IPs = 0.0.0.0/0, ::/0

Im Allgemeinen müssen Sie den gesamten Datenverkehr nur weiterleiten, wenn Sie VPN als „Leiter zum Himmel“ verwenden. Mehr verrate ich hier nicht.

NAT-zu-NAT-Verbindungen

Wenn sich zwei Peers hinter NAT befinden und ohne Relay-Server eine direkte Verbindung herstellen möchten, müssen Sie sicherstellen, dass mindestens einer der Peers über einen stabilen öffentlichen Netzwerkausgang verfügt, entweder mithilfe einer statischen öffentlichen IP oder durch dynamische Aktualisierung des FQDN über DDNS.

Das WebRTC-Protokoll kann die Verbindung zwischen zwei NATs dynamisch konfigurieren und die IP:Port-Kombination jedes Hosts über einen Signalserver erkennen. WireGuard verfügt jedoch nicht über diese Funktion. Es verfügt nicht über einen Signalserver, um dynamisch nach anderen Hosts zu suchen, und kann lediglich Endpoint+ListenPort fest codieren und die Verbindung über PersistentKeepalive aufrechterhalten.

Um die Voraussetzungen für NAT-zu-NAT-Verbindungen zusammenzufassen:

Mindestens ein Peer-Knoten verfügt über eine feste öffentliche IP-Adresse. Wenn keiner der beiden Knoten über eine feste öffentliche IP-Adresse verfügt, kann DDNS zur Aufrechterhaltung eines stabilen Domänennamens verwendet werden.
Mindestens ein Peer-Knoten gibt einen UDP-ListenPort an, und sein NAT-Router kann keine zufällige UDP-Quellportzuweisung durchführen, da sonst das Rückgabepaket an den zuvor angegebenen ListenPort gesendet und vom Router verworfen wird und nicht an den neu zugewiesenen zufälligen Port gesendet wird.
Alle Peers müssen PersistentKeepalive auf anderen Peers in der [Peer]-Konfiguration aktivieren, damit die Verbindungspersistenz aufrechterhalten werden kann.

Für beide Kommunikationspartner,ServerWenn der NAT-Router keine Weiterleitungsregeln für den Peer-Knoten hinter NAT angibt, ist UDP Hole Punching erforderlich.

Das Prinzip des UDP Hole Punching:

Peer1 sendet ein UDP-Datenpaket an Peer2, doch der NAT-Router von Peer2 weiß nicht, an wen er das Paket senden soll, und verwirft es daher. Das spielt jedoch keine Rolle. Dieser Schritt ermöglicht es dem NAT-Router von Peer1, die UDP-Antwort zu empfangen und an Peer1 weiterzuleiten.
Peer2 sendet ein UDP-Datenpaket an Peer1. Aufgrund des vorherigen Schritts hat der NAT-Router von Peer1 eine temporäre Weiterleitungsregel eingerichtet und kann UDP-Antworten empfangen. Daher kann er das Datenpaket empfangen und an Peer1 weiterleiten.
Peer1 sendet eine UDP-Antwort an Peer2. Aufgrund des vorherigen Schrittes kann der NAT-Router von Peer2 bereits UDP-Antworten empfangen und das Datenpaket empfangen und an Peer2 weiterleiten.

Dieser Vorgang, bei dem ein erstes Paket gesendet, abgelehnt wird und dann die festgelegten Weiterleitungsregeln des Routers verwendet werden, um eine Antwort zu erhalten, wird als „UDP Hole Punching“ bezeichnet.

Beim Senden eines UDP-Pakets erstellt der Router üblicherweise eine temporäre Regel, um die Quelladresse/den Quellport der Zieladresse/dem Zielport und umgekehrt zuzuordnen. Die von der Zieladresse und dem Zielport zurückgegebenen UDP-Pakete werden an die ursprüngliche Quelladresse und den ursprünglichen Quellport weitergeleitet. So funktionieren die meisten UDP-Anwendungen hinter NAT (z. B. BitTorrent, Skype usw.). Diese temporäre Regel läuft nach einiger Zeit ab, sodass der Client hinter NAT regelmäßig Pakete über PersistentKeepalive senden muss, um die Verbindung aufrechtzuerhalten.

Wenn sich zwei Peers hinter NAT befinden, müssen die beiden Knoten Pakete etwa zur gleichen Zeit aneinander senden, damit UDP Hole Punching funktioniert. Dies bedeutet, dass beide Parteien die öffentliche Netzwerkadresse und Portnummer des jeweils anderen im Voraus kennen müssen. Diese können in wg0.conf angegeben werden.

Einschränkungen von UDP Hole Punching

Seit 2019 sind viele altmodische Lochmethoden, die zuvor verwendet wurden, nicht mehr effektiv. Die bekannteste Methode in der Vergangenheit war pwnat^[6] Eine neue, von NAT entwickelte Hole-Punching-Methode ermöglicht P2P-Kommunikation in NAT ohne Proxy, Drittanbieter-Server, UPnP, DMZ, Sproofing und DNS-Konvertierung. Das Prinzip ist ebenfalls sehr einfach:

Dieses Problem wird dadurch gelöst, dass der Client vorgibt, ein zufälliger ICMP-Hop im Internet zu sein, sodass der Server die IP-Adresse des Clients ermitteln kann. Der Befehl „Traceroute“ nutzt diese Technologie ebenfalls zur Erkennung von Hops im Internet.

Insbesondere wenn der Server startet, beginnt er mit dem Senden von festen ICMP-Echoanforderungspaket(ICMP-Echoanforderungspakete). Offensichtlich können wir keine Antwort von 3.3.3.3 erhalten. ICMP-Echopakete3.3.3.3 ist jedoch kein Host, auf den wir zugreifen können, und wir möchten auch nicht so tun, als wären wir einer, um ICMP-Echopakete zu senden. Stattdessen besteht das Implementierungsprinzip der pwnat-Technologie darin, dass der Client (der die IP-Adresse des Servers kennt) ein ICMP-Echopaket an den Server sendet, wenn er eine Verbindung zum Server herstellen möchte. ICMP-Zeitüberschreitungspakete(ICMP-Zeitüberschreitungspaket). Dieses ICMP-Paket enthält das ursprüngliche Festzeitpaket, das vom Server an 3.3.3.3 gesendet wurde. ICMP-Echoanforderungspaket.

Warum tun wir das? Nun, wir geben vor, ein ICMP-Hop im Internet zu sein und teilen dem Server höflich mit, dass sein ursprünglicher ICMP-EchoanforderungspaketKann nicht auf 3.3.3.3 zugreifen. Und Ihr NAT ist ein intelligentes Gerät, es wird es bemerken ICMP-ZeitüberschreitungspaketeDie Datenpakete im Server werden gesendet ICMP-EchoanforderungspaketDann wird es ICMP-ZeitüberschreitungspaketeWird an den Server hinter NAT zurückgeleitet, einschließlich des vollständigen IP-Paketheaders vom Client, damit der Server die IP-Adresse des Clients kennt!

Derzeit unterliegt diese Art der UDP-Lochstanzmethode vielen Einschränkungen. Weitere Informationen finden Sie unterVorheriger ArtikelZusätzlich zum UDP-Hole-Punching können wir weiterhin fest codierte Methoden verwenden, um die öffentlichen Netzwerkadressen und Portnummern der beiden Peer-Knoten anzugeben. Diese Methode ist für die meisten NAT-Netzwerke effektiv.

Quellport-Randomisierung

Befinden sich alle Peers hinter einem NAT mit strikter UDP-Quellport-Randomisierung (wie in den meisten Mobilfunknetzen), sind keine NAT-zu-NAT-Verbindungen möglich. Da keine der beiden Parteien einen ListenPort aushandeln und sicherstellen kann, dass ihr NAT nach dem Senden eines Ping-Pakets den an diesen Port gesendeten Datenverkehr empfangen kann, ist es unmöglich, das Hole Punching zu initialisieren, was zu einem Verbindungsabbruch führt. Daher ist P2P-Kommunikation in LTE/3G-Netzen generell nicht möglich.

Verwenden eines Signalisierungsservers

Wie im vorherigen Abschnitt erwähnt, ist eine NAT-zu-NAT-Verbindung nicht direkt möglich, wenn sich alle Peers hinter NAT mit strikter UDP-Quellport-Randomisierung befinden. Dies kann jedoch über einen Signalserver eines Drittanbieters erfolgen. Der Signalserver entspricht einer Transitstation, die den kommunizierenden Parteien die IP-Port-Informationen der Gegenpartei mitteilt. Hier einige Beispiele:

takutakahashi/wg-connect^[7]
git.zx2c4.com/wireguard-tools/tree/contrib/nat-hole-punching^[8]

Dynamische IP-Adresse

WireGuard löst Domänennamen nur beim Start auf. Wenn Sie DDNS zur dynamischen Aktualisierung der Domänennamenauflösung verwenden, müssen Sie WireGuard bei jeder IP-Änderung neu starten. Die derzeit empfohlene Lösung besteht darin, WireGuard alle paar Minuten oder Stunden mit dem PostUp-Hook neu zu starten, um die Auflösung der Domänennamen zu erzwingen.

Im Allgemeinen sind NAT-zu-NAT-Verbindungen äußerst instabil und unterliegen zahlreichen weiteren Einschränkungen. Daher wird empfohlen, über einen Relay-Server zu kommunizieren.

Beispiel einer NAT-zu-NAT-Konfiguration:

Peer1:

[Schnittstelle]
...
ListenPort = 12000

[Peer]
...
Endpunkt = peer2.example-vpn.dev:12000
PersistentKeepalive = 25

Peer2:

[Schnittstelle]
...
ListenPort = 12000

[Peer]
...
Endpunkt = peer1.example-vpn.dev:12000
PersistentKeepalive = 25

Weitere Informationen:

samyk/pwnat^[9]
en.wikipedia.org/wiki/UDP_hole_punching^[10]
stackoverflow.com/questions/8892142/udp-hole-punching-algorithm^[11]
stackoverflow.com/questions/12359502/udp-hole-punching-not-going-through-on-3g^[12]
stackoverflow.com/questions/11819349/udp-hole-punching-not-possible-with-mobile-provider^[13]
WireGuard/WireGuard@Master/contrib/beispiele/nat-hole-punching^[14]
staaldraad.github.io/2017/04/17/nat-to-nat-with-wireguard^[15]
golb.hplar.ch/2019/01/expose-server-vpn.html^[16]

Subnetz-IP dynamisch zuweisen

Dies bezieht sich auf die dynamische Zuweisung der VPN-Subnetz-IP des Peer-Knotens (Peer), ähnlich wie DHCP, nicht Endpoint.

WireGuard entwickelt offiziell die Funktion zur dynamischen Zuweisung von Subnetz-IPs. Die konkrete Implementierung finden Sie hier: WireGuard/wg-dynamic^[17]

Natürlich können Sie PostUp auch verwenden, um IP-Werte zur Laufzeit aus einer Datei zu lesen und so ein System zu implementieren, das IPs dynamisch zuweist, ähnlich dem CNI-Plugin für Kubernetes. Beispiel:

[Schnittstelle]
...
PostUp = wg set %i erlaubte IPs /etc/wireguard/wg0.key <(some command)

Praktische Tipps

Freigeben einer peers.conf-Datei

Einführung einer geheimen Funktion, die die WireGuard-Konfiguration vereinfacht. Stimmt der öffentliche Schlüssel eines Peers mit dem privaten Schlüssel der lokalen Schnittstelle überein, ignoriert WireGuard den Peer. Mit dieser Funktion können wir die gleiche Peer-Liste auf allen Knoten teilen. Jeder Knoten muss lediglich eine separate [Schnittstelle] definieren, und selbst wenn der Knoten in der Liste enthalten ist, wird er ignoriert. Die genaue Vorgehensweise lautet wie folgt:

Jeder Peer verfügt über eine separate Datei /etc/wireguard/wg0.conf, die nur die Konfiguration des Abschnitts [Interface] enthält.
Jeder Peer-Knoten (Peer) teilt sich dieselbe Datei /etc/wireguard/peers.conf, die alle Peers enthält.
In der Datei Wg0.conf muss ein PostUp-Hook mit dem Inhalt PostUp = wg addconf /etc/wireguard/peers.conf konfiguriert werden.

Es gibt viele Möglichkeiten, peers.conf zu teilen. Sie können sie über Tools wie Ansible verteilen, mit einem Netzwerklaufwerk wie Dropbox synchronisieren oder sie mithilfe eines verteilten Dateisystems wie Ceph auf verschiedenen Knoten bereitstellen.

Lesen Sie die Konfiguration aus einer Datei oder Befehlsausgabe

WireGuard kann auch Inhalte aus der Ausgabe beliebiger Befehle oder Dateien lesen, um den Konfigurationswert zu ändern. Diese Funktion erleichtert die Schlüsselverwaltung. Beispielsweise können Schlüssel zur Laufzeit von Drittanbieterdiensten wie Kubernetes Secrets oder AWS KMS gelesen werden.

Containerisierung

WireGuard kann auch in einem Container ausgeführt werden. Am einfachsten ist es, die Parameter --privileged und --cap-add=all zu verwenden, um dem Container das Laden von Kernelmodulen zu ermöglichen.

Sie können WireGuard in einem Container ausführen und eine Netzwerkschnittstelle für den Host verfügbar machen. Sie können WireGuard auch im Host ausführen und eine Schnittstelle für einen bestimmten Container verfügbar machen.

Hier ist ein konkretes Beispiel, in dem der vpn_test-Container den gesamten Datenverkehr über einen WireGuard-Relay-Server leitet. Die in diesem Beispiel angegebene Containerkonfiguration liegt im Docker-Compose-Konfigurationsdateiformat vor.

Relay-Server-Containerkonfiguration:

Version: '3'

Dienstleistungen:
Drahtschutz:
Bild: Linuxserver/Wireguard
Häfen:
51820: 51820 / UDP
cap_add:
-NET_ADMIN
-SYS_MODULE
Bände:
– /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro

Relay-Server WireGuard-Konfiguration wg0.conf:

[Schnittstelle]
# Name = relay1.wg.example.com
Adresse = 192.0.2.1/24
ListenPort = 51820
Privater Schlüssel = oJpRt2Oq27vIB5/UVb7BRqCwad2YMReQgH5tlxz8YmI=
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A WEITERLEITEN -i wg0 -j AKZEPTIEREN; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A WEITERLEITEN -i wg0 -j AKZEPTIEREN; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D WEITER -i wg0 -j AKZEPTIEREN; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D WEITER -i wg0 -j AKZEPTIEREN; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
#-Name = peer1.wg.example.com
Öffentlicher Schlüssel = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/2Gg=
Erlaubte IPs = 192.0.2.2/32

Client-Container-Konfiguration:

Version: '3'

Dienstleistungen:
Drahtschutz:
Bild: Linuxserver/Wireguard
cap_add:
-NET_ADMIN
-SYS_MODULE
Bände:
– /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro

VPN-Test:
Bild: curlimages/curl
Einstiegspunkt: curl -s http://whatismyip.akamai.com/
Netzwerkmodus: „Dienst: Wireguard“

Clientseitige WireGuard-Konfiguration wg0.conf:

[Schnittstelle]
#-Name = peer1.wg.example.com
Adresse = 192.0.2.2/32
Privater Schlüssel = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/sgk8=
DNS = 1.1.1.1,8.8.8.8

[Peer]
# Name = relay1.wg.example.com
Endpunkt = relay1.wg.example.com:51820
Öffentlicher Schlüssel = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+2um0c0B1s=
Erlaubte IPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21