WireGuard, Einrichtung mehrerer Clients für NAT und wohin geht STUN?

Momentan starten wir den Zugriff auf Server, die auf WireGuard basieren, und heute möchte ich darüber sprechen, wie Clients konfiguriert werden, die sich hinter NAT befinden, obwohl wir auch die Serverkonfiguration nicht vergessen werden.

Zunächst zu den Vorteilen von WireGuard und der Rückseite der Medaille, zu den Schwierigkeiten, die mit den Vorteilen einhergehen. WireGuard ist eine relativ junge Implementierung eines Tunnels zwischen zwei Punkten, da das Übertragungsprotokoll von UDP verwendet wird. Aus diesem Grund und auch, weil die Linux-Implementierung selbst als Kernel-Modul implementiert ist, zeigen die Tests einen ordentlichen Geschwindigkeitsvorteil gegenüber Mitbewerbern. Dies kann nicht als Peer-to-Peer-Netzwerk betrachtet werden, obwohl die Endknoten als Peer bezeichnet werden . Das Wesen eines Peer-to-Peer-Netzwerks besteht nicht nur darin, dass es möglich wäre, zwei beliebige Knoten zu verbinden. Natürlich können Sie mit diesem Toolkit eine sehr komplexe Netzwerkinfrastruktur aufbauen, aber ich habe kein solches Ziel. Wir werden überlegen, eine Verbindung zu einem Serverknoten herzustellen und über diesen auf das Internet zuzugreifen.

Wenn zwei Knoten, der Server und ein Client weiße IPs haben, sollte es in diesem Fall offensichtlich keine Schwierigkeiten beim Einrichten geben. Häufig befinden sich Clients jedoch hinter NAT. In diesem Fall müssen Sie beim Einrichten des Servers die falsche IP-Adresse angeben, die auf dem Gerät ausgegeben / registriert wurde. In dieser Hinsicht kann das STUN-Protokoll helfen. Dieses Protokoll wird häufig bei der Arbeit mit VoIP verwendet, insbesondere wenn sich beide Clients hinter NAT befinden. In unserem Fall hilft es aber auch. Nach den Informationen auf Wikipedia funktioniert STUN nicht mit allen NAT-Typen: In einem der vier NAT-Typen kann ein (symmetrischer) Client eine andere IP-Adresse haben als eine, die extern mit dem STUN-Client definiert werden kann.

STUN-Clients existieren auf allen gängigen Betriebssystemen außer iOS. Unter diesem Betriebssystem konnte ich den STUN-Client nicht finden. Ich werde ein Beispiel für macOS geben. Zunächst müssen Sie den STUN-Client selbst installieren.

$ brew install stunman 

Es gibt Unmengen von STUN-Servern im Internet und es ist nicht schwierig, einen Server für den Test zu finden. Ich werde stun.ekiga.net benutzen. Für den Test müssen Sie den lokalen Port verwenden, den wir zur Konfiguration verwenden:

 $ stunclient --localport 51820 stun.ekiga.net 

Bei einem erfolgreichen Test erhalten wir ungefähr die folgende Schlussfolgerung:

 Binding test: success Local address: 192.168.88.23:51820 Mapped address: 82.207.27.3:51820 

Die zugeordnete Adresse ist genau die IP- Adresse , die Sie beim Einrichten des Servers verwenden müssen. In der Tat ist dies die IP-Adresse, die in meinem Fall einen Dienst zur Bestimmung der externen IP ausgibt. Aus diesem Grund können Sie Ihren bevorzugten Dienst zur Bestimmung der IP-Adresse verwenden. Es ist jedoch zu bedenken, dass dieser Test indirekt durchgeführt wird und es keine Garantie dafür gibt, dass alles wie beabsichtigt funktioniert.

Um auf der Clientseite eine Verbindung zum Server herzustellen, müssen Sie Folgendes angeben: IP, Port und öffentlicher Schlüssel. Für die Konfiguration auf der Clientseite benötigen Sie genau dieselbe Liste, die auf der Serverseite bereitgestellt wird. Als nächstes werde ich Optionen für Configs vorschlagen. Wenn Sie diese als Beispiele verwenden, wird empfohlen, die Schlüssel neu zu generieren.

