Get best of the week

Migration d'OpenVPN vers WireGuard pour joindre des réseaux en un seul réseau L2



Je voudrais partager l'expérience de la combinaison de réseaux dans trois appartements géographiquement éloignés, dans chacun desquels des routeurs avec OpenWRT sont utilisés comme passerelle dans un réseau commun. Lors du choix d'une méthode pour combiner des réseaux entre L3 avec des sous-réseaux de routage et L2 avec des ponts, lorsque tous les nœuds du réseau seront sur le même sous-réseau, la deuxième méthode a été préférée, qui était plus difficile à configurer, mais offrant plus d'opportunités, car le réseau était prévu d'utiliser des technologies transparentes Wake-on-Lan et DLNA.

Partie 1: Contexte


OpenVPN a été initialement choisi comme protocole pour la mise en œuvre de cette tâche, car, d'une part, il peut créer un périphérique de prise qui peut être facilement ajouté au pont, et d'autre part, OpenVPN prend en charge le fonctionnement du protocole TCP, ce qui était également important, car aucun des appartements n'avait une adresse IP dédiée, et je n'ai pas pu utiliser STUN, car pour une raison quelconque mon fournisseur bloque les connexions entrantes via UDP depuis leurs réseaux, tandis que TCP m'a permis de transférer le port du serveur VPN vers VPS loué en utilisant SSH. Oui, cette approche donne une grosse charge, car les données sont cryptées deux fois, mais je ne voulais pas entrer VPS dans mon réseau privé, car il y avait un risque que des tiers en prennent le contrôle, donc,avoir un tel appareil sur le réseau domestique était extrêmement indésirable et il a été décidé de payer pour la sécurité avec des frais généraux importants.

Pour transférer le port sur le routeur sur lequel il était prévu de déployer le serveur, le programme sshtunnel a été utilisé. Je ne décrirai pas les subtilités de sa configuration - cela se fait assez facilement, je note juste que sa tâche était de transmettre le port TCP 1194 du routeur au VPS. Ensuite, le serveur OpenVPN a été configuré sur le périphérique tap0, qui s'est retrouvé dans le pont br-lan. Après avoir vérifié la connexion au serveur que vous venez de créer à partir de l'ordinateur portable, il est devenu clair que l'idée de la redirection de port avait porté ses fruits et mon ordinateur portable était devenu membre du réseau de routeurs, même si je n'y étais pas physiquement.

Le problème est resté limité: il était nécessaire de distribuer les adresses IP dans différents appartements afin qu'ils ne soient pas en conflit et de configurer les routeurs comme clients OpenVPN.
Les adresses IP et les plages de serveurs DHCP suivantes ont été sélectionnées:

  • 192.168.10.1 avec une plage de 192.168.10.2 - 192.168.10.80 pour le serveur
  • 192.168.10.100 avec une plage de 192.168.10.101 - 192.168.10.149 pour le routeur de l'appartement n ° 2
  • 192.168.10.150 avec une plage de 192.168.10.151 - 192.168.10.199 pour le routeur de l'appartement n ° 3

Il était également nécessaire d'attribuer ces adresses aux routeurs clients du serveur OpenVPN en ajoutant les lignes suivantes à sa configuration:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

et en ajoutant les lignes suivantes au fichier /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

où flat1_id et flat2_id sont les noms de périphériques spécifiés lors de la création de certificats pour la connexion à OpenVPN

Ensuite, les clients OpenVPN ont été configurés sur les routeurs, des périphériques tap0 sur les deux ont été ajoutés au pont br-lan. À ce stade, il semblait que tout était en ordre, car les trois réseaux se voient et fonctionnent dans leur ensemble. Cependant, il s'est avéré que ce n'était pas un détail très agréable: parfois, les appareils ne pouvaient pas obtenir une adresse IP de leur routeur, avec toutes les conséquences qui en découlaient. Pour une raison quelconque, le routeur de certains appartements n'a pas eu le temps de répondre à temps à DHCPDISCOVER et l'appareil n'a pas reçu son adresse. J'ai réalisé que je devais filtrer ces requêtes dans tap0 sur chacun des routeurs, mais, comme il s'est avéré, iptables ne peut pas fonctionner avec l'appareil s'il fait partie du pont et ebtables devrait me venir en aide. Malheureusement, ce n'était pas dans mon firmware et j'ai dû reconstruire les images pour chaque appareil.Après avoir fait cela et ajouté de telles lignes à /etc/rc.local de chaque routeur, le problème a été résolu:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

