Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Ca fait longtemps que je n'ai pas bidouillé OpenVPN.

Il est possible qu'il y ait un problème de version. Le serveur OpenVPN des Freebox est peut-être un peu daté, et se trouver incompatible avec des clients OpenVPN plus récents.
De mémoire..... j'arrivais à faire fonctionner un vieil iPhone (iPhone 4) en OpenVPN bridgé mais pas un Android très récent qui lui ne fonctionnait qu'en OpenVPN routé ou pas du tout, je ne m'en souviens plus du tout.

Pour Windows... si je me réfère à un message récent d'une personne se trouvant en Russie, il semblerait que le client OpenVPN marche bien en bridgé.

Sous nunux c'est un peu compliqué car le comportement des programmes peut varier en fonction des options de compilation utilisées lors de la création des packages.
Il est possible que pour le package dont tu disposes, une option de compilation interdise une rétrocomptabilité avec d'anciens serveurs, mais d'une distro à une autre, ça peut changer.

Les utilisateurs avancés de Linux savent compiler eux mêmes ces paquets pour définir des options "customisées"
Je ne sais pas le faire sous Linux, je sais mieux le faire sous BSD qui lui propose dans son système de ports la plupart de ces fameuses options de compilation à cocher.

Si j'ai le temps je ferai un test avec ma distro Linux Tumbleweed.

Merci pour ton éclairage qui explique bien les raisons de ce problème.
Ça me fait penser aux vieilles versions de samba utilisées sur la box. Mais dans ce cas on peut assez facilement spécifier la version du protocole.
Je ne m’y connais pas assez pour compiler et reste preneur de toute piste.

Je ne connais absolument pas Raspberry Caspian, donc je ne connais pas le système de package.

Le principe est que tu peux faire appel à des "dépôts alternatifs" qui peuvent contenir éventuellement des versions compilées différentes.
Par exemple, sous OpenSUSE Tumbleweed, j'utilise le FFMPEG fourni par Videolan, car la version OpenSUSE ne comprend pas les CODECs non OSS (un ensemble de CODECs gratuits mais pas Open Source dans le sens de la licence Linux GPL), résultat, Firefox bute sur la moindre video en streaming à défaut de posséder le CODECs audio, et c'est juste inutilisable.

Toujours sous Tumbleweed il y a une myriades de paquets proposés par des particuliers via le système OpenSUSE Build service. Ces paquets sont hébergés par OpenSUSE eux-mêmes, donc ça les rend un peu plus sûrs que des dépôts strictement privés. Au moindre souci OpenSUSE bannira les Builds Service fautives... mais à consommer avec modération.

L'un des grands dépôts alternatifs et connus comme fiables par la communauté c'est le fameux dépôt "packman".... éventuellement y-a-t-il une version alternative plus intéressante.

Mais sur les dépôts alternatifs, il faut y aller "piaaaaaaano"

- s'assurer qu'on a affaire à des dépôts fiables et reconnus (le dépôt de l'éditeur est la source la plus directe et la plus fiable qui soit, pour des paquets tiers Videolan est par exmeple un vieux de la vieille pour ne parler que de lui, mais il y a aussi packman....)

- se méfier comme de la peste de dépôts "privés" censés vous apporter la solution, car il y a peut-être des cochonneries incluses dans le code

L'autre gros soucis... ce sont les dépendances. Introduire du dépôt alternatif c'est potentiellement foutre le merdier dans la distro lors des mises à jours.
Le système va piquer une mise à jour d'un composant KDE dans ce dépôt alternatif, et d'autres dans les dépôts officiels, mais les options de compilation seront incompatibles entre eux et les modules seront incapables d'interagir. Donc il faut savamment paramétrer "les priorités des dépôts", les dépôts officiels de la distro étant prioritaires.

Tout n'est pas possible.
Dans certains cas il sera tout simplement impossible d'installer le paquet convoité car ce dernier peut requérir une version de composant qui ne correspond pas à la version de la distribution, et forcer l'installation de cette version de composant peut entrainer des conséquences dramatiques en changeant les versions de plein d'autres composants et en rendant la distro inutilisable.

Autre alternative, passer par des dépôts "sans installation racine", les fameux dépôts flatpak, snap, appimage

Par exemple SNAP propose une version d'openvpn. A priori le serveur contient aussi le client. Snapcraft est géré par Ubuntu

Ici le dépôt officiel de snap, celui géré par Ubuntu. Eventuellement d'autres peuvent exister.

https://snapcraft.io/easy-openvpn-server

Voici pour Flatpak, le dépôt officiel en général promu par les distros Redhat, OpenSUSE
Des dépôts privés peuvent exister

https://flatpak.org/

Pour les appimage, il n'y a pas de dépôt. C'est l'éditeur lui-même qui le fournit (source la plus sûre, comme pour Linphone, Cryptomator...), ou un tiers via des dépôts comme github, mais il faut faire confiance au projet

- Appimage est le moins invasif. Les apps sinstallent et se désinstalle facilement, toutes les dépendances nécessaires sont incluses mais il n'y pas de procédure de mise à jour simple. Les applis s'installent en mode utilisateur exclusivement. On ne peut pas installer d'AppImage partagée entre plusieurs utlisateurs de l'OS

- Flatpak / snap : ils sont concurrents. Toutefois ça ne met pas totalement de coté la notion de dépendances, mais ils vont simplement installer ces dépendances totalement isolées du noyau du système, et a priori le système est conçu pour pouvoir gérer plusieurs versions concurrentes d'un même composant (ce qui est très compliqué dans le système d'installation racine)

