WireGuard, configuration de plusieurs clients pour NAT, et où va STUN?

En ce moment, nous lançons l'accès aux serveurs basés sur WireGuard et aujourd'hui je veux vous dire comment configurer les clients qui sont derrière NAT, bien que nous n'oublierons pas non plus la configuration du serveur.

Tout d'abord, sur les avantages de WireGuard et le revers de la médaille, sur les difficultés qui surgissent avec les avantages. WireGuard est une implémentation assez récente d'un tunnel entre deux points, car le protocole de transmission est utilisé par UDP. C'est pourquoi, et aussi parce que l'implémentation Linux elle-même est implémentée en tant que module du noyau, les tests montrent un avantage de vitesse décent sur les concurrents. Cela ne peut pas être considéré comme un réseau d'égal à égal, bien que les nœuds d'extrémité soient appelés homologues . L'essence d'un réseau peer-to-peer n'est pas seulement qu'il serait possible de connecter deux nœuds arbitraires. Bien sûr, avec cette boîte à outils, vous pouvez construire une infrastructure réseau très complexe, mais je n'ai pas un tel objectif. Nous envisagerons de nous connecter à un nœud de serveur et d'accéder à Internet via celui-ci.

Évidemment, si deux nœuds, le serveur et un client ont des IP blanches , dans ce cas, il ne devrait pas y avoir de difficultés de configuration. Mais souvent, les clients sont derrière NAT, et dans ce cas, lors de la configuration du serveur, vous devez spécifier la mauvaise adresse IP qui est émise / enregistrée sur le périphérique. À cet égard, le protocole STUN peut vous aider. Ce protocole est souvent utilisé lorsque vous travaillez avec VoIP, en particulier lorsque les deux clients sont derrière NAT. Mais dans notre cas, cela aidera également. À en juger par les informations sur Wikipédia, STUN ne fonctionne pas avec tous les types de NAT; dans l'un des 4 types de NAT, un client (symétrique) peut avoir une IP différente de celle qui peut être définie en externe à l'aide du client STUN.

Les clients STUN existent sur tous les systèmes d'exploitation courants à l'exception d'iOS. Sous ce système d'exploitation, je n'ai pas pu trouver le client STUN. Je vais donner un exemple pour macOS. Tout d'abord, vous devez installer le client STUN lui-même.

$ brew install stunman 

Il y a des tonnes de serveurs STUN sur Internet et il n'est pas difficile de trouver un serveur pour le test. J'utiliserai stun.ekiga.net . Pour le test, vous devrez utiliser le port local, celui que nous utiliserons pour configurer:

 $ stunclient --localport 51820 stun.ekiga.net 

Avec un test réussi, nous obtenons approximativement la conclusion suivante:

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

L'adresse mappée est exactement l'IP que vous devrez utiliser lors de la configuration du serveur. En fait, c'est l'adresse IP qui dans mon cas donnera tout service pour déterminer l'IP externe. Par conséquent, vous pouvez utiliser votre service préféré pour déterminer l'IP, mais bien sûr, il convient de considérer que ce test sera indirect et qu'il n'y a aucune garantie que tout fonctionnera comme prévu.

Pour vous connecter, côté client, au serveur, vous devez fournir: IP, port et clé publique. Pour la configuration côté client, vous avez besoin exactement de la même liste fournie côté serveur. Ensuite, je proposerai des options pour les configurations, si vous les utilisez comme exemples, il est recommandé de régénérer les clés.

Sous Linux, cela peut être fait à partir de la ligne de commande, sur macOS via l'interface utilisateur du client officiel.

 $ wg genkey | tee privatekey | wg pubkey > publickey 

Dans ce cas, au lieu de l'appel, la clé privée sera créée dans le fichier privatekey, public in dans publickey, respectivement.

Tout d'abord, considérez la configuration client:

 #       [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 

Il est maintenant temps pour la configuration du serveur:

 #       [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 

Lorsque vous utilisez ces configurations comme exemples, il est recommandé de supprimer les commentaires en russe, le serveur et le client en cas de commentaires ne sont pas garantis.

J'ai utilisé les ressources suivantes pour configurer: le site officiel , ArchWiki et ce tutoriel .

En fin de compte, je voudrais également clarifier quelques questions possibles:

1. Est-il possible de créer plusieurs sections du même Peer sur le serveur, qui ne différeront que dans EndPoint ?

Oui, c'est possible, et cela peut même être utile si vous utilisez le service à partir de différents endroits, par exemple au travail et à la maison. Mais des problèmes peuvent survenir si de tels homologues se connectent simultanément, dans ce cas, il y aura un conflit d'adresses IP.

2. Quels IP et port externes seront déterminés par le protocole STUN pour plusieurs clients par NAT?

La même chose pour tous les clients, ce sera la même chose. Serait-ce un problème? Tout dépend des paramètres de votre fournisseur / routeur, mais fondamentalement, aucun problème ne devrait survenir, car le routeur doit diffuser les paquets UDP à l'intérieur du réseau par le masque de réseau local, respectivement, les destinataires qui peuvent déchiffrer les paquets doivent les recevoir avec succès. Nous avons effectué des tests sur nos équipements, les tests ont réussi.

Le but de l'article n'était pas d'écrire un tutoriel complet sur la façon de configurer WireGuard, il n'est pas difficile de le faire en utilisant la documentation officielle. Nous voulions montrer comment WireGuard peut fonctionner pour NAT.

Si vous souhaitez essayer WireGuard en entreprise, vous pouvez nous contacter, nous y avons accès en mode test.

UPD:
Comme l'a souligné à juste titre l'habitant aborouhin , une seule adresse IP blanche suffit pour que le canal de données fonctionne sans problème. Par conséquent, EndPoint for Peer peut être omis de la configuration du serveur, ce qui facilite la configuration. Et le manuel décrit peut être utile si les deux nœuds sont derrière NAT.

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


All Articles