Cette configuration a duré trois ans.

Partie 2: Présentation de WireGuard


Récemment, sur Internet, ils ont commencé à parler de plus en plus de WireGuard, admirant la simplicité de sa configuration, sa vitesse de transmission élevée, son ping faible avec une sécurité comparable. La recherche d'informations supplémentaires à son sujet a clairement montré qu'ils ne soutenaient ni le travail en tant que membre du pont, ni le protocole TCP, ce qui m'a fait penser qu'il n'y avait toujours pas d'alternative à OpenVPN pour moi. J'ai donc hésité à me familiariser avec WireGuard.

Il y a quelques jours, au-dessus des ressources, d'une manière ou d'une autre liées à l'informatique, la nouvelle a clignoté que WireGuard sera finalement inclus dans le noyau Linux, à partir de la version 5.6. Les articles de presse, comme toujours, ont fait l'éloge de WireGuard. J'ai de nouveau plongé dans la recherche de moyens de remplacer le bon vieux OpenVPN. Cette fois, je suis tombé sur cet article. Il a parlé de la construction d'un tunnel Ethernet sur L3 en utilisant GRE. Cet article m'a donné de l'espoir. On ne savait toujours pas quoi faire du protocole UDP. La recherche m'a conduit à des articles sur l'utilisation de socat en conjonction avec un tunnel SSH pour transférer un port UDP, cependant, ils ont noté que cette approche ne fonctionne qu'en mode de connexion unique, c'est-à-dire que le travail de plusieurs clients VPN serait impossible. J'ai eu l'idée d'élever un serveur VPN sur VPS et de configurer GRE pour les clients, mais il s'est avéré que GRE ne prend pas en charge le cryptage, ce qui conduira au fait qu'en cas d'accès au serveur par des tiers, tout le trafic entre mes réseaux est entre leurs mains cela ne me convenait pas en principe.

Encore une fois, la décision a été prise en faveur d'un cryptage excessif, en utilisant un VPN sur un VPN selon le schéma suivant:

VPN de premier niveau:
VPS est un serveur avec une adresse interne de 192.168.30.1
MS est un client VPS avec une adresse interne de 192.168.30.2
MK2 est un client VPS avec une adresse interne de 192.168.30.3
MK3 est un client VPS avec une adresse interne de 192.168.30.3 MK2 est un

VPN de deuxième niveau:
MS est un serveur avec une adresse externe 192.168.30.2 et un 192.168.31.1 interne
MK2 est un client MS avec une adresse de 192.168.30.2 et possède une IP interne 192.168.31.2
MK3 est un client MSavec l'adresse 192.168.30.2 et possède une IP interne 192.168.31.3

* MS - routeur-serveur dans l'appartement 1, MK2 - routeur dans l'appartement 2, MK3 - routeur dans l'appartement 3
* Les configurations des appareils sont publiées dans le spoiler à la fin de l'article.

Et donc, les pings entre les nœuds du réseau 192.168.31.0/24 vont, il est temps de passer à la configuration du tunnel GRE. Avant cela, afin de ne pas perdre l'accès aux routeurs, il convient de configurer des tunnels SSH pour transférer 22 ports sur le VPS, de sorte que, par exemple, le routeur de l'appartement 2 soit disponible sur le port 10022nd VPS et sur le port 11122th le VPS sera disponible le routeur est de l'appartement 3. Il est préférable de configurer le transfert avec le même sshtunnel, car il restaurera le tunnel s'il tombe.

Le tunnel est configuré, vous pouvez vous connecter à SSH via le port redirigé:

