Je voudrais partager mon expérience de combinaison de réseaux dans trois appartements géographiquement éloignés, chacun utilisant des routeurs avec OpenWRT comme passerelle, dans un réseau commun. Lors du choix d'une méthode pour combiner des réseaux entre L3 avec routage de sous-réseau et L2 avec pontage, lorsque tous les nœuds du réseau seront dans le même sous-réseau, la préférence a été donnée à la deuxième méthode, qui est plus difficile à configurer, mais offre plus d'opportunités, car transparent l'utilisation des technologies était prévue dans le réseau créé Wake-on-Lan et DLNA.
Partie 1 : Contexte
OpenVPN a été initialement choisi comme protocole pour implémenter cette tâche, car, premièrement, il peut créer un périphérique de prise qui peut être ajouté au pont sans aucun problème, et deuxièmement, OpenVPN prend en charge le fonctionnement sur le protocole TCP, ce qui était également important, car aucun des appartements n'avait d'adresse IP dédiée, et je n'ai pas pu utiliser STUN, car pour une raison quelconque, mon FAI bloque les connexions UDP entrantes de leurs réseaux, tandis que le protocole TCP m'a permis de transférer le port du serveur VPN sur les VPS loués en utilisant SSH. Oui, cette approche donne une grosse charge, puisque les données sont cryptées deux fois, mais je ne voulais pas introduire le VPS dans mon réseau privé, car il y avait toujours 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 une surcharge importante.
Pour rediriger le port du 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 transférer le port TCP 1194 du routeur vers le VPS. Ensuite, le serveur OpenVPN a été configuré sur l'appareil tap0, qui était connecté au pont br-lan. Après avoir vérifié la connexion au serveur nouvellement créé à partir de l'ordinateur portable, il est devenu clair que l'idée de la redirection de port se justifiait et mon ordinateur portable est devenu membre du réseau du routeur, même s'il n'y était pas physiquement.
L'affaire restait petite: il fallait répartir les adresses IP dans différents appartements pour qu'elles n'entrent pas en conflit et configurer les routeurs en tant que clients OpenVPN.
Les adresses IP de routeur et les plages de serveurs DHCP suivantes ont été sélectionnées :
- 192.168.10.1 avec gamme 192.168.10.2 - 192.168.10.80 pour le serveur
- 192.168.10.100 avec gamme 192.168.10.101 - 192.168.10.149 pour un routeur dans l'appartement n ° 2
- 192.168.10.150 avec gamme 192.168.10.151 - 192.168.10.199 pour un routeur dans l'appartement n ° 3
Il fallait aussi attribuer exactement ces adresses aux routeurs clients du serveur OpenVPN en ajoutant la ligne à sa configuration :
ifconfig-pool-persist /etc/openvpn/ipp.txt 0et 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érique spécifiés lors de la génération de certificats pour la connexion à OpenVPN
Ensuite, les clients OpenVPN ont été configurés sur les routeurs, les périphériques tap0 des deux ont été ajoutés au pont br-lan. A ce stade, tout semblait en ordre puisque les trois réseaux se voient et fonctionnent comme un tout. Cependant, un détail pas très agréable s'est avéré : parfois, les appareils pouvaient obtenir une adresse IP ne provenant pas de leur routeur, avec toutes les conséquences qui en découlent. Pour une raison quelconque, le routeur de l'un des appartements n'a pas eu le temps de répondre à DHCPDISCOVER à temps et l'appareil a reçu la mauvaise adresse. J'ai réalisé que je devais filtrer de telles requêtes dans tap0 sur chacun des routeurs, mais il s'est avéré qu'iptables ne peut pas fonctionner avec un périphérique s'il fait partie d'un pont et ebtables devrait venir à mon aide. A mon grand regret, ce n'était pas dans mon firmware et j'ai dû reconstruire les images pour chaque appareil. En faisant cela et en ajoutant ces 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
Depuis peu, Internet parle de plus en plus de WireGuard, admirant la simplicité de sa configuration, sa vitesse de transfert élevée, son faible ping avec une sécurité comparable. En cherchant plus d'informations à ce sujet, il est apparu clairement que ni le travail en tant que membre du pont ni le travail sur le protocole TCP n'est pris en charge par celui-ci, ce qui m'a fait penser qu'il n'y a toujours pas d'alternative à OpenVPN pour moi. J'ai donc reporté l'apprentissage de WireGuard.
Il y a quelques jours, la nouvelle s'est répandue à travers des ressources liées d'une manière ou d'une autre à l'informatique que WireGuard sera enfin inclus dans le noyau Linux, à partir de la version 5.6. Les articles de presse, comme toujours, ont fait l'éloge de WireGuard. Je me suis à nouveau plongé dans la recherche de moyens de remplacer le bon vieux OpenVPN. Cette fois je suis tombé sur . Il parlait de créer un tunnel Ethernet sur L3 en utilisant GRE. Cet article m'a redonné espoir. On ne savait toujours pas quoi faire avec le 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, ce qui signifie que plusieurs clients VPN seraient impossibles. J'ai eu l'idée de configurer un serveur VPN sur un 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 entraînera le fait que si des tiers accèdent au serveur, tout le trafic entre mes réseaux est entre leurs mains, ce qui ne me convenait pas du tout.
Encore une fois, la décision a été prise en faveur du chiffrement redondant, en utilisant VPN sur VPN selon le schéma suivant :
VPN de couche XNUMX :
VPS il est serveur avec adresse interne 192.168.30.1
MS il est par client VPS avec adresse interne 192.168.30.2
MK2 il est par client VPS avec adresse interne 192.168.30.3
MK3 il est par client VPS avec adresse interne 192.168.30.4
VPN de couche XNUMX :
MS il est serveur avec adresse externe 192.168.30.2 et interne 192.168.31.1
MK2 il est par client MS avec l'adresse 192.168.30.2 et a une adresse IP interne de 192.168.31.2
MK3 il est par client MS avec l'adresse 192.168.30.2 et a une adresse IP interne de 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 mise en place du tunnel GRE. Avant cela, afin de ne pas perdre l'accès aux routeurs, il convient de configurer des tunnels SSH pour rediriger le port 22 vers le VPS, afin que, par exemple, un routeur de l'appartement 10022 soit disponible sur le port 2 du VPS, et un le routeur de l'appartement 11122 sera disponible sur le port 3 du VPS routeur de l'appartement XNUMX. Il est préférable de configurer la redirection avec le même sshtunnel, car il restaurera le tunnel en cas de chute.
Le tunnel est configuré, vous pouvez vous connecter en SSH via le port redirigé :
ssh root@МОЙ_VPS -p 10022Ensuite, désactivez OpenVPN :
/etc/init.d/openvpn stopConfigurons maintenant un 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 ajoutez l'interface créée au pont :
brctl addif br-lan grelan0
Effectuons une procédure similaire sur le routeur du serveur :
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Et, également, ajoutez l'interface créée au pont :
brctl addif br-lan grelan0
à partir de ce moment, les pings commencent à aller avec succès vers le nouveau réseau et moi, avec satisfaction, je vais boire du café. Ensuite, pour voir comment fonctionne le réseau à l'autre bout du fil, j'essaie de me connecter en SSH à l'un des ordinateurs de l'appartement 2, mais le client ssh se bloque sans me demander de mot de passe. J'essaie de me connecter à cet ordinateur via telnet sur le port 22 et vois une ligne à partir de laquelle vous pouvez comprendre que la connexion est en cours d'établissement, le serveur SSH répond, mais pour une raison quelconque, il ne me propose pas d'entrer.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
J'essaie de me connecter via VNC et je vois un écran noir. Je me convainc que le problème se trouve dans l'ordinateur distant, car je peux facilement me connecter au routeur depuis cet appartement en utilisant l'adresse interne. Cependant, je décide de me connecter en SSH à cet ordinateur via le routeur et je suis surpris de constater que la connexion réussit et que l'ordinateur distant fonctionne correctement mais ne parvient pas non plus à se connecter à mon ordinateur.
Je sors le périphérique grelan0 du pont et démarre OpenVPN sur le routeur de l'appartement 2 et m'assure que le réseau fonctionne à nouveau correctement et que les connexions ne sont pas interrompues. En cherchant, je tombe sur des forums où les gens se plaignent des mêmes problèmes, où il leur est conseillé d'augmenter le MTU. À peine dit que c'était fait. Cependant, jusqu'à ce que le MTU soit défini sur une valeur suffisamment grande de 7000 pour les périphériques gretap, des connexions TCP interrompues ou des transmissions lentes ont été observées. En raison de la MTU élevée pour gretap, les MTU des connexions WireGuard des premier et deuxième niveaux ont été définies sur 8000 7500 et XNUMX XNUMX, respectivement.
J'ai fait une configuration similaire sur le routeur de l'appartement 3, à la seule différence qu'une deuxième interface gretap nommée grelan1 a été ajoutée au routeur du serveur, qui a également été ajouté au pont br-lan.
Tout fonctionne. Vous pouvez maintenant mettre l'assemblage gretap en chargement automatique. Pour ça:
Placé 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 7000
ip link set grelan0 up
brctl addif br-lan grelan0
Ajouté ceci à /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 du 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 constaté que, pour une raison quelconque, ils ne se connectaient pas au serveur. En se connectant à leur SSH (heureusement, j'avais précédemment configuré sshtunnel pour cela), il a été découvert que WireGuard, pour une raison quelconque, crée une route pour le point de terminaison, tout en étant incorrect. Ainsi, pour 192.168.30.2, la table de routage a été spécifiée dans la table de routage via l'interface pppoe-wan, c'est-à-dire via Internet, bien que la route vers celle-ci aurait dû être dirigée via l'interface wg0. Après la suppression de cette route, la connexion a été restaurée. Je n'ai trouvé nulle part d'instructions sur la façon de forcer WireGuard à ne pas créer ces routes. De plus, je n'ai même pas compris s'il s'agissait d'une fonctionnalité d'OpenWRT ou de WireGuard lui-même. Sans avoir à me préoccuper longtemps de ce problème, j'ai simplement ajouté aux deux routeurs dans un script bouclé par un timer, une ligne qui supprimait cette route :
route del 192.168.30.2
Résumant
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 il est généralement impossible de configurer un appareil gretap dessus, mais malgré cela, j'ai obtenu un avantage dans le transfert de données la vitesse entre les appartements et, par exemple, l'utilisation de VNC n'est plus gênante. Le ping a légèrement diminué, mais est devenu plus stable :
Lorsque vous utilisez 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 principalement affecté par un ping élevé vers VPS qui est d'environ 61.5 ms
Cependant, la vitesse a considérablement augmenté. Ainsi, dans un appartement avec un routeur-serveur, j'ai une vitesse de connexion Internet de 30 Mbps, et dans d'autres appartements, 5 Mbps. Dans le même temps, en utilisant OpenVPN, je ne pouvais pas atteindre un taux de transfert de données entre les réseaux de plus de 3,8 Mbps selon iperf, tandis que WireGuard le "gonflait" jusqu'au même 5 Mbps.
Configuration 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 WireGuard sur MS (ajouté à /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 WireGuard sur MK2 (ajouté à /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 WireGuard sur MK3 (ajouté à /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 deuxième niveau, je spécifie le port 51821 aux clients WireGuard. En théorie, ce n'est pas nécessaire, car le client établira une connexion à partir de n'importe quel port libre non privilégié, mais j'ai fait en sorte que toutes les connexions entrantes peut être refusé sur les interfaces wg0 de tous les routeurs, à l'exception des connexions UDP entrantes sur le port 51821.
J'espère que l'article sera utile à quelqu'un.
PS De plus, je souhaite partager mon script qui m'envoie une notification PUSH sur mon téléphone dans l'application WirePusher lorsqu'un nouveau périphérique apparaît sur mon réseau. Voici un lien vers le script : .
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-lzoClient 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
J'ai utilisé easy-rsa pour générer des certificats.
Source: habr.com