Je voudrais partager mon expérience d'intégration de réseaux dans trois appartements géographiquement éloignés, chacun utilisant des routeurs avec OpenWRT comme passerelle, en un réseau commun. En choisissant entre des réseaux L3 avec routage des sous-réseaux et L2 avec bridge, où tous les nœuds du réseau seraient dans le même sous-réseau, la seconde méthode, plus complexe à configurer mais offrant de plus grandes possibilités, a été privilégiée, car le réseau créé devait permettre une utilisation transparente de technologies telles que Wake-on-Lan et DLNA.
Partie 1 : Contexte
Pour la mise en œuvre de cette tâche, le protocole OpenVPN a d'abord été choisi, car, d'une part, il peut créer un appareil tap qui s'intègre parfaitement dans le bridge, et d'autre part, OpenVPN prend en charge le protocole TCP, ce qui était également crucial, car aucun des appartements n'avait d'adresse IP dédiée, et je n'ai pas pu utiliser STUN, car mon fournisseur bloque apparemment les connexions entrantes via le protocole UDP depuis ses réseaux, alors que le protocole TCP me permettait de rediriger le port du serveur VPN sur un VPS loué via SSH. Oui, cette approche entraîne une charge plus importante, car les données sont chiffrées deux fois, mais je ne souhaitais pas intégrer le VPS dans mon réseau privé, car cela comportait le risque que des tiers prennent le contrôle, rendant ainsi inacceptable d'avoir un tel appareil dans le réseau domestique, donc il a été décidé de payer pour la sécurité en conséquence.
Pour rediriger le port sur le routeur, où le serveur devait être déployé, le programme sshtunnel a été utilisé. Je ne vais pas décrire les subtilités de sa configuration — c'est assez simple, juste à noter que sa tâche était de rediriger le port TCP 1194 du routeur vers le VPS. Par la suite, le serveur OpenVPN a été configuré sur l'appareil tap0, qui était intégré dans le pont br-lan. Après avoir vérifié la connexion au serveur récemment créé depuis un ordinateur portable, il est devenu évident que l'idée de rediriger le port avait fonctionné et que mon ordinateur portable était devenu membre du réseau du routeur, même s'il n'y était pas physiquement.
Il ne restait plus qu'à répartir les adresses IP dans les différents appartements de manière à éviter les conflits et à configurer les routeurs en tant que clients OpenVPN.
Les adresses IP des routeurs et les plages de serveurs DHCP suivantes ont été choisies :
- 192.168.10.1 avec la plage 192.168.10.2 — 192.168.10.80 pour le serveur
- 192.168.10.100 avec la plage 192.168.10.101 — 192.168.10.149 pour le routeur dans l'appartement n°2
- 192.168.10.150 avec la plage 192.168.10.151 — 192.168.10.199 pour le routeur dans l'appartement n°3
Il était également nécessaire d'attribuer ces adresses aux routeurs clients du serveur OpenVPN, en ajoutant dans sa configuration la ligne :
ifconfig-pool-persist /etc/openvpn/ipp.txt 0et en ajoutant les lignes suivantes dans le 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 des appareils spécifiés lors de la création des certificats pour se connecter à OpenVPN
Ensuite, les clients OpenVPN ont été configurés sur les routeurs, avec les appareils tap0 des deux ajoutés au pont br-lan. À ce stade, tout semblait en ordre, car les trois réseaux se voient et fonctionnent comme un tout. Cependant, un détail désagréable est apparu : parfois, les appareils pouvaient obtenir une adresse IP qui n’était pas leur routeur, avec toutes les conséquences qui en découlent. Pour une raison quelconque, le routeur dans un des appartements ne parvenait pas à répondre à temps au DHCPDISCOVER et l'appareil recevait une adresse qui n'était pas la sienne. J'ai compris que je devais filtrer de telles demandes dans tap0 sur chacun des routeurs, mais, comme il s'est avéré, iptables ne peut pas fonctionner avec un appareil s'il est partie d'un pont, et ebtables devait m'aider. Malheureusement, il n'était pas présent dans mes firmwares, et j'ai dû reconstruire les images pour chaque appareil. Après cela, et en ajoutant ces lignes dans /etc/rc.local de chaque routeur, le problème était 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 : Découverte de WireGuard
Récemment, WireGuard est de plus en plus mentionné sur Internet, loué pour la simplicité de sa configuration, sa grande vitesse de transmission et son faible ping avec une sécurité comparable. La recherche d'informations supplémentaires à son sujet m'a fait comprendre que ni le fonctionnement en tant que membre d'un pont, ni le fonctionnement via le protocole TCP n'étaient pris en charge, ce qui m'a amené à penser qu'il n'y avait toujours pas d'alternatives à OpenVPN pour moi. Ainsi, j'avais retardé ma découverte de WireGuard.
Il y a quelques jours, une nouvelle a circulé sur les ressources liées à l'informatique, annonçant que WireGuard serait enfin intégré au noyau Linux, à partir de la version 5.6. Les articles de presse, comme toujours, faisaient l'éloge de WireGuard. Je me suis replongé dans la recherche de solutions de remplacement pour le bon vieux OpenVPN. Cette fois-ci, je suis tombé sur . Dans cet article, il était question de créer un tunnel Ethernet sur L3 à l'aide de GRE. Cet article m'a donné de l'espoir. Il restait cependant flou quant à la gestion du protocole UDP. Mes recherches me conduisaient vers des articles sur l'utilisation de socat en combinaison avec un tunnel SSH pour le transfert de port UDP, mais il était noté que cette approche ne fonctionnait qu'en mode de connexion unique, rendant impossible l'utilisation de plusieurs clients VPN. J'ai eu l'idée de mettre en place un serveur VPN sur un VPS, et de configurer GRE pour les clients, mais, comme il s'est avéré, GRE ne prend pas en charge le chiffrement, ce qui signifie qu'en cas d'accès au serveur par des tiers, tout le trafic entre mes réseaux serait exposé, ce qui ne m'enchantait guère.
J'ai donc de nouveau opté pour un chiffrement redondant, en utilisant un VPN sur un VPN selon le schéma suivant :
VPN de premier niveau :
VPS est serveur avec l'adresse interne 192.168.30.1
MC est client VPS avec l'adresse interne 192.168.30.2
MC2 est client VPS avec l'adresse interne 192.168.30.3
MC3 est client VPS avec l'adresse interne 192.168.30.4
VPN de second niveau :
MC est serveur avec l'adresse externe 192.168.30.2 et l'adresse interne 192.168.31.1
MC2 est client MC avec l'adresse 192.168.30.2 et a un IP interne 192.168.31.2
MC3 est client MC avec l'adresse 192.168.30.2 et a un IP interne 192.168.31.3
* MC — routeur-serveur dans l'appartement 1, MC2 — routeur dans l'appartement 2, MC3 — routeur dans l'appartement 3
* Les configurations des appareils sont publiées dans un spoiler à la fin de l'article.
Et donc, les pings entre les nœuds du réseau 192.168.31.0/24 fonctionnent, il est temps de passer à la configuration du tunnel GRE. Avant cela, afin de ne pas perdre l'accès aux routeurs, il est préférable de configurer des tunnels SSH pour le transfert du port 22 sur le VPS, de sorte que, par exemple, le routeur de l'appartement 2 soit accessible sur le port 10022 du VPS, et le routeur de l'appartement 3 sur le port 11122. Il est préférable de réaliser cette configuration de transfert avec sshtunnel, car il rétablira le tunnel en cas de chute.
Le tunnel est configuré, vous pouvez vous connecter à SSH via le port transféré :
ssh root@MON_VPS -p 10022Ensuite, il convient de désactiver OpenVPN :
/etc/init.d/openvpn stopMaintenant, configurons le tunnel GRE 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 grelan0 up
Et ajoutons l'interface créée au pont :
brctl addif br-lan grelan0
Nous effectuerons la même procédure 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, également, ajoutons l'interface créée au pont :
brctl addif br-lan grelan0
À partir de ce moment, les pings commencent à passer avec succès dans le nouveau réseau et je pars, satisfait, boire un café. Ensuite, pour évaluer comment fonctionne le réseau de l'autre côté, j'essaie de me connecter par SSH à un des ordinateurs dans l'appartement 2, mais le client ssh « bloque », ne proposant pas de saisir un mot de passe. J'essaie de me connecter à cet ordinateur via telnet sur le port 22 et je vois une ligne qui indique que la connexion s'établit, le serveur SSH répond, mais pour une raison quelconque, ne me permet pas de me connecter.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
J'essaie de me connecter à lui via VNC et je vois un écran noir. Je me persuade que le problème vient de l'ordinateur distant, car je peux me connecter au routeur de cet appartement via l'adresse interne. Cependant, je décide de me connecter en SSH à cet ordinateur via le routeur et découvre avec étonnement que la connexion réussit, et l'ordinateur distant fonctionne normalement, mais ne peut également pas se connecter à mon ordinateur.
Je retire l'appareil grelan0 du pont et lance OpenVPN sur le routeur dans l'appartement 2, et je constate que le réseau fonctionne à nouveau correctement et que les connexions ne se coupent pas. Je tombe sur des forums où des gens se plaignent de problèmes similaires, où il leur est conseillé d'augmenter le MTU. Dit et fait. Cependant, tant que le MTU n'était pas suffisamment élevé — 7000 pour les dispositifs gretap, il y avait soit des coupures de connexions TCP, soit une faible vitesse de transmission. En raison du MTU élevé pour gretap — le MTU pour les connexions WireGuard de premier et deuxième niveau ont été fixés à 8000 et 7500 respectivement.
J'ai effectué une configuration similaire sur le routeur de l'appartement 3, avec la seule différence qu'un deuxième interface gretap nommé grelan1 a été ajouté sur le routeur serveur, qui a également été ajouté au pont br-lan.
Tout fonctionne. Maintenant, je peux placer le montage gretap dans le démarrage automatique. Pour cela :
J'ai placé ces lignes dans /etc/rc.local sur le routeur dans 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 7000
ip link set grelan0 up
brctl addif br-lan grelan0
J'ai ajouté ceci dans /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 7000
ip link set grelan0 up
brctl addif br-lan grelan0
Et sur le routeur-serveur :
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
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 7000
ip link set grelan1 up
brctl addif br-lan grelan1
Après avoir redémarré les routeurs clients, j'ai découvert qu'ils ne se connectaient pas au serveur pour une raison quelconque. En me connectant à leur SSH (heureusement, j'avais préalablement configuré sshtunnel pour cela), il a été constaté que WireGuard crée pour une raison quelconque une route pour l'endpoint, et cette route est incorrecte. Ainsi, pour 192.168.30.2, la table de routage indiquait une route via l'interface pppoe-wan, c'est-à-dire via Internet, alors que la route vers cette adresse devait être dirigée via l'interface wg0. Après avoir supprimé cette route, la connexion a été rétablie. Je n'ai pas réussi à trouver des instructions sur comment empêcher WireGuard de créer ces routes. De plus, je n'ai même pas compris si c'était une spécificité d'OpenWRT ou de WireGuard lui-même. Ne voulant pas passer trop de temps sur ce problème, j'ai simplement ajouté sur les deux routeurs dans un script en boucle par minute, la ligne qui supprimait cette route :
route del 192.168.30.2
En résumé
Je n'ai pas encore abandonné complètement OpenVPN, car j'ai parfois besoin de me connecter à un nouveau réseau avec mon ordinateur portable ou mon téléphone, et la configuration de l'appareil gretap sur eux est généralement impossible, mais malgré cela, j'ai gagné en vitesse de transmission de données entre les appartements et, par exemple, l'utilisation de VNC ne pose plus de problèmes. 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é vers le VPS, qui est d'environ 61,5 ms.
Cependant, la vitesse a considérablement augmenté. Ainsi, dans l'appartement avec le routeur-serveur, j'ai une vitesse de connexion Internet de 30 Mbit/s, tandis que dans les autres appartements, c'est 5 Mbit/s. En outre, lors de l'utilisation de OpenVPN, je n'ai pas réussi à atteindre une vitesse de transfert de données entre les réseaux supérieure à 3,8 Mbit/s selon les relevés d'iperf, tandis que WireGuard a « propulsé » cette vitesse jusqu'à 5 Mbit/s.
Configuration de WireGuard sur VPS[Interface]
Adresse = 192.168.30.1/24
Port d'écoute = 51820
Clé privée =
[Peer]
PublicKey =
AllowedIPs = 192.168.30.2/32
[Peer]
PublicKey =
AllowedIPs = 192.168.30.3/32
[Peer]
PublicKey =
AllowedIPs = 192.168.30.4/32
Configuration de WireGuard sur MS (ajoutée dans /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'
option mtu '8000'
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 '7500'
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 dans /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'
option mtu '8000'
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 '7500'
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 de WireGuard sur MK3 (ajoutée dans /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'
option mtu '8000'
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 '7500'
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 second niveau, j'indique aux clients WireGuard le port 51821. En théorie, cela n'est pas nécessaire, car le client établira une connexion à partir de n'importe quel port non privilégié libre, mais j'ai fait cela pour pouvoir interdire toutes les connexions entrantes sur les interfaces wg0 de tous les routeurs, sauf les connexions UDP entrantes sur le port 51821.
J'espère que cet article sera utile à quelqu'un.
P.S. De plus, je souhaite partager mon script qui m'envoie une notification PUSH sur mon téléphone via l'application WirePusher lorsque de nouveaux appareils apparaissent sur mon réseau. Voici le lien vers le script : .
MISE À JOUR : Configuration du serveur OpenVPN et des clients
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-lzoClient OpenVPN
client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Changez l'IP externe de votre routeur
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 J'ai utilisé easy-rsa pour générer les certificats.
Source : habr.com