Flatpak et snap peuvent au choix installer les apps en mode partagé pour tous les utilisateurs de l'OS ou en mode utilisateur strict. En mode partagé, une simple commande de mise à jour lance la mise à jour DE TOUTES LES APPS installées c'est très efficace.

Flatpak et snap requièrent l'installation préalable de composants racines, avec le paramétrage initial des dépôts
Pour les AppImage, les distros en général supportent désormais nativement le format, il n'y a pas de composants additionnels à installer

Si tu installes des jeux en snap.... l'espace disque utilisé peut être juste DEMENTIEL, en raison de la chaine de dépendances à installer qui peut revenir à installer plusieurs systèmes en parallèle.

Quand je dis démentiel.... on parle parfois de plusieurs centaines de gigaoctets pour des joueurs accros.
La question ne se pose pas pour Flatpak qui ne promeut pas les jeux, sauf dépôt flatpak privé... quoique, si une appli requiert d'ancien composants KDE, ça peut produire une réaction en chaine assez terrible.

Donc à utiliser avec une extrême modération...., il y a de très mauvais conseils qui circulent sur Internet, qui ne mettent pas en garde contre cela.

Le système d'installation racine doit rester le système par défaut, c'est aussi le système le plus sûr compilé à partir des sources les plus fiables possible.
On utilise flatpak, snap, appimage ponctuellement en complément JAMAIS à titre principal comme le font certains inconscients.

Au passage... je te conseilles vivement de passer à une Linux Rolling Release de type Tumbleweed. Les avantages (disponibilté des dernières sources possibles) l'emportent largement sur les inconvénients qui existent, il ne faut pas non plus l'ignorer. En Tumbleweed je peux par exemple faire tourner le système de fichier OpenZFS via un dépôt alternatif, qui n'est pas disponible sur les versions standard OpenSUSE Leap. Je dispose rapidement de la dernière verison de Keepass, de Firefox... je peux faire tourner du matériel assez récent. Les dernières cartes Wifi Intel AX200 tournent sans problème car incluses dans les derniers kernels Linux... pas de soucis de saut de version à effectuer, ça se fait en continu.

Tumbleweed existe en x86 et ARM64, elle tourne parfaitement sous VM Freebox...
Sous la VM Freebox il suffit de paramétrer ton disque virtuel, de paramétrer une image DVD et de booter sur l'image d'installation de Tumbleweed ARCH 64... et ça marche ça va lancer l'installeur en mode texte.

En revanche il faut choisir EXT4 surtout pas BTFRS, c'est une catastrophe ton truc va ramer.

Il faudra prévoir 4 GO minimum pour la VM Tumbleweed ARCH64 donc passer la cas échéant ta Freebox en 8 GO, ECC (les blocs Samsung, Hynix étant connus pour fonctionner)
Ca fonctionne avec bien moins, sans avoir à upgrader la mémoire de la Delta, mais ça se ressent aussitôt sur la réactivité de la machine.

Merci pour ton éclairage qui explique bien les raisons de ce problème.
Ça me fait penser aux vieilles versions de samba utilisées sur la box. Mais dans ce cas on peut assez facilement spécifier la version du protocole.
Je ne m’y connais pas assez pour compiler et reste preneur de toute piste.

J'ai réessayé ce matin avec les yeux en face des trous. Et ç marche il faut bien rajouter la ligne de l'adresse Mac et de l'IP dans le fichier de conf openvpn. J'ai également rajouté le bail statique sur ma box.