[Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

LucMorizur · Le 09/05/2020, à 15:55

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 !

Starjuice · Le 02/07/2020, à 22:20

Merci pour ton tuto!!! Malheureusement ca ne fonctionne pas chez moi, j'ai une erreur dans le log.

Thu Jul  2 23:14:49 2020 us=238577 /home/jb/ifconfig_script.sh tap0 1500 1591   init
Thu Jul  2 23:14:49 2020 us=240704 WARNING: Failed running command (--up/--down): could not execute external program
Thu Jul  2 23:14:49 2020 us=240752 Exiting due to fatal error

Si quelqu'un a une idée.

LucMorizur · Le 03/07/2020, à 06:53

Salut !

Starjuice a écrit :

Merci pour ton tuto!!!

De rien ! Content que ça serve !

Malheureusement ca ne fonctionne pas chez moi, j'ai une erreur dans le log.

A priori, la ligne

Thu Jul  2 23:14:49 2020 us=240704 WARNING: Failed running command (--up/--down): could not execute external program

suggère que c'est l'option --up qui cherche à faire exécuter une commande qui n'aboutit pas. Pourrais-tu donner l'intégralité de la commande qui est lancée ?

ERenon · Le 04/07/2020, à 11:12

LucMorizur a écrit :

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 !

Bonjour,

Peut être, moi pour un VPN sous Ubuntu, je vais dans « réseau » > ajouter ( + ) un VPN > en important un fichier > téléchargement du fichier > ajout du nom d’utilisateur et du mot de passe, terminé, 3 minutes.

ERenon · Le 04/07/2020, à 11:48

Et un pont ( bridge ) dans un réseau, d’autant que je me rappelle, n’a jamais été très conseillé, c’est vulnérable.

Quant à monter un VPN à partir de la freebox, j’ai bien peur que Niels se frotte les mains, sans oublier la police parfois.

Un VPN mal monté est dangereux, ne pas acheter un truc avec des serveurs aux USA ou en Grande Bretagne ( problème de journaux ), préférer le monter à la main en OpenVPN, changer le DNS dans IPv4 et 6, utiliser Firefox réglé « pas de proxy » et « activer le DNS via HTTPS » ( des fois ça fuit du port 80 ), ou bloquer ce port en sortie ( pour le VPN ) dans un pare feu si Windows.
Un module « useragent » aidera à la confidentialité.

Ça vaut Tor parfois et ce n’est pas bloqué ( port 443 ).

Dernière modification par ERenon (Le 04/07/2020, à 11:57)

LucMorizur · Le 04/07/2020, à 15:03

ERenon a écrit :

moi pour un VPN sous Ubuntu, je vais dans « réseau » > ajouter ( + ) un VPN > en important un fichier > téléchargement du fichier > ajout du nom d’utilisateur et du mot de passe, terminé, 3 minutes.

Oui... moi j'ai essayé, ça fonctionnait en routé, pas en bridgé...
Pour vous, ça fonctionne en bridgé ou routé ? Et d'où provenait le fichier que vous avez importé ?

ERenon a écrit :

Et un pont ( bridge ) dans un réseau, d’autant que je me rappelle, n’a jamais été très conseillé, c’est vulnérable.

Ah... enfin là il s'agit de mon réseau domestique, je n'ai pas trop de craintes que ma femme ou mes enfants viennent hacker mon PC sous Ubuntu lorsque je le connecte par OpenVPN...
Pour autant que j'aie compris, le résultat d'un VPN bridgé vise à ce que le PC connecté se retrouve exactement dans la même situation que s'il était physiquement connecté au réseau. Et ensuite, ben je fais confiance à OpenVPN et à Free pour que ce soit sûr entre le point d'où je me connecte et la Freebox... Après, il se peut en effet que le point d'où je me connecte ne soit pas fiable.

ERenon a écrit :

Quant à monter un VPN à partir de la freebox, j’ai bien peur que Niels se frotte les mains, sans oublier la police parfois.

Niels ? Désolé j'ai pas la ref...
Pas connaissance de vulnérabilités particulières concernant la Freebox, des conseils à ce sujet ?

ERenon a écrit :

Un VPN mal monté est dangereux, ne pas acheter un truc avec des serveurs aux USA ou en Grande Bretagne ( problème de journaux ), préférer le monter à la main en OpenVPN, changer le DNS dans IPv4 et 6, utiliser Firefox réglé « pas de proxy » et « activer le DNS via HTTPS » ( des fois ça fuit du port 80 ), ou bloquer ce port en sortie ( pour le VPN ) dans un pare feu si Windows.
Un module « useragent » aidera à la confidentialité.
Ça vaut Tor parfois et ce n’est pas bloqué ( port 443 ).

OK, merci pour les conseils ; néanmoins des précisions seront sûrement utiles aux moins avertis, dont je suis.

ERenon · Le 04/07/2020, à 17:55

J’ai essayé le freebox par un temps, à l’époque, pas de pare feu mais un routeur… donc le routage ça protège, faire un pont selon mes souvenirs c’est se passer de celui ci pour une connexion, moi je ne le ferais pas.

D’autre part, accès à la configuration de la freebox en tapant l’IP dans la barre de navigation, moi je n’aimais pas, malgré tout la freebox était réputée par un temps solide au hack par rapport à un routeur classique, souvent non mis à jour.

Le tunnel il est solide, mais il faut que la porte d’entrée à chaque bout le soit aussi, moi je ne vois pas pourquoi tu ne montes pas un VPN de façon classique, derrière du routage, mais c’est vrai qu’on n’est pas attaqué par la CIA tous les jours.

Dernière modification par ERenon (Le 04/07/2020, à 18:25)

LucMorizur · Le 05/07/2020, à 09:20

Moi je ne suis pas trop calé en réseaux et sécurité. Mais pour ce que j'ai compris, un VPN "classique" comme tu dis, ça permet d'accéder à des adresses IP (sites internet ou autres types de service) qui pourraient ne pas être acceptées, ou particulièrement surveillées, par ton fournisseur d'accès au lieu où tu te trouves. Par exemple si tu veux aller chercher des renseignements avec Google sur Tian'anmen alors que tu te trouves en Chine . (De plus le site que tu visites pourrait aussi restreindre ton accès en fonction de ton adresse IP (et je crois bien que Google justement a des accords à ce sujet avec la Chine, par exemple), ou tracer celle-ci, donc le duo VPN + Tor (qui lui fais en sorte d'afficher une autre adresse IP que la tienne) permet une navigation totalement sûre de n'importe où. Enfin, en principe, bien sûr ...)

En l'occurrence moi ce n'est pas du tout ce que je veux faire, je veux juste pouvoir accéder à mon réseau domestique comme si j'étais à la maison : pouvoir imprimer, accéder aux disques durs des autres PC... D'ailleurs si j'essayais de naviguer sur internet en étant connecté à ma Freebox par VPN (ce que permet le mode routé, et encore une fois ça ne m'intéresse pas), alors les données des sites visités seraient d'abord envoyées sur ma Freebox, à un débit de l'ordre de 1.8 Mbit/s comme d'habitude en ADSL ; puis renvoyées vers mon PC connecté en VPN routé, mais là à un débit d'environ 0.2 Mbit/s ! Aucun intérêt !

(Bon, d'accord, c'est pas très, très souvent, que j'ai besoin d'imprimer un truc sur mon imprimante à la maison, alors que je suis à 300 km de là à l'hôtel... Maaais... sait-on jamais... )

Si des précisions ou des corrections techniques (précises de préférence) doivent être apportées à ce que je viens de raconter, ce sera bien volontiers !

ERenon · Le 05/07/2020, à 10:36

Pas de navigation j’en doute, si tu veux être tranquille, désinstalle le navigateur, pas besoin de VPN.

« alors les données des sites visités seraient d'abord envoyées sur ma Freebox », ton FAI ne verra que l’IP du serveur du VPN si présence d’un VPN classique, le reste bernique, sauf fuite DNS.

Ton histoire de débit en retour bof ! moi je connais le débit descendant c’est tout.

« alors que je suis à 300 km de là à l'hôtel... Maaais... sait-on jamais... », je t’ai prévenu, VPN mal monté attention ! surtout à l’hôtel, dans un hotspot ou dans un cybercafé.

LucMorizur · Le 05/07/2020, à 10:56

ERenon a écrit :

Pas de navigation j’en doute, si tu veux être tranquille, désinstalle le navigateur, pas besoin de VPN.

Pas compris.

« alors les données des sites visités seraient d'abord envoyées sur ma Freebox », ton FAI ne verra que l’IP du serveur du VPN si présence d’un VPN classique, le reste bernique, sauf fuite DNS.

Oui, ça c'est en effet le principe du VPN

Ton histoire de débit en retour bof ! moi je connais le débit descendant c’est tout.

Alors là y'a pas photo. Et je me suis amusé à mesurer (Test débit nPerf), c'est limpide :

_ connecté depuis chez moi normal : IP vue par les sites (Info IP) : l'IP de ma Freebox ; débit descendant : normal, comme d'hab, vers les 1.8 Mbit/s ; débit ascendant : normal, comme d'hab, vers les 0.2 Mbit/s ;
_ connecté sur ma clé 4G : IP vue par les sites : l'IP de ma clé 4G évidemment ; débit descendant : normal, comme d'hab, vers les 1.8 Mbit/s ; débit ascendant : normal, comme d'hab, vers les 0.2 Mbit/s ;
_ connecté sur ma clé 4G, VPN routé vers ma Freebox activé : IP vue par les sites : l'IP de ma Freebox ; débit descendant : vers les 0.2 Mbit/s (ça rame !) ; débit ascendant : vers les 0.1 Mbit/s.

Rien de plus logique : c'est comme si je naviguais depuis chez moi, mais ensuite tout le flux est renvoyé via le tunnel VPN vers mon PC où qu'il se trouve. Or le seul tuyau par lequel ma Freebox peut renvoyer ce flux, c'est la liaison ascendante de mon ADSL, laquelle liaison est bien calibrée à quelque chose comme 0.2 Mbit/s (comme expliqué dans le deuxième paragraphe de mon premier post sur ce fil, c'est normal, c'est une liaison ADSL, pour laquelle le besoin en ascendant est à 99.99 % extrêmement faible).

Dernière modification par LucMorizur (Le 05/07/2020, à 10:57)

ylec · Le 08/03/2023, à 17:14

Merci pour avoir partagé cette solution quand on veut utiliser l'OpenVPN pour faire une connexion BRIDGée.
J'ai déjà utilisé ce genre de topologie pour de la connexion intersite, de réseaux locaux qui doivent rester sur le même LAN IP, tout en étant dans des bâtiments différents d'une même ville, ou dans des villes différentes.
Mais c'était avec des routeurs autres que la free BOX.
Ton contexte c'était pour connecter un PC depuis l'extérieur(Bâtiment A dans le schéma ci dessous), avec une adresse IP sur le même LAN que ton réseau domestique (Batiment B) dans le schéma ci dessous.
Mon objectif c'est l'interconnexion de deux LAN , celui de la freeBox dans le Bâtiment B, et celui raccordé au 2ème interface de mon PC dans la bâtiment A
LAN1 Bât. A LAN1 Bât. B
eth1 ___________ eth0 _______________ _______________________
---------------------| Pc ou routeur|----------------| routeur de mon FAI| ------( internet) ------|FreeBox du réseau principal|---------------
------------------- ------------------------- -------------------------------------
Donc dans un premier temps, même objectif que ton tuto, avoir eth0 de mon PC sur le même LAN IP, que le LAN1 de la FreeBOX distante.
Je précise que la FreeBOX cible (bât B) est une 4K mini, dans mon contexte expérimental.
J'ai passé des heures , rien que pour essayer des configurations dérivées de celle faites avec d'autres environnement sans succès.
Je confirme aussi comme toi, que connecter juste son PC avec un mode OpenVPN routé, demande 2 ou 3 dizaine de minutes, selon son habitude à utiliser des connexion VPN, le temps de configurer le serveur OpenVPN routé sur la boxe, et d'importer le fichier *.ovpn généré par la freeboxe, via la NetworkManager applet, dédié aux VPN. Et ça focntionne tout de suite, comme chez tous les provider VPN !!!
Je précise que pour faire du mode bidgé intersite, entre deux portions d'un même LAN IP, évidemment je n'utilise pas NetworkManager qui ne permet pas de faire ça. Car il faut conditionellement la montée avec succes de l'interface tap: tap0 par exemple , du tube VPN, faire ensuite une connexion bridgée: dans l'exemple ci dessus entre tap0 et eth1
Au lieu d'écrire un script dédié à une connexion donnée, je préfère utiliser le service client-openvpn@, qui nécessite un fichier de conf dans /etc/openvpn/clients , exemple Openvpn_batB_bridged.conf
Ce fichier de conf, reprend tous les paramètres: --option1 valeur1 -- option2 valeur2 ....
que tu as mis derrière ta commande openvpn, sous la forme:
option1 valeur1
option2 valeur2
... etc ...
et ensuite on lance le service avec:
# systemctl start openvpn-client@Openvpn_batB_bridged
Quand ça fonctionne, si on en a besoin en permanence, un simple
# systemctl enable openvpn-client@Openvpn_batB_bridged
valide le service en démarrage automatique par systemd au boot
Je précise qu'en suivant la solution du service, il est inutile de mettre des références à nm-openvpn, ou NetworkManager dans le fichier de conf. Pour le user et group il est plutot judicieux de mettre openvpn au lieu de nm-openvpn, car les droits d'accès pour le groupe à tout ce qui est sous /etc/openvpn, est par défaut accessible au group openvpn.
Je range également tout ce qui est certificat de CA, de serveur , extended certificat et key sous /etc/openvpn/client/ après les avoir extrait/importé par l'applet NetworkManager à partir du fichier *.ovpn créé par la FreeBOX.
Donc tous les PATHs dans le fichier Openvpn_batB_bridged.conf commencent par /etc/openvpn/client/
==========
Le raccordement de tap0 à eth1, via un bridge bridge0 par exemple se fait dans le script, post overture du tunnel openvpn, donné en argument de l'option up du fichier Openvpn_batB_bridged.conf, par exemple:
up /etc/openvpn/client/start-after-vpn-connect-free.sh
dans lequel on construit le bridge0, s'il n'existe pas et qu'ensuite on fait le lien avec tap0:
principale étapes du script
+++++++start-after-vpn-connect-free.sh+++++++

BRNUM=0
PHYSINT=eth1
TAPINT=tap0

# create bridge interface if not existing
if [ "`brctl show | grep bridge${BRNUM}`" = "" ]
then
        brctl addbr bridge${BRNUM} 2> /dev/null
fi

STATUS_TAPINT="`ifconfig $TAPINT | grep flags`"
if [ "$STATUS_TAPINT" != "" ]
then
	echo "`ifconfig $TAPINT `" >> /var/log/openvpn.log
	#ifconfig $TAPINT  192.168.1.7/24 up
	#brctl addif bridge${BRNUM} $TAPINT 
fi

# required to put bridge${BRNUM} UP
# otherwise the switching does not run
ifconfig bridge${BRNUM} up

++++++++++++++++++++++++++++
La commande ifconfig ci dessus est commentée, car j'ai mis directement dans Openvpn_batB_bridged.conf :
ifconfig 192.168.1.7 255.255.255.0
sous
lladdr be:1c:62:82:a0:fc (votre adresse mac préférée pour tap0 !)
ATTENTION

le paramètre ifconfig ci dessus est une option --ifconfig de la commande "openvpn"
tandis que
les lignes ifconfig du script start-after-vpn-connect-free.sh
correspondent à la commande shell ifconfig
On peut donc remplacer dans ce shell, la commande:
ifconfig $TAPINT....
par:
ip link show $TAPINT

de même la dernière ligne du script ci dessus peut être remplacé par une commande "ip"
ip link set bridge${BRNUM} up

Si la commande brctl .... est aussi commenté on est dans le même cas de figure que toi.
Ce qui permet de tester tout à partir de son PC.
Si la ligne est active, à la fin on a quelque chose comme:
[root@ismf38 client]# brctl show bridge0
bridge name bridge id STP enabled interfaces
bridge0 8000.4a297a0149fb no tap0
eth1
A partir de là , le PC ne peut plus atteindre les éléments du réseau 192.168.1.0/24 (celui du LAN IP de la freeBox)
Ceci découle directement du méchanisme de bridging sous linux
Mais tout ce qui est sur le troncon raccordé à l'interface eth1 du batimant A, oui.
En fait si on rajoute une IP à bridge0
exemple; ifconfig bridge0 192.168.1.10/24 up
le PC continuera à atteindre les autres noeuds du réseau IP de la freeBoxe, qu'ils soient sur le tronçon du batiment A ou du Batiment B !

Toutes les adresses IP référencée ici sont hors de l'intervalle du pool DHCP de la FreeBOX, qui pour moi était réglé à 192.168.1.50 - 192.168.1.100
=============
Encore une fois mille fois merci pour ton précieux post! (je l'ai trouvé car référencé sur un autres blog !)

Dernière modification par ylec (Le 10/03/2023, à 14:40)

ylec · Le 08/03/2023, à 17:33

Au cas où ça pourrait aider, voici le le contenu complet de Openvpn_batB_bridged.conf (avec les info sensibles masquées, adresse IP publique de la freebox: xx.xx.xx.xx, et l'ID du certificat de server : abcdef123456789abcdef123456789)
==========================================

client
remote xx.xx.xx.xx 59504
proto tcp-client
nobind
dev b0tap
dev-type tap
lladdr be:1c:62:82:a0:fc
ifconfig 192.168.1.7 255.255.255.0
cipher AES-256-GCM
auth-nocache
extra-certs /etc/openvpn/client/config_openvpn_bridge_batB-extra-certs.pem
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server abcdef123456789abcdef123456789"
remote-cert-tls server
reneg-sec 72000
verb 4
log-append /var/log/openvpn.log
syslog nm-openvpn
tun-mtu 1500
script-security 2
up /etc/openvpn/client/start-after-vpn-connect-free.sh
up-restart
persist-key
persist-tun
auth-retry interact
route-noexec
ca   /etc/openvpn/client/config_openvpn_bridge_batB-ca.pem
cert /etc/openvpn/client/config_openvpn_bridge_batB-cert.pem
key  /etc/openvpn/client/config_openvpn_bridge_batB-key.pem
auth-user-pass /etc/openvpn/client/eveb_bridged_user_pass
user openvpn
group openvpn
chroot /var/lib/openvpn/chroot

NOTE
enlever la dernière ligne
chroot /var/lib/openvpn/chroot
si vous ne voulez pas vous embêter à recopier toute l'arborescence utile de /etc/openvpn/client/*
sous /var/lib/openvpn/chroot/
Car une fois chrooté le process ne peut plus lire /etc/openvpn/client/
et donc les ré-authentifications régulières ne peuvent plus se faire (vous verrez dans le log des files NOT found !!!):
Tous les fichier *.pem, le script et surtout le fichier eveb_bridged_user_pass, doivent être accessible à partir du / chrooté, donc sous /var/lib/openvpn/chroot
[================================================
le fichier eveb_bridged_user_pass, contient sur la première ligne le nom du user openvpn créé sur la FreeBox, et la deuxième ligne son password
Si vous ne mettez pas le password, il vous sera demandé en interactif au démarrage du service.
systemctl start openvpn-client@Openvpn_batB_bridged
Mais dans ce cas on ne peut pas utiliser systemd, pour le démarrer automatiquement en permanence.
Donc se sera uniquement pour un usage occasionnel.
===================
Et pour finir, la configuration où vous démarrez tout, pour que ce soit ou non utilisable pour des appareils situés sur la branche raccordé à l'interface eth1:
1°) ne mettez pas de
paramètre valeur :
ifconfig 192.168.1.7 255.255.255.0
dans le fichier de conf Openvpn_batB_bridged.conf

et
2°) finir le travail dans le script post activation de l'interface tap0 (une fois le VPN établi) : /etc/openvpn/client/start-after-vpn-connect-free.sh dans cet exemple
voici la fin du programme modifié:

# STATUS_TAPINT="`ifconfig $TAPINT | grep flags`"
# oubien
STATUS_TAPINT="`ip link show $TAPINT`"

if [ "$STATUS_TAPINT" != "" ]
then
        echo "`ip addr show $TAPINT `" >> /var/log/openvpn.log
        # ifconfig $TAPINT  up
        # oubien
        ip link set $TAPINT up

        # brctl addif bridge${BRNUM} $TAPINT && ifconfig bridge${BRNUM} 192.168.1.20
        # oubien
        # brctl addif bridge${BRNUM} $TAPINT && ip address change 192.168.1.20/24 dev bridge${BRNUM}
        brctl addif bridge${BRNUM} $TAPINT
fi

Comme indiqué dans le post initial de ce fil de discussion, si on ne met pas localement une d'adresse IP à l'interface tap, créé au moment de l'établissement du VPN, tap0 reste en état down.
On le force donc à l'état up avec "ifconfig ... up" ou "ip ... up", sinon il ne sera pas intégrable dans le bridge0.
ATTENTION
le paramètre ifconfig dans le fichier de conf,
correspond à l'option --ifconfig de la commande openvpn
alors que les lignes ifconfig dans le script /etc/openvpn/client/start-after-vpn-connect-free.sh
corespondent à la commande shell ifconfig, qui peut être remplacée par une commande ip !

NOTE
si on met une adresse IP sur l'interface tap0, au moment où elle va être raccordé à bridge0 elle ne sera plus utilisable, mais vous aurez une route:
vers le réseau 192.168.1.0/24 (dans cet exemple) via tap0
en rajoutant une adresse IP sur bridge0, vous aurez une deuxième route
vers le réseau 192.168.1.0/24 (dans cet exemple) via bridge0
et la communication IP entre le PC et le reste du réseau 192.168.1.0/24 ne fonctionnera pas

Dans l'exemple ci dessus, on s'arrête à l'ajout de l'interface tap0 dans les ports du bridge bridge0
si vous valider à la place de la dernière ligne du bloc "then fi"
la ligne qui est en commentaire au dessus, vous mettez une adresse sur brideg0, ce qui permettra au PC du batiment A d'accéder à la partie du LAN du batiment B + la branche déportée dans le batiment A (raccordé à eth1)
Sinon seuls les éléments qui seront sur les troncons raccordés à eth1 de votre PC, communiqueront avec ceux du LAN de la FreeBoxe dans le batiment B.
Dans le cas ou vous faites du télétravail pour un client depuis votre bureau ou votre domicile , ne pas mettre d'adresse IP à bridge0 est le plus judicieux .
Ainsi il n'y à aucune communication possible entre :
--> le LAN principal du Client dans le batiment B + le petit bout du même LAN raccordé à eth1 dans le batiment A
et
--> le LAN de votre bureau en entreprise , ou votre LAN domestique

Dernière modification par ylec (Le 10/03/2023, à 15:36)

xubu1957 · Le 08/03/2023, à 17:43

Bonjour,

Pour ajouter toi-même les balises code à tes messages #11 et #12 : Merci

Cliquer sur le lien « Modifier » en bas à droite du message
Sélectionner le texte
Cliquer sur le <> de l'éditeur de message

moko138 a écrit :

1) Les balises-code sont les < > (crochets bleus) de la barre de mise en forme.

_ _ _
3) /!\ Si vous avez plusieurs retours à donner, séparez-les bien (toujours pour la lisibilité) :
comme
cela.

Comme demandé dans le premier message du tutoriel Retour utilisable de commande
_ _ _

(Edit= messages regroupés)
_ _ _

Lecture conseillée > memento des balises code.

Dernière modification par xubu1957 (Le 08/03/2023, à 19:45)

ylec · Le 08/03/2023, à 19:35

merci beaucoup pour cette information: donc correction faite !

LucMorizur · Le 09/03/2023, à 15:31

Wow ! Impressionnant !...

ylec a écrit :

(...) Encore une fois mille fois merci pour ton précieux post! (je l'ai trouvé car référencé sur un autres blog !)

De rien, vraiment bien content que ça ait servi, car je m'étais bien embêté ! (Bon, en même temps, ça m'avait permis de m'occuper pendant le confinement... )

Maintenant que j'ai la fibre, le débit ascendant est suffisant pour me permettre de contrôler en VNC un PC chez un client, tout en étant moi-même chez un autre client, le tout protégé donc par ce tunnel VPN passant par ma Freebox. C'est vraiment très pratique, et je l'utilise vraiment.

Pour ce qui est de ta réalisation ylec, il faudra que je m'y penche, car je suis sûr d'apprendre plein de choses... À vrai dire je suis assez nul en réseaux, pour le moment il y a beaucoup de choses que tu as évoquées que je ne comprends pas...!

Merci en tous cas à toi aussi d'avoir partagé tes résultats !

xubu1957 · Le 09/03/2023, à 15:37

Bonjour,

En complément :

Le 01/07/2019, bruno a écrit :

Hors-sujet.
Au passage les commandes ifconfig sont obsolètes. Il serait préférable d'aider les demandeurs avec les commandes ip:
#3 : remplacer par ip a (ou ip address show)
#4 : remplacer par ip link set enp4s0 up|down

dans Problème connexion Ethernet via CPL

LucMorizur · Le 09/03/2023, à 15:45

xubu1957 a écrit :

les commandes ifconfig sont obsolètes.

Ah oui, en effet, merci. Il va falloir adapter les scripts avant que ça disparaisse vraiment, ou que ce soit vraiment inadapté.

Euh... je reviens modifier mon post initial dès que... enfin, voilà, quoi ...

Dernière modification par LucMorizur (Le 09/03/2023, à 15:46)

ylec · Le 10/03/2023, à 16:05

Enfin pour finir, une idée des performances de débit:
Pour faire simple elle est médiocre:

CAS USAGE DU TUNNEL OPENVPN
Si je met une machine Linux PCb sur le tronçon du bâtiment B, disons à l'adresse: 192.168.1.100
une fois le tunnel établi avec la freeBox, avec mon PCa coté bâtiment A , à l'adresse 192.168.1.20 (celle de mon bridge0, intégrant l'interface tap0)
si je fais un échange de fichier via ssh (avec par exemple le gestionnaire de fichier , nautilus, caja, etc...--> se connecter à un serveur )
avec l'adresse cible 192.1681.100
... compter plus de 50mn pour une archive de 8Go , soit un peux moins de 3 Mo/s
(je précise que les deux boxes internet coté bâtiment A et B, on des upload/download au moins égal à 1Gbps: donc on peut s'attendre à des débits d'environ 100Mo maximum)

CAS LIAISON SANS USAGE du TUNNEL OPENVPN

Sur la boxe Free 4K mini du batiment B, j'ai donc fait une redirection de port, par exemple 8822, redirigé vers port 22 de la machine 192.168.1.100
Et cette fois je fais une connexion ssh, port 8822, vers l'adresse IP publique de la boxe du bâtiment B
je vais donc faire une échange entre les mêmes PC que précédemment mais sans usage du tunnel

cette fois j'ai ... 80 Mo/s, soit moins de 2 mn pour échanger mon archive de 8Go !!!
Si vous avez oublié vos archives *.OVA de machine virtuelle sur le NAS de la maison ou du bureau à VERSAILLES, et que vous en avez besoin urgemment à GRENOBLE... c'est pas top !!
==================
Je précise que sur le PC du bat A (un Athlon FX octocore cadencé à 4GHz: donc supportant les instructions aes, pour le décodage/encodage AES hardware), dans le cas de l'usage du VPN, le process openvpn charge à peine un CPU à 14% ! Donc c'est la FreeBox qui n'est pas adaptée pour le décodage AES pour OpenVPN
Avec l'expérience d'un Edge Routeur 4 d'Ubiquiti, à la place d'une freeBox 4K mini, j'ai constaté les mêmes dégradation de performance.

Mais sur les forums d'Ubiquiti, donnant un tuto pour OpenVPN en mode bridge, il était clairement annoncé qu'OpenVPN, tourne uniquement en espace process, dans sans l'aide du CPU pour le décodage/encodage AES. Et puisque l'OS de l'ER4 est un linux, il est facile de suivre avec top, la charge du CPU quand on transfert à travers une tunnel OpenVPN : ça bourrique fort !!!!

C'est sans doute pour ça que son interface WEB de configuration ne propose pas OpenVPN comme tunnel VPN possible, et qu'il faut rentrer toute la conf en mode CLI.
Bref, deux routeurs Linux derrière les routeurs des FAI, de chaque coté, l'un en serveur VPN, l'autre en client comme dans ce cas de figure, feront sans doute mieux l'affaire. Il y aura juste à faire dans la boxe du Bâtiment B, une redirection de port pour celui utilisé sur le serveur openvpn, vers le PCb.
Mais ça c'est une autre expérience!

Dernière modification par ylec (Le 10/03/2023, à 16:11)

jimbou · Le 26/06/2024, à 07:57

ERenon a écrit :

Peut être, moi pour un VPN sous Ubuntu, je vais dans « réseau » > ajouter ( + ) un VPN > en important un fichier > téléchargement du fichier > ajout du nom d’utilisateur et du mot de passe, terminé, 3 minutes.

Bonjour,

Ca marche bien sous Windows, mais pas sur mon Ubuntu.

Ca se finit systématiquement par un échec d'établissement de la connexion.

Alors je me suis rabattu sur SMB.

krodelabestiole · Le 26/06/2024, à 08:30

SMB à la place d'un VPN ?

j'ai du mal à voir ça comme une alternative, ce n'est pas le même but recherché a priori ?
le VPN peut par ex. servir à regarder la télé française depuis l'étranger, ou accéder à des services privés sur son réseau local depuis l'extérieur, via internet (en mode bridgé)...

je ne vois aucun intérêt à un VPN en local, et a contrario le SMB ne s'utilise que sur un réseau local pour y partager des fichiers et des imprimantes (ou alors lui-même via un VPN bridgé pour y accéder depuis internet).

ERenon a écrit :

Quant à monter un VPN à partir de la freebox, j’ai bien peur que Niels se frotte les mains, sans oublier la police parfois.

je ne vois pas trop ce que ça change par rapport à son propre VPN (sur rpi ou autre) derrière la freebox ?
dans tous les cas le traffic est redirigé sur son FAI (donc free), et a priori c'est plutôt le but ?

jimbou · Le 26/06/2024, à 09:15

L'utilisation du VPN que tu décris, c'est du type "grand public"

Je veux en faire une utilisation plus professionnelle : connecter un PC quelque part dans le monde (bon, disons en France) au réseau local de l'association pour faire comme si le PC était dans les locaux de l'association. Du télétravail.

Le premier besoin étant d'accéder aux fichiers du serveur de l'association, le SMB me suffit pour l'instant. Et d'ailleurs, je vais plutôt opter pour le protocole SSH.

krodelabestiole · Le 26/06/2024, à 09:22

c'est exactement ce que je décris là :

ou accéder à des services privés sur son réseau local depuis l'extérieur, via internet (en mode bridgé)...

toujours est-il que j'espère pour votre sécurité et vos informations que tu n'utilises pas SMB via internet...
SSH / SFTP est effectivement un bien meilleurs choix dans cette optique.

jimbou · Le 26/06/2024, à 09:28

Ah oui, pardon.

LucMorizur · Le 30/06/2024, à 12:07

jimbou a écrit :

ERenon a écrit :
Peut être, moi pour un VPN sous Ubuntu, je vais dans « réseau » > ajouter ( + ) un VPN > en important un fichier > téléchargement du fichier > ajout du nom d’utilisateur et du mot de passe, terminé, 3 minutes.
Bonjour,
Ca marche bien sous Windows, mais pas sur mon Ubuntu.
Ca se finit systématiquement par un échec d'établissement de la connexion.
Alors je me suis rabattu sur SMB.

Ça ne m'étonne hélas pas trop : ça commence à remonter, mais je me souviens qu'au moment où j'avais réussi à mettre ça en place, j'avais vraiment, vraiment galéré. Aujourd'hui il y a des parties pour lesquelles je ne suis pas sûr de retrouver comment j'avais fait ; et je me souviens que je n'ai pas vraiment compris comment j'avais trouvé la dernière commande qui a permis que ça finisse par fonctionner, avec le ifconfig — qui d'ailleurs est apparemment obsolète et dont il va falloir s'occuper avant que ça ne fonctionne plus, ce qui pour moi signifie prendre du temps — pas mal de temps — afin de, sinon comprendre, au moins faire des tests pour s'assurer que ça fonctionne.

Car sinon, après deux changements de PC depuis mon premier post à ce sujet, et donc des modifications dans la commande à effectuer (genre adresse MAC évidemment, ou bien sûr les chemins de fichier au adresses IP), eh bien dans mon cas ça fonctionne toujours, et heureusement car j'en ai besoin professionnellement.

Bon courage pour tous·tes celles et ceux qui se coltinent cette configuration !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 09/05/2020, à 15:55

[Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#2 Le 02/07/2020, à 22:20

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#3 Le 03/07/2020, à 06:53

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#4 Le 04/07/2020, à 11:12

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#5 Le 04/07/2020, à 11:48

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#6 Le 04/07/2020, à 15:03

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#7 Le 04/07/2020, à 17:55

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#8 Le 05/07/2020, à 09:20

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#9 Le 05/07/2020, à 10:36

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#10 Le 05/07/2020, à 10:56

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#11 Le 08/03/2023, à 17:14

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#12 Le 08/03/2023, à 17:33

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#13 Le 08/03/2023, à 17:43

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#14 Le 08/03/2023, à 19:35

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#15 Le 09/03/2023, à 15:31

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#16 Le 09/03/2023, à 15:37

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#17 Le 09/03/2023, à 15:45

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#18 Le 10/03/2023, à 16:05

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#19 Le 26/06/2024, à 07:57

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#20 Le 26/06/2024, à 08:30

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#21 Le 26/06/2024, à 09:15

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#22 Le 26/06/2024, à 09:22

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#23 Le 26/06/2024, à 09:28

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

#24 Le 30/06/2024, à 12:07

Re : [Résolu] OpenVPN ponté (bridge) sur Freebox V6 depuis Ubuntu 18.04

Pied de page des forums