Bonjour ;
j'ai eu beaucoup de mal à réaliser une connexion VPN bridgée vers ma Freebox V6, voici donc comment au final comment j'y suis parvenu (c'est certainement améliorable).
Tout d'abord, il faut savoir que la Freebox V6 (ou Freebox révolution) propose un serveur OpenVPN : dans l'interface de gestion, Paramètres de la Freebox / Serveur VPN . Il faut définir un utilisateur, et quatre services de serveur VPN sont proposés : IPsec IKEv2, PPTP, OpenVPN Routé, et OpenVPN Bridgé. Je ne me souviens plus très bien, mais je crois que PPTP est fortement déconseillé ; en tous cas en ce qui me concerne c'est OpenVPN bridgé qui m'intéressait. En effet le mode routé est une encapsulation de la couche OSI 3, la machine distante est donc intégrée au réseau local grâce à une nouvelle adresse IP ; tandis que le mode ponté est une encapsulation de la couche OSI 2, c'est donc avec une adresse MAC qu'on intègre une machine, qui se retrouve donc dans le réseau local quasiment exactement de la même manière que si elle y était physiquement — il y a sûrement quelques imprécisions dans cette description, mais en gros c'est à peu près ça.
À savoir aussi, qu'en mode routé, le flux internet sur la machine distante passe entièrement par la Freebox. Si on fait une vérification d'adresse IP depuis la machine distante une fois le VPN routé établi (genre
http://www.mon-ip.fr/ ), c'est celle de la Freebox que voient les sites. Cela peut être pratique pour surfer comme on veut depuis des endroits où certains sites sont empêchés (comme avec tous les service VPN proposés sur internet). Mais évidemment, la machine distante connectée à la Freebox par VPN, subit le très faible débit ascendant d'une connexion ADSL (130 ko/s dans mon cas, sur connexion ADSL2+ — le "A" de ADSL, c'est pour asynchrone, car la plupart de la bande passante est dédiée au flux descendant : quand on surfe, on envoie quelques caractères (= quelques octets, l'URL), pour recevoir des méga-octets, voire plus, de données).
Enfin l'interface Freebox permet de récupérer des fichiers de configuration .ovpn pour chacun des deux modes OpenVPN, ces fichiers de configuration permettant normalement au client de se connecter très simplement au serveur.
J'ai donc installé OpenVPN sur mon PC sous Ubuntu (Ubuntu Studio ; Linux 4.15.0-96-lowlatency #97-Ubuntu x86_64 GNU/Linux ; Ubuntu 18.04.4 LTS ; Xfce 4.12), c'est la version 2.4.4-2ubuntu1.3 qui est présente (alors que j'ai compilé et installé la version 2.4.9 :/, j'ai dû louper quelque chose). J'ai aussi installé les paquets
network-manager-openvpn et
network-manager-openvpn-gnome, pour pouvoir gérer les connexions OpenVPN avec des outils graphiques intégrés à Ubuntu.
Une fois les fichiers .ovpn importés, j'ai créé de nouvelles connexions avec le Network Manager d'Ubuntu : clic sur l'icône du réseau dans la barre des tâches, "Modifier les connexions", appui sur "+" dans la fenêtre "Connexions réseau" afin de créer une nouvelle entrée, et là dans la liste déroulante, "Importer une configuration VPN enregistrée", qui permet donc d'utiliser les fichiers .ovpn.
Le mode routé fonctionne de cette façon, mais pas le mode bridgé. Je suis un peu rentré dans les détails ; ci-dessous les résultats.
Lorsque le mode routé est actif, on peut voir dans les processus une très longue ligne pour le process openvpn : cet exécutable est lancé par le Network Manager, avec de très nombreuses options. À l'aide de la commande Linux ps, j'ai pu récupérer les process démarrés, avec toutes les options. Même si le mode bridgé s'arrête assez rapidement, on a quand même le temps de récupérer cela. Le mode routé est défini par l'option --tun alors que le mode bridgé l'est par l'option --tap. Le premier entraîne la création de l'élément virtuel "tun0" dans le dossier "/sys/devices/virtual/net/", tandis que le mode bridgé sera représenté par l'élément virtuel "tap0".
Je suis allé voir dans le fichier "/var/log/syslog" ce qui n'allait pas avec le mode bridgé.
Après pas mal de temps, j'ai pu relever les trois principaux problèmes suivants :
1. Il y a un message "Could not generate persistent MAC address for tap0: No such file or directory"
2. Il y a un message "VPN plugin: failed: bad-ip-config (2)"
3. Il y a un message "Failed running command (--up/--down): external program exited with error status: 1"
Après de nombreuses recherches (aucune ne donnant de solution clé en main) et différents tests, j'en suis arrivé aux conclusions suivantes :
Le Network Manager démarre openvpn avec l'option --up, qui permet l'exécution d'un script une fois la connexion établie. C'est ce script qui s'arrête avec un code sortie d'erreur, et qui entraîne l'arrêt du processus avec le message "Failed running command (--up/--down): external program exited with error status: 1". Dans mon cas, le script démarré est :
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --debug 0 4867 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_10 --tap --
Pour le mode routé, c'est
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --debug 0 4082 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_6 --tun --
et là ça fonctionne. Évidemment, le mode bridgé ne fonctionne pas avec le script du mode routé, même en remplaçant bien sûr l'option --tun par --tap.
J'ai donc exécuté openvpn en gérant moi-même les options. Déjà, en précisant l'option --lladdr avec une adresse MAC de mon PC (ici je mets 01:23:45:67:89:AB), j'ai pu faire disparaître le message "Could not generate persistent MAC address for tap0". (Enfin en fait pas dans "/var/log/syslog" (je pense que c'est testé là trop tôt, en quelque sorte), mais dans un fichier de log généré par openvpn (options "--verb 4" et "--log-append
/chemin/de/fichier/log), les messages "/sbin/ip link set addr 01:23:45:67:89:AB dev tap0" et "TUN/TAP link layer address set to 01:23:45:67:89:AB" sont apparus, montrant que l'adresse MAC était attribuée à l'élément virtuel tap0 — déjà un bon point, a priori.) Puis j'ai tout simplement viré l'option --up avec le script qui entraînait l'erreur. Là, la connexion était présente plus longtemps, mais un "ifconfig -a" sur ma machine donnait le résultat suivant pour la connexion tap :
tap0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 01:23:45:67:89:AB txqueuelen 100 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Et pas d'accès à mon réseau domestique bien sûr.
Mais à cette étape, comme finalement j'avais bien ce réseau tap0 connecté à mon réseau domestique, il a simplement suffi d'affecter une adresse IP à tap0 pour avoir
ENFIN ! une connexion bridgée fonctionnelle :
ifconfig tap0 192.168.0.51
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.51 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 1234:1234:1234:1234:1234:1234:1234:1234 prefixlen 64 scopeid 0x0<global>
inet6 1234::1234:1234:1234:1234 prefixlen 64 scopeid 0x20<link>
inet6 1234:1234:1234:1234:1234:1234:1234:1234 prefixlen 64 scopeid 0x0<global>
ether 01:23:45:67:89:AB txqueuelen 100 (Ethernet)
RX packets 8 bytes 1180 (1.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 63 bytes 9892 (9.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Ça, c'est normal !
Pfiou !!
Conclusion, pour me connecter en VPN bridgé à ma Freebox, j'exécute la commande suivante en tant que root dans une fenêtre bash :
/usr/sbin/openvpn --remote 123.456.789.ABC 12345 --proto tcp-client --nobind --dev tap0 --dev-type tap --lladdr 01:23:45:67:89:AB --cipher AES-256-CBC --keysize 256 --auth-nocache --extra-certs "/chemin/vers/extra-certs.pem" --verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 123456789ABCDEF0123456789ABCDEF0" subject --remote-cert-tls server --reneg-sec 0 --verb 4 --log-append "/chemin/vers/openvpn.log" --syslog nm-openvpn --tun-mtu 1500 --script-security 2 --up "/chemin/vers/ifconfig_script.sh" --up-restart --persist-key --persist-tun --management /var/run/NetworkManager/nm-openvpn-12345678-1234-1234-1234-123456789ABC unix --management-client-user root --management-client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec --client --ca "/chemin/vers/ca.pem" --cert "/chemin/vers/cert.pem" --key "/chemin/vers/key.pem" --auth-user-pass "/chemin/vers/UTILISATEUR_VPN.txt" --user nm-openvpn --group nm-openvpn --chroot /var/lib/openvpn/chroot
( :/ !)
Où :
123.456.789.ABC est l'adresse IP fixe de ma Freebox, et
12345 le port indiqué pour le mode bridgé dans l'interface de gestion OpenVPN Bridgé de la Freebox ;
01:23:45:67:89:AB une adresse MAC de mon PC client
"/chemin/vers/extra-certs.pem" le chemin pointant sur le certificat extra-certs (tous les certificats sont automatiquement générés et correctement répartis sur le disque dur par le Network Manager, lors de l'importation des fichiers .ovpn)
"C=FR, O=Freebox SA, CN=Freebox OpenVPN server 123456789ABCDEF0123456789ABCDEF0" une chaîne utilisée par l'option --verify-x509-name pour reconnaître le serveur (la Freebox, sûrement 😉 !)
"/chemin/vers/openvpn.log" le chemin vers un fichier de log, pratique pour analyser ce qui ne fonctionne pas, à combiner avec l'option --verb 4, qui permet apparemmment d'avoir un bon niveau de détails
"/chemin/vers/ifconfig_script.sh" un script lancé une fois la connxion établie grâce à l'option --up, et dans lequel réside la commande
ifconfig tap0 192.168.0.51, permettant de finaliser l'intégration de la machine distante au réseau local
/var/run/NetworkManager/nm-openvpn-12345678-1234-1234-1234-123456789ABC un fichier sur le disque dur...
"/chemin/vers/ca.pem" le chemin pointant sur le certificat ca
"/chemin/vers/cert.pem" le chemin pointant sur le certificat cert
"/chemin/vers/key.pem" le chemin pointant sur la clé
"/chemin/vers/UTILISATEUR_VPN.txt" le chemin pointant sur un fichier contenant sur la première ligne l'identifiant VPN à connecter (défini dans l'interface de la Freebox), et sur la seconde ligne, le mot de passe pour cet identifiant. Si ces lignes sont vides, ces renseignements seront demandés en ligne de commande — il va de soi qu'il vaut largement mieux ne pas renseigner le mot de passe.
Pfou !!
Désolé pour ce long post, mais comme vous voyez ce n'a pas été simple. Enfin, peut-être quelqu'un va écrire une réponse avec une solution largement meilleure tenant en trois lignes... je reste preneur !