Unter Linux kann dies über die Befehlszeile und unter macOS über die offizielle Client-Benutzeroberfläche erfolgen.

 $ wg genkey | tee privatekey | wg pubkey > publickey 

In diesem Fall wird am Ort des Anrufs der private Schlüssel in der Datei privatekey erstellt, public in in publickey.

Betrachten Sie zunächst die Client-Konfiguration:

 #       [Interface] #       PrivateKey = YPuKo2QXndQ2Vc3S/y90oKT7AJ0Swhq/HWKiF7GwS04= #         ListenPort = 51820 #  IP   ,        #    Address = 10.8.0.2/24 # DNS   ,      DNS = 8.8.8.8 #     [Peer] #   ,     PublicKey = nFjDIkgsAh1RMZuaCJ+AKs7JmbMxxthhZ0POjUSTvkc= #     ,       # IP  ,          #     ,      #     WireGuard . IP   , #   . AllowedIPs = 0.0.0.0/0 #  IP    Endpoint = 46.101.122.130:51820 #  2 .  -    ,     , #    AllowedIPs         #   .  -     # ,    -  25 . PersistentKeepalive = 25 

Jetzt ist es Zeit für die Serverkonfiguration:

 #       [Interface] # IP      Address = 10.8.0.1/24 #     ListenPort = 51820 #  ,      PrivateKey = MNnxOy79xtXtSQ3UySWtdlOMbG7ff9dXGjeSTPEByn8= #  2 ,      wg0  PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE #     [Peer] #   ,    PublicKey = TdRtYd6XXI+ynPDXU6FF5TT3L5t/YlQVZswr2xsou34= #   IP ,     , #     AllowedIPs = 10.8.0.2/32 #  IP ,   ,     STUN  EndPoint = 82.207.27.3:51820 

Wenn Sie diese Konfigurationen als Beispiel verwenden, wird empfohlen, Kommentare auf Russisch zu löschen. Bei Kommentaren können Server und Client nicht garantiert werden.

Ich habe die folgenden Ressourcen zum Konfigurieren verwendet: die offizielle Website , ArchWiki und dieses Tutorial .

Zum Schluss möchte ich noch einige mögliche Fragen klären:

1. Können auf dem Server mehrere Abschnitte desselben Peers erstellt werden, die sich nur in EndPoint unterscheiden ?

Ja, das ist möglich und es kann sogar nützlich sein, wenn Sie den Dienst von verschiedenen Orten aus nutzen, z. B. bei der Arbeit und zu Hause. Es können jedoch Probleme auftreten, wenn solche Peers gleichzeitig online gehen. In diesem Fall liegt ein Konflikt zwischen den IP-Adressen vor.

2. Welche externe IP und welcher Port werden vom STUN-Protokoll für mehrere Clients pro NAT bestimmt?

Für alle Kunden gleich, es wird dasselbe sein. Wäre das ein Problem? Dies hängt alles von den Einstellungen Ihres Providers / Routers ab. Grundsätzlich sollten jedoch keine Probleme auftreten, da der Router UDP-Pakete innerhalb des Netzwerks über die lokale Netzwerkmaske senden muss bzw. die empfangenden Parteien, die die Pakete entschlüsseln können, diese erfolgreich empfangen müssen. Wir haben Tests an unseren Geräten durchgeführt, die Tests waren erfolgreich.

Der Zweck des Artikels bestand nicht darin, ein vollständiges Tutorial zur Konfiguration von WireGuard zu verfassen. Es ist nicht schwierig, die offizielle Dokumentation zu verwenden. Wir wollten zeigen, wie WireGuard für NAT funktioniert.

Wenn Sie WireGuard im Geschäft ausprobieren möchten, können Sie uns kontaktieren, wir haben Zugriff im Testmodus.

UPD:
Wie der Aborouhin- Habitor zu Recht bemerkt hat , reicht nur eine weiße IP aus, damit der Datenkanal problemlos funktioniert. Dementsprechend kann EndPoint for Peer in der Serverkonfiguration weggelassen werden, was die Konfiguration vereinfacht. Das beschriebene Handbuch kann nützlich sein, wenn sich beide Knoten hinter NAT befinden.

Source: https://habr.com/ru/post/de481838/


All Articles