ssh root@_VPS -p 10022

Ensuite, désactivez OpenVPN:

/etc/init.d/openvpn stop

Configurez maintenant le tunnel GRE sur le routeur depuis l'appartement 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

Et ajoutez l'interface créée au pont:

brctl addif br-lan grelan0

Nous effectuerons une procédure similaire sur le routeur-serveur:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

Et, aussi, ajoutez l'interface créée au pont:

brctl addif br-lan grelan0

à partir de ce moment, les pings commencent à accéder avec succès au nouveau réseau et moi, avec satisfaction, je vais boire du café. Ensuite, afin d'évaluer le fonctionnement du réseau à l'autre extrémité du câble, j'essaie de me connecter via SSH à l'un des ordinateurs de l'appartement 2, mais le client ssh se bloque sans demander de mot de passe. J'essaie de me connecter à cet ordinateur via telnet au port 22 et je vois une ligne à partir de laquelle on peut comprendre que la connexion est établie, le serveur SSH répond, il ne me propose tout simplement pas d'entrer pour une raison quelconque.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

J'essaie de me connecter via VNC et de voir un écran noir. Je m'assure qu'il s'agit d'un ordinateur distant, car je peux facilement me connecter au routeur depuis cet appartement à l'adresse interne. Cependant, je décide de me connecter au SSH de cet ordinateur via un routeur et je suis surpris de constater que la connexion est réussie et que l'ordinateur distant fonctionne correctement, mais il ne peut pas non plus se connecter à mon ordinateur.

Je supprime le périphérique grelan0 du pont et exécute OpenVPN sur le routeur de l'appartement 2 et je m'assure que le réseau fonctionne à nouveau comme prévu et que les connexions ne se rompent pas. Lorsque je recherche, je tombe sur des forums où les gens se plaignent des mêmes problèmes, où il leur est conseillé d'augmenter le MTU. Cependant, je n'ai pas pu augmenter le MTU pour le VPN de premier niveau (wg0): avec les MTU supérieurs à 1420, qui sont définis automatiquement, les pauses commencent, mais en même temps, le VPN de deuxième niveau wg1 fonctionnant au-dessus de wg0 fonctionnait correctement avec MTU 1600. Cela suffit pour l'installation Le MTU est de 1500 pour le périphérique gretap, de sorte que cette interface a la même valeur MTU que le pont br-lan dans lequel le gretap devait être ajouté. Si je comprends bien, le pont définit le MTU égal à la plus petite des valeurs disponibles sur tous les appareils.

J'ai fait une configuration similaire sur le routeur de Apartment 3, à la seule différence que sur le routeur, le serveur a ajouté une deuxième interface gretap nommée grelan1, qui a également été ajoutée au pont br-lan.

Tout fonctionne. Vous pouvez maintenant mettre l'assemblage Gretap au démarrage. Pour ce faire:

Mettez ces lignes dans /etc/rc.local sur le routeur de l'appartement 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

Ajouté à /etc/rc.local sur le routeur de l'appartement 3:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

Et sur le routeur du serveur:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 1500
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 1500
ip link set grelan1 up
brctl addif br-lan grelan1

Après avoir redémarré les routeurs clients, j'ai constaté que pour une raison quelconque, ils ne se connectaient pas au serveur. Une fois connecté à leur SSH (heureusement, j'ai préconfiguré sshtunnel pour cela), il a été découvert que WireGuard créait une route pour le point de terminaison pour une raison quelconque, mais c'était incorrect. Ainsi, pour 192.168.30.2, la table de routage indiquait la route via l'interface pppoe-wan, c'est-à-dire via Internet, bien que la route vers celle-ci aurait dû être routée via l'interface wg0. Après avoir supprimé cet itinéraire, la connexion a été rétablie. Je n'ai pas pu trouver quelque part des instructions sur la façon de faire en sorte que WireGuard ne crée pas ces itinéraires. De plus, je n'ai même pas compris, une fonctionnalité est OpenWRT, ou WireGuard lui-même. Ne devant pas faire face à ce problème depuis longtemps, j'ai simplement ajouté une ligne à ce routeur au script bouclé par un timer pour supprimer cette route:

route del 192.168.30.2

Résumer


Je n'ai pas encore réussi à rejeter complètement OpenVPN, car j'ai parfois besoin de me connecter à un nouveau réseau à partir d'un ordinateur portable ou d'un téléphone, et la configuration d'un appareil Gretap sur eux est généralement impossible, mais malgré cela, j'ai obtenu un avantage dans la vitesse de transfert de données entre les appartements et, par exemple, l'utilisation de VNC maintenant ne cause aucun inconvénient. Le ping a légèrement diminué, mais est devenu plus stable:

lors de l'utilisation d'OpenVPN:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

Lors de l'utilisation de WireGuard:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

Il est davantage affecté par le ping élevé avant VPS, qui est d'environ 61,5 ms.

Cependant, la vitesse a considérablement augmenté. Donc, dans un appartement avec un routeur-serveur, j'ai une vitesse de connexion Internet de 30 Mbit / s, et dans d'autres appartements - 5 Mbit / s. Dans le même temps, lors de l'utilisation d'OpenVPN, je n'ai pas été en mesure d'atteindre un taux de transfert de données entre réseaux de plus de 3,8 Mb / s selon iperf, tandis que WireGuard le "pompait" aux mêmes 5 Mb / s.

Configuration de WireGuard sur VPS
[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <___VPS>

[Peer]
PublicKey = <__VPN_1_>
AllowedIPs = 192.168.30.2/32

[Peer]
PublicKey = <__VPN_2_2>
AllowedIPs = 192.168.30.3/32

[Peer]
PublicKey = <__VPN_2_3>
AllowedIPs = 192.168.30.4/32

Configuration de WireGuard sur MS (ajoutée à / etc / config / network)
#VPN   - 
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key '__VPN_1_'
        option auto '1'

config wireguard_wg0
        option public_key '__VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP__VPS'

#VPN   - 
config interface 'wg1'
        option proto 'wireguard'
        option private_key '__VPN_2_'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '1600'

config wireguard_wg1
        option public_key '__VPN_2_2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
        option public_key '__VPN_2_3'
        list allowed_ips '192.168.31.3'


Configuration de WireGuard sur MK2 (ajoutée à / etc / config / network)
#VPN   - 
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key '__VPN_1_2'
        option auto '1'

config wireguard_wg0
        option public_key '__VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP__VPS'

#VPN   - 
config interface 'wg1'
        option proto 'wireguard'
        option private_key '__VPN_2_2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '1600'

config wireguard_wg1
        option public_key '__VPN_2_'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'


Configuration WireGuard sur MK3 (ajoutée à / etc / config / network)
#VPN   - 
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key '__VPN_1_3'
        option auto '1'

config wireguard_wg0
        option public_key '__VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP__VPS'

#VPN   - 
config interface 'wg1'
        option proto 'wireguard'
        option private_key '__VPN_2_3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '1600'

config wireguard_wg1
        option public_key '__VPN_2_'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'


Dans les configurations décrites pour le VPN de deuxième niveau, je spécifie le port 51821 pour les clients WireGuard. En principe, cela n'est pas nécessaire, car le client établira une connexion à partir de n'importe quel port libre non privilégié, mais je l'ai fait pour que je puisse bloquer toutes les connexions entrantes sur les interfaces wg0 de tous les routeurs, sauf connexions UDP entrantes au port 51821.

J'espère que cet article sera utile à quelqu'un.

PS Aussi, je veux partager mon script qui m'envoie une notification PUSH sur le téléphone à l'application WirePusher lorsqu'un nouveau périphérique apparaît sur mon réseau. Voici le lien vers le script: github.com/r0ck3r/device_discover .

MISE À JOUR: Configuration du serveur et des clients OpenVPN

Serveur OpenVPN
client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo


Client OpenVPN
client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3



Pour générer des certificats utilisés easy-rsa

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

More articles:


All Articles