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
Le protocole choisi pour mettre en œuvre cette tâche était initialement OpenVPN, car, premièrement, il permet de créer un dispositif de prise qui peut être ajouté au pont sans aucun problème, et deuxièmement, OpenVPN Il prend en charge TCP, ce qui était essentiel car aucun des appartements ne disposait d'une adresse IP dédiée. Je ne pouvais pas utiliser STUN car mon FAI bloque, pour une raison inconnue, les connexions UDP entrantes sur son réseau. TCP m'a permis de rediriger le port du serveur VPN vers le VPS loué via SSH. Bien que cette solution engendre une surcharge importante, les données étant doublement chiffrées, je ne souhaitais pas intégrer le VPS à mon réseau privé, car il existait un risque de piratage. Par conséquent, la présence d'un tel appareil sur mon réseau domestique était fortement déconseillée ; j'ai donc opté pour un surcoût important en matière de sécurité.
Pour rediriger le port sur le routeur où le serveur devait être déployé, j'ai utilisé le programme sshtunnel. Je ne détaillerai pas sa configuration, car elle est très simple. Je préciserai simplement qu'il permet de rediriger le port TCP 1194 du routeur vers le VPS. Ensuite, j'ai configuré le serveur. OpenVPN Sur le périphérique tap0, connecté au pont br-lan, j'ai testé la connexion au serveur nouvellement créé depuis mon ordinateur portable. Il est alors apparu que la redirection de port avait fonctionné et que mon ordinateur portable était désormais membre du réseau du routeur, même s'il n'en faisait pas physiquement partie.
Il ne restait plus qu'à répartir les adresses IP dans les différents appartements afin d'éviter les conflits et à configurer les routeurs comme suit : OpenVPN-clients.
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 était également nécessaire d'attribuer ces adresses aux routeurs clients. OpenVPN-serveur, en ajoutant la ligne suivante à 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ériques spécifiés lors de la création des certificats de connexion à OpenVPN
Ensuite, les routeurs ont été configurés. OpenVPNLes périphériques tap0 des deux réseaux ont été ajoutés au pont br-lan. À ce stade, tout semblait fonctionner correctement, les trois réseaux étant visibles et fonctionnant comme une seule unité. Cependant, un problème plutôt gênant est apparu : il arrivait que des périphériques reçoivent une adresse IP du mauvais routeur, avec toutes les conséquences que cela implique. Pour une raison inconnue, le routeur de l'un des appartements n'a pas répondu à la requête DHCPDISCOVER à temps, et le périphérique a reçu une adresse incorrecte. J'ai compris qu'il me fallait filtrer ces requêtes dans l'interface tap0 de chaque routeur, mais il s'est avéré qu'iptables ne fonctionne pas avec un périphérique faisant partie d'un pont. J'ai donc dû utiliser ebtables. Malheureusement, mon firmware ne l'incluait pas, j'ai donc dû reconstruire les images pour chaque périphérique. Après cette opération et l'ajout des lignes suivantes au fichier /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 : Apprendre à connaître WireGuard
Ces derniers temps, on parle de plus en plus sur Internet de WireGuardJ'appréciais sa facilité de configuration, sa vitesse de transfert élevée, son faible ping et sa sécurité comparable. Une recherche d'informations complémentaires a révélé qu'il ne prenait en charge ni les membres de pont ni le protocole TCP, ce qui m'a fait croire qu'il n'existait aucune alternative. OpenVPN Pour moi, ce n'est toujours pas le cas. Alors j'ai repoussé le moment de faire connaissance. WireGuard.
Il y a quelques jours, une nouvelle s'est répandue, via des sources liées de près ou de loin au secteur informatique, selon laquelle WireGuard sera finalement inclus dans le noyau Linux, à partir de la version 5.6. Les articles d'actualité, comme toujours, ont été salués. WireGuardJe me suis de nouveau plongé dans la recherche de moyens de remplacer le bon vieux OpenVPNCette 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, vous devriez désactiver 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 retire le périphérique grelan0 du pont et je l'exécute. OpenVPN Sur le routeur de l'appartement 2, j'ai vérifié que le réseau fonctionnait de nouveau correctement et que les connexions étaient stables. En cherchant des informations, je suis tombé sur des forums où des utilisateurs se plaignaient des mêmes problèmes et où il leur était conseillé d'augmenter la MTU. Aussitôt dit, aussitôt fait. Cependant, tant que la MTU n'était pas suffisamment élevée (7000 pour les périphériques gretap), je subissais des déconnexions TCP ou des débits de transfert très faibles. En raison de la MTU élevée pour gretap, la MTU des connexions WireGuard Les premier et deuxième niveaux ont été fixés respectivement à 8000 et 7500.
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é qu'ils ne se connectaient pas au serveur. Après m'être connecté à leur interface SSH (heureusement, j'avais préalablement configuré sshtunnel), j'ai découvert que… WireGuard Pour une raison inconnue, une route est créée pour le point de terminaison, mais elle est incorrecte. Par exemple, pour 192.168.30.2, la table de routage spécifie une route via l'interface pppoe-wan, c'est-à-dire via Internet, alors que la route aurait dû passer par l'interface wg0. Après avoir supprimé cette route, la connexion a été rétablie. Existe-t-il des instructions pour forcer la configuration de la route ? WireGuard Je n'ai pas pu éviter de créer ces routes. De plus, je ne savais même pas si c'était une fonctionnalité d'OpenWRT ou de… WireGuardSans passer trop de temps à résoudre le problème, j'ai simplement ajouté une ligne au script de boucle de minuterie sur les deux routeurs qui supprimait cette route :
route del 192.168.30.2
Résumant
Rejet total OpenVPN Je n'y suis pas encore parvenu, car il m'arrive de devoir me connecter à un nouveau réseau depuis un ordinateur portable ou un téléphone, et configurer un périphérique gretap sur ces appareils est généralement impossible. Cependant, malgré cela, j'ai constaté une nette amélioration de la vitesse de transfert de données entre appartements, et l'utilisation de VNC, par exemple, est désormais très simple. Le ping a légèrement diminué, mais la connexion est devenue plus stable.
Lorsque vous utilisez le 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
Lorsque vous utilisez le 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 l'appartement équipé du routeur-serveur, je bénéficie d'une connexion internet de 30 Mbps, contre 5 Mbps dans les autres appartements. De plus, lors de l'utilisation OpenVPN Je n'ai pas pu atteindre une vitesse de transfert de données entre les réseaux supérieure à 3,8 Mbps selon les relevés d'iperf, alors que WireGuard l'a "boosté" à la même vitesse de 5 Mbit/s.
Configuration WireGuard sur VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Pair]
Clé publique = <CLÉ_PUBLIC_VPN_1_MS>
IP autorisés = 192.168.30.2/32
[Pair]
Clé publique = <CLÉ_PUBLIC_VPN_2_MK2>
IP autorisés = 192.168.30.3/32
[Pair]
Clé publique = <CLÉ_PUBLIC_VPN_2_MK3>
IP autorisés = 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, j'indique aux clients WireGuard Port 51821. Cela ne devrait pas être nécessaire, car le client établira une connexion à partir de n'importe quel port libre et non privilégié, mais je l'ai fait de cette façon afin de pouvoir refuser toutes les connexions entrantes sur les interfaces wg0 de tous les routeurs, à l'exception des connexions UDP entrantes vers 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 OpenVPN-serveurs et clients
OpenVPN-serveur
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-lzoOpenVPN-client
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
