Exit la box opérateur partie 3
Table of contents
Avant d'aller plus loin dans la technique...
Résumé de l'épisode précédent
Dans la seconde partie nous avons vu comment mettre en place les différents services au sein de notre routeur qui vont permettre de sécuriser et rendre disponible l'accès aux clients connectés sur les différents liens. - La sécurité s'effectue via le pare-feu iptables, qui va autoriser ou non des ips, flux et autres connexions entre les différents sous réseaux. Il va également prendre en charge le NAT/PAT pour permettre de mettre à disposition un port donné de manière temporaire. - Les services DHCP et DNS permettront respectivement de mettre à disposition une adresse ip à un client local et de gérer la résolution de noms sur internet. - Enfin cerise sur le gâteau l'installation de piHole, qui permettra de bloquer les requêtes depuis votre réseau vers la toile.
Que peut on faire de plus?
Maintenant j'aimerais accéder à mon super nouveau réseau local depuis le net. Sans rentrer trop dans les détails, deux choix s'offrent à moi: - j'ouvre des ports sur mon interface WAN, et je redirige ceux ci vers les services souhaités (un serveur web, mon synology, un accès ssh...) -- simple à mettre en place -- ouvert à toutes les tentatives d'intrusion - je mets en place un VPN qui me permettra d'interconnecter un réseau virtuel à mon réseau local, donc finalement d'étendre celui ci de manière sécurisée en passant par des réseaux publics.
Les deux solutions sont compatibles, et je peux choisir par exemple d'ouvrir un serveur Web pour tout le monde et de restreindre les autres services à mon VPN. Allons y déjà pour le VPN!
En avant le déploiement...de WireGuard
Dans le petit monde des VPN, il n'y a pas beaucoup de prétendants hormis l'inébranlable IPsec et le plus récent et plus lourd OpenVPN. Un petit nouveau a cependant fait son trou il y a quelques années et a tellement la cote qu'il a réussi à être intégré au noyau linux en un temps record!
Simple et sécurisé, il associe bonne performance et accès simplifié tant niveau serveur que pour les clients, ce que nous verrons dans la suite de cette article. Pour l'utiliser depuis un an (pas de manière intensive je vous l'accorde) je n'ai jamais eu aucun souci notable avec...ça sent bon l'outil qui va (enfin?) détrôner IPsec?
Je ne vous fait pas l'affront de vous indiquer comment fonctionne un VPN, de nombreux écrits sur ce thème. Clubic qui revient sur le devant de la scène avec des articles rédigés par des vrais-personnes-qui-font-de-l'informatique a un article ici à son sujet.
Comment ça se passe coté serveur?
Sur Debian depuis la bullseye , wireguard est disponible sur les dépôts officiels donc aucune difficulté pour l'installation. Si vous êtes sur une version plus ancienne il faudra peut être activer les backports pour pouvoir en profiter.
Comme précédemment indiqué, il a été intégré au kernel donc une grande partie des distributions doivent le proposer nativement:
root@router-debian:~# apt install wireguard
Il faudra ensuite générer une paire de clés publique/privée, un outil a été mis à disposition
wg genkey | tee /etc/wireguard/wg-private.key | wg pubkey | tee /etc/wireguard/wg-public.key
Il est ensuite nécessaire d'indiquer la clé privée dans le fichier de configuration qui permettra la création de l'interface virtuelle:
nano /etc/wireguard/wg0.conf
Son contenu:
[Interface]
Address = 10.10.0.1/24 # Ip de mon interface serveur
SaveConfig = true
PostUp = # permet la mise en place de règles iptables au lancement du service
PostDown = # suppression des règles lorsque le vpn est arrêté
ListenPort = 51820 # port en écoute
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Enfin pour lancer wireguard, lancer la commande:
wg-quick up wg0
Et voilà, rien de plus! on vérifie que l'interface est bien en écoute via un ip add, c'est tout bon:
42: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.10.0.1/24 scope global wg0
valid_lft forever preferred_lft forever
Une seconde commande permet également d'avoir un retour d'informations intéressantes:
wg show wg0
On y voit le nom de l'interface, la clé publique, le port en écoute et les clients (peer) qu'on va paramétrer dans la suite de cette article:
interface: wg0
public key: XXXXXXXXXXXXXXh0mOvRyrg0lL7KdDSGI5qq2g=
private key: (hidden)
listening port: 51820
peer: SvSrk+8Clm8SMYiFAJTit/XXXXXXXXXXXXXXXX
endpoint: 1.2.3.4:45597
allowed ips: 10.10.0.2/32
peer: pPtZM+B1KnUtsz92e6cRiyDIXXXXXXXXXXXXXXXXXX
endpoint: 1.2.3.5:63442
allowed ips: 10.10.0.3/32
Enfin dernière chose si vous souhaitez que le service soit lancé lors du lancement de votre routeur:
systemctl enable wg-quick@wg0.service
Il restera d'une part à ouvrir le port sur l'interface WAN pour que le routeur puisse accepter les requêtes des clients, mais également d'autre part à modifier les règles de routage pour que le nouveau réseau 10.10.X.X puisse être correctement acheminé. Mais avant passons au paramétrage des clients...
Comment ça se passe coté client?
Wireguard vise large et permet d'installer un client que ce soit sur du Windows, Linux, Android ou encore iOS.
Quelle que soit l'OS, le principe est le même: - On installe le client - Puis on créé le fichier de configuration en indiquant l’IP du client à utiliser sur le VPN (ici 10.10.0.X) - Enfin une clé publique est générée, il faudra ensuite l'autoriser coté serveur
Exemple du fichier créé:
[Interface]
PrivateKey = XXXXXXXXXXXXX
Address = 10.10.0.2/32
DNS = 10.10.0.1
[Peer]
PublicKey = XXXXXXXXXXXX
AllowedIPs = 0.0.0.0/0
Endpoint = xx.xx.xx.xx:51820
PersistentKeepalive = 20
Pour faire simple: - le PrivateKey est la clé privée du client générée automatiquement - le PublicKey est la clé publique du serveur - Endpoint l'ip publique / nom de domaine du serveur Wireguard en écoute - AllowedIPs va permettre de rediriger tout le trafic (0.0.0.0/0) ou simplement les requêtes à destination de mon réseau local (10.10.0.0,192.168.1.0/24,192.168.2.0/24) via le tunnel nouvellement monté.
Il faudra enfin indiquer coté serveur la clé publique du client:
wg set wg0 peer ClientPublicKey allowed-ips 10.10.0.2
Vous voilà fin prêt à monter votre tunnel, vous pouvez vérifier une fois le client connecté, avec la commande indiquée en fin de premier paragraphe.
Trafic et choix de sécurité
Adios DNAT, vive le routage
Une précision avant d'attaquer les règles iptables. Dans le cas présent j'ai deux options pour permettre la bonne distribution de mes requêtes. - Soit je fais du NAT/PAT sur l'ip de ma passerelle VPN (ici 10.10.0.1) et je redirige vers le service souhaité, ce qui donne un truc du genre:
iptables -t nat -A PREROUTING -p tcp --dport 5001 -j DNAT --to-destination 192.168.2.2:5001
avec également ouverture des ports qui vont bien
- Soit je simplifie la démarche et m'appuie sur le routage. En effet on vient de créer une nouvelle interface réseau, et il n'est pas utile de faire du DNAT sur une interface interne. Il suffit simplement d'ouvrir les ports que vont bien depuis/vers le réseau 10.10.x.x et ça passera sans problème.
Je m'oriente sur cette seconde option, exemple de mes ajouts au script iptables dans la partie suivante.
On modifie iptables selon nos désirs
Une autre précision sur comment gérer les règles iptables.
Wireguard permet de mettre en place des règles à la volée à partir du fichier de configuration (dans cet exemplemnt wg0.conf) via les paramètres PostUp et PostDown.
- Ça peut être très pratique si par exemple vous souhaitez que certaines règles liées à la montée du VPN supplantent celles déjà en place (règles icmp, ouverture de ports jusqu'à là non autorisées...).
- Ces mesures seront automatiquement supprimées lorsque le tunnel ne sera plus actif.
Pour ma part je n'ai pas choisi de faire ainsi, mais j'ai simplement rajouté mes règles iptables dans mon script initial. En effet je préfère avoir toutes les règles sous les yeux, avec donc l'inconvénient qu'elles sont constantes.
Premièrement coté WAN je n'ouvre plus qu'un port, celui permettant de contacter le serveur wireguard:
iptables -A INPUT -i eno1 -p udp --dport 51820 -j ACCEPT
Fini les scans de ports obstentatoires, même si avec crowdsec la sécurité était grandement améliorée (tient ça vaudrait le coup d'en faire un article...)
Puis je permet à mes clients connectés en VPN d'accéder à certains services, coté DMZ comme LAN.
Quelques exemples pour vous donner une idée:
#VPN
iptables -A INPUT -i wg0 -p tcp -d 192.168.1.1 --dport 22 -j ACCEPT # accès ssh sur ma patte LAN
iptables -A FORWARD -i wg0 -d 192.168.2.0/24 -j ACCEPT # accès au sous réseau 192.168.2.X
iptables -A FORWARD -i wg0 -p tcp -d 192.168.1.30 --dport 80 -j ACCEPT # accès en http sur une seule ip
iptables -A FORWARD -s 10.10.0.0/24 -d 0.0.0.0/0 -j DROP # je refuse tout ce qui vient des clients à destination d'internet
Enfin je permet à ma nouvelle classe d'ip d'être nattée d'une interface à l'autre, comme vu dans le précédent article du SNAT:
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
Et voilà, comme à la maison! On peut prendre en main via ssh son routeur via un tunnel (ceinture-bretelles, on est jamais trop prudent), consulter sa page domotique ou encore accéder à ses vidéos depuis Plex sans lag ou presque. Pour avoir testé openvpn qui ne répondait que trop peu à ce genre d'usage, wireguard fait parfaitement le taff.
Et pour finir...
C'est la fin de la rédaction de ces 3 articles qui ont eu pour but de vous éclairer sur la mise en place d'un routeur maison avec des services fiables et sécurisés.
Tout n'est certainement pas nickel, n'hésitez pas à commenter sur les points qui vous semblent à parfaire. Encore une fois je tourne sur une solution homemade depuis plus d'un an maintenant, et je n'ai eu que très rarement des problèmes (souvent liés à mes gros doigts qui tapent à coté...) Le grand intérêt au delà de la sécurité c'est d'ajouter des briques logicielles dès que nécessaire pour avoir un accès qui vous corresponde complètement, bande de geek.
@ bientôt sur la toile!