subject:"OpenVPN"

Un dernier PS :

NM est installé quand on installe un DE avec debian, d'après ce que je lis ici.

Network Manager knows how to handle various types of connections (...)
Note that this program is installed by default when the “Desktop Environment” 
task is chosen during initial installation. 
(8.2.5. Automatic Network Configuration for Roaming Users 
https://www.debian.org/doc/manuals/debian-handbook/sect.network-config)



- Mail original -
De: "didier gaumet" 
À: "Liste Debian" 
Envoyé: Dimanche 23 Juillet 2023 14:26:07
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel?

Tiens, en mangeant un truc sur le pouce tout à l(heure, je naviguais sur 
internet sur mon smartphone et j'ai trouvé un article du wiki Gnome sur 
la gestion de DNS par NetworkManager en liaison ou non avec dnsmasq ou 
systemd-resolved:
https://wiki.gnome.org/Projects/NetworkManager/DNS

J'ai pas en tête (lu en diagonale ton premier message) ton contexte 
exact mais si NetworkManager est installé, il rentre aussi dans le jeu, 
faut en tenir compte, je suppose

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

MA REPONSE, MAL INDENTEE, DONC MISE EN TETE

1/ Sur la résolution de nom :
C'est réglé. Merci.
J'ai dégagé resolvconf qui m'a causé problème comme par le passé.
Je conserve juste NM sur ce poste de travail.
Et je testerai systemd-resolved sur un serveur.
Mon expérience c'est que les trucs systemd fonctionnent toujours avec souvent 
un peu de temps à passer dans la doc pour piger la syntaxe modulaire.
Par ex : il faut annuler une valeur avant de la définir avec systemd.timer (vs 
crontab qui n'impose pas cette gymnastique) mais qui offre aussi des 
vérifications manuelles et automatiques (lint).


2/ Sur wireguard :
J'ai bien avancé. 
La doc de wireguard n'est quand même pas vraiment à la hauteur de ce programme 
très intéressant.
Par ailleurs, les divers tutos expliquent la configuration de manière très 
variable. Il faut tâtonner et bien distinguer l'utilisation du fichier de conf 
(avec/sans persistance) et les commandes wg qui font la même chose sans 
l'utiliser.
Entre mon serveur wg et de simples clients (mobiles) : impeccable.
J'ai principalement un problème de configuration réseau sur mon poste de 
travail qui est à la fois client wg et qui accèdent à divers serveurs (via ssh 
ou mosh), dont le serveru wg.
Du coup, quand tout le trafic est détourné vers le serveur, je perds le contact 
avec mes serveurs. 
C'est classique pour les experts mais il faut que j'arrive à traiter 
correctement mon trafic réseau.
Je vais ouvrir un fil sur ce thème générique qui me semble tourner autour de 
iptables/ufw/nftables.


3/ je mets un terme à ce fil dont le nom était vraiment trop long !
Merci à tous.


- Mail original -
De: "didier gaumet" 
À: "Liste Debian" 
Envoyé: Dimanche 23 Juillet 2023 22:51:15
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel?

Le 23/07/2023 à 18:47, roger.tar...@free.fr a écrit :
[...]
> Tu dois cond gérer en manuel /etc/resolv.conf .

Non, mon PC n'est pas un serveur, c'est un laptop pour mon usage perso 
avec un DE et Network-Manager installé qui gère ça

> J'ai lu ton dernier message vers18h  qui parle du DNS géré par NM 
> (https://wiki.gnome.org/Projects/NetworkManager/DNS)
> 
> Sur mon poste de travail, j'ai NM qui gérait /etc/resolv.conf , mais comme 
> j'ai installé resolvconf, à présent :
> /etc/resolv.conf -> ../run/resolvconf/resolv.conf
> 
> J'ai essayé d'arrêter resolvconf.service et de redémarrer 
> NetworkManager.service .
> Ça ne change rien.
> Je ne sais pas trop quoi faire pour que NM gère la résolution de noms...
> J'ai la tête qui fume.
> Une piste pour sortir de ce bazar ?
> Merci.

A moins que tu n'aies un besoin bien particulier, l'ordinateur dont tui 
parles est un PC avec un bureau et NetworkManager, donc je te conseille:
- de purger par apt (apt remove n'est pas suffisant car il n'enlève pas 
les fichiers de conf.) resolvconf. Si tu as déjà fait une apt remove de 
resolvconf, réinstalle-le (apt install) pour pouvoir le purger (apt purge)
- de réinstallet (apt reinstall) ou reconfigurer (dpkg-reconfigure) 
Network-Manager
- de redémarrer pour remettre tout à plat ensuite

ça suffira peut-être à repartir du bon pied

Pour celui quit veut absolument mélanger NetworkManager avec un 
gestionnaire DNS, NM semble prévu ppur fonctionner avec systemd-resolved 
mais pas avec resolvconf. Et dans ton cas je n'ai pas l'impression que 
ce mélange serait justifié.

> PS :
> Le seul endroit du manuel debian qui parle de résolution de noms que j'ai 
> trouvé est :
> https://www.debian.org/doc/manuals/debian-reference/ch05.fr.html#_the_hostname_resolution
> 
> Il faut aller chez Arch pour des infos sur systemd-resolved (ta réf : 
> https://wiki.archlinux.org/title/Systemd-resolved ).
> C'est étrange, non ?

Selon moi Debian est une distribution généraliste qui ne place pas la 
convivialité avant la fonctionnalité (tout dépend de la cible visée).
Ce qui l'amène à être au milieu de l"échelle des docs/wiki, en caricaturant:
- docs complètes et pertinentes pour les distros installées à partir des 
sources -LFS, Gentoo...) et les distros binaires mais à paramétrer 
manuellement de manière poussée (Archlinux...)
- docs moyennes pour les distros moyennes (Debian, RHEL (plutôt mieux 
que Debian)...)
- docs de faible niveau pour les distros les plus conviviales (certaines 
distros n'ont quasiment pas de docs, Ubuntu a beaucoup de docs bonnes et 
mauvaises)

Re: Tunnel openvpn - comment router ...

2023-07-23 Par sujet RogerT




> Le 23 juil. 2023 à 21:06, Michel  a écrit :
> 
> Le 23/07/2023 à 19:40, Michel Verdier a écrit :
>> Le 23 juillet 2023 roger tarani a écrit :
>> 
>>> plein de choses mélangées avec un subject trop long
>> 
>> Là moi je suis perdu. S'il vous plaît utilisez un MUA correct en faisant
>> des reply avec les belles indentations habituelles (>) sinon on ne
>> sait plus qui a dit quoi et ce qui est répondu à "quoi".
> 
> Ah, toi aussi...
> 

Le webmail free (zimbra) doit mal baliser/indenter les textes antérieurs. 

Là, je réponds depuis un MUA de smartphone et je vois l’indentation correcte de 
vos deux messages. 

Merci.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?


Le 23/07/2023 à 18:47, roger.tar...@free.fr a écrit :
[...]

Tu dois cond gérer en manuel /etc/resolv.conf .


Non, mon PC n'est pas un serveur, c'est un laptop pour mon usage perso 
avec un DE et Network-Manager installé qui gère ça



J'ai lu ton dernier message vers18h  qui parle du DNS géré par NM 
(https://wiki.gnome.org/Projects/NetworkManager/DNS)

Sur mon poste de travail, j'ai NM qui gérait /etc/resolv.conf , mais comme j'ai 
installé resolvconf, à présent :
/etc/resolv.conf -> ../run/resolvconf/resolv.conf

J'ai essayé d'arrêter resolvconf.service et de redémarrer 
NetworkManager.service .
Ça ne change rien.
Je ne sais pas trop quoi faire pour que NM gère la résolution de noms...
J'ai la tête qui fume.
Une piste pour sortir de ce bazar ?
Merci.


A moins que tu n'aies un besoin bien particulier, l'ordinateur dont tui 
parles est un PC avec un bureau et NetworkManager, donc je te conseille:
- de purger par apt (apt remove n'est pas suffisant car il n'enlève pas 
les fichiers de conf.) resolvconf. Si tu as déjà fait une apt remove de 
resolvconf, réinstalle-le (apt install) pour pouvoir le purger (apt purge)
- de réinstallet (apt reinstall) ou reconfigurer (dpkg-reconfigure) 
Network-Manager

- de redémarrer pour remettre tout à plat ensuite

ça suffira peut-être à repartir du bon pied

Pour celui quit veut absolument mélanger NetworkManager avec un 
gestionnaire DNS, NM semble prévu ppur fonctionner avec systemd-resolved 
mais pas avec resolvconf. Et dans ton cas je n'ai pas l'impression que 
ce mélange serait justifié.



PS :
Le seul endroit du manuel debian qui parle de résolution de noms que j'ai 
trouvé est :
https://www.debian.org/doc/manuals/debian-reference/ch05.fr.html#_the_hostname_resolution

Il faut aller chez Arch pour des infos sur systemd-resolved (ta réf : 
https://wiki.archlinux.org/title/Systemd-resolved ).
C'est étrange, non ?


Selon moi Debian est une distribution généraliste qui ne place pas la 
convivialité avant la fonctionnalité (tout dépend de la cible visée).

Ce qui l'amène à être au milieu de l"échelle des docs/wiki, en caricaturant:
- docs complètes et pertinentes pour les distros installées à partir des 
sources -LFS, Gentoo...) et les distros binaires mais à paramétrer 
manuellement de manière poussée (Archlinux...)
- docs moyennes pour les distros moyennes (Debian, RHEL (plutôt mieux 
que Debian)...)
- docs de faible niveau pour les distros les plus conviviales (certaines 
distros n'ont quasiment pas de docs, Ubuntu a beaucoup de docs bonnes et 
mauvaises)

Re: Fwd: Tunnel openvpn - comment router ...

2023-07-23 Par sujet Michel

Le 23/07/2023 à 19:40, Michel Verdier a écrit :
> Le 23 juillet 2023 roger tarani a écrit :
> 
>> plein de choses mélangées avec un subject trop long
> 
> Là moi je suis perdu. S'il vous plaît utilisez un MUA correct en faisant
> des reply avec les belles indentations habituelles (>) sinon on ne
> sait plus qui a dit quoi et ce qui est répondu à "quoi".

Ah, toi aussi...

Re: Fwd: Tunnel openvpn - comment router ...

2023-07-23 Par sujet Michel Verdier

Le 23 juillet 2023 roger tarani a écrit :

> plein de choses mélangées avec un subject trop long

Là moi je suis perdu. S'il vous plaît utilisez un MUA correct en faisant
des reply avec les belles indentations habituelles (>) sinon on ne
sait plus qui a dit quoi et ce qui est répondu à "quoi".

Fwd: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?




- Mail transféré -
De: "roger tarani" 
À: "Liste Debian" 
Envoyé: Dimanche 23 Juillet 2023 18:47:14
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel?

- Mail original -
De: "didier gaumet" 
À: "Liste Debian" 
Envoyé: Dimanche 23 Juillet 2023 13:33:17
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel?

Le 23/07/2023 à 12:51, RogerT a écrit :


J'ai lu ton dernier message vers18h  qui parle du DNS géré par NM 
(https://wiki.gnome.org/Projects/NetworkManager/DNS)

Sur mon poste de travail, j'ai NM qui gérait /etc/resolv.conf , mais comme j'ai 
installé resolvconf, à présent :
/etc/resolv.conf -> ../run/resolvconf/resolv.conf

J'ai essayé d'arrêter resolvconf.service et de redémarrer 
NetworkManager.service .
Ça ne change rien.
Je ne sais pas trop quoi faire pour que NM gère la résolution de noms...
J'ai la tête qui fume.
Une piste pour sortir de ce bazar ?
Merci.




J'ajoute :
Il y a un truc qui m'échappe : après avoir arrêté et désactivé 
resolvconf.service, et redémarré NetworkManager (et networking.services), c'est 
bizarre d'avoir toujours ce lien symbolique qui semble lié à resolvconf (oui ?) 
:
  /etc/resolv.conf -> ../run/resolvconf/resolv.conf

Je n'ai pas redémarré.

J'imaginais que ce qui gérait la résolution de noms auparavant allait revenir 
(/etc/resolv.conf parlait d'un fichier généré par NM...)
Je suis dans le brouillard sur ce qui se passe exactement sur la gestion de 
réseau sur ce poste de travail.
Qu'ai-je oublié ?
Merci.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

- Mail original -
De: "didier gaumet" 
À: "Liste Debian" 
Envoyé: Dimanche 23 Juillet 2023 13:33:17
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel?

Le 23/07/2023 à 12:51, RogerT a écrit :

> Merci pour ta précision.
> 
> Donc ce tuto
> https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/ 
> <https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/>
> qui invite à faire ce qui suit est un peu bizarre, non ?
> 
> Save the changes and restart the *resolvconf.service* and 
> *systemd-resolved* or reboot the system.
> 
> $ sudo systemctl restart resolvconf.service
> 
> $ sudo systemctl restart systemd-resolved.service

Bon, avertissement habituel: je suis une tanche en réseaux.

Mais de ma fenêtre:
- /etc/resolv.conf permet la résolution de nom manuelle
- le but principal de resolvconf, systemd-resolved, openresolv permettre 
la résolution de noms automatique
- le but du tuto ci-dessus semble de vouloir garder un part de contrôle 
manuel prioritaire sur une gestion qu'on souhaite quand même automatique
- en soi et en théorie, pourquoi pas? Mais là où ça me semble piégeux et 
peu académique c'est que l'auteur fait ça en mélangeant les services 
systemd (resolvconf et systemd-resolved) alors qu'il partait de 
systemd-resolved et qu'en cherchant vite-fait sur internet, 
systemd-resolved tout seul et bien paramétré semble permettre cette 
touche de contrôle manuel, cf 
https://wiki.archlinux.org/title/Systemd-resolved#Manually

donc je peux me tromper parce que je ne suis pas qualifié mais ce tuto 
ne me semble pas très pertinent.


Je me disais bien...

En résumé, pour la résolution des noms, (après avoir recherché dans /etc/hosts 
pour "dns" défini dans /etc/nsswitch.conf) c'est /etc/resolv.conf qui est lu.
Il est soit :
- configuré à la main
- configuré automatiquement (par resolvconf ou systemd-resolved ou openresolv 
ou NetworkManager, etc.)

Cf. https://www.debian.org/doc/manuals/debian-reference/ch05.fr.html + 
discussions ici


> D’après les commentaires laissés sur ce site, les résultats ont été 
> variables…
> 
> resolvconf semble marcher.
> systemd-resolved aussi (bien qu’il faille toujours fouiller dans la doc 
> de systemd pour bien tout comprendre ; ensuite, ça va)
> 
> Quel outil de résolution de nom faut-il choisir pour quel usage ?
> Sur un poste de travail ?
> Sur un serveur ?

de ma fenêtre toujours, ça dépend surtout de l'efficacité, fiabilité de 
l'outil et de la pérennité du projet (équipe de maintenance qui fait son 
boulot). Je n'ai pas regardé du tout openresolv mais le projet 
resolvconf a l'air d'être hébergé sur les machines debian (Salsa) et le 
projet systemd-resolved me semble faire partie de la nébuleuse systemd 
donc il ne devrait pas casser la gueule non plus.

Perso, là, tout de suite, en étant ignare de la chose, si je devais 
faire du DNS automatique+manuel je prendrais systemd-resolved parce que 
je sais qu'il peut le faire et que j'aurais la flemme de chercher plus 
loin mais peut-être resolvconf peut-il faire la même chose (pas cherché
Et pour faire du DNS purement automatique je prendrais n'importe lequel.

> PS : Quand on installe debian pour la première fois, je ne me souviens 
> plus qu’on m’ait demandé quel service de résolution de nom je pouvais 
> choisir.
[...]

Ben sur un poste de travail, pas un serveur, ça me paraît logique: chez 
moi aucun des trois n'est installé

Tu dois cond gérer en manuel /etc/resolv.conf .

J'ai lu ton dernier message vers18h  qui parle du DNS géré par NM 
(https://wiki.gnome.org/Projects/NetworkManager/DNS)

Sur mon poste de travail, j'ai NM qui gérait /etc/resolv.conf , mais comme j'ai 
installé resolvconf, à présent :
/etc/resolv.conf -> ../run/resolvconf/resolv.conf

J'ai essayé d'arrêter resolvconf.service et de redémarrer 
NetworkManager.service .
Ça ne change rien.
Je ne sais pas trop quoi faire pour que NM gère la résolution de noms...
J'ai la tête qui fume.
Une piste pour sortir de ce bazar ?
Merci.


PS :
Le seul endroit du manuel debian qui parle de résolution de noms que j'ai 
trouvé est :
https://www.debian.org/doc/manuals/debian-reference/ch05.fr.html#_the_hostname_resolution

Il faut aller chez Arch pour des infos sur systemd-resolved (ta réf : 
https://wiki.archlinux.org/title/Systemd-resolved ).
C'est étrange, non ?

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

Tiens, en mangeant un truc sur le pouce tout à l(heure, je naviguais sur 
internet sur mon smartphone et j'ai trouvé un article du wiki Gnome sur 
la gestion de DNS par NetworkManager en liaison ou non avec dnsmasq ou 
systemd-resolved:

https://wiki.gnome.org/Projects/NetworkManager/DNS

J'ai pas en tête (lu en diagonale ton premier message) ton contexte 
exact mais si NetworkManager est installé, il rentre aussi dans le jeu, 
faut en tenir compte, je suppose

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?


Le 23/07/2023 à 12:51, RogerT a écrit :


Merci pour ta précision.

Donc ce tuto
https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/ 


qui invite à faire ce qui suit est un peu bizarre, non ?

Save the changes and restart the *resolvconf.service* and 
*systemd-resolved* or reboot the system.


$ sudo systemctl restart resolvconf.service

$ sudo systemctl restart systemd-resolved.service


Bon, avertissement habituel: je suis une tanche en réseaux.

Mais de ma fenêtre:
- /etc/resolv.conf permet la résolution de nom manuelle
- le but principal de resolvconf, systemd-resolved, openresolv permettre 
la résolution de noms automatique
- le but du tuto ci-dessus semble de vouloir garder un part de contrôle 
manuel prioritaire sur une gestion qu'on souhaite quand même automatique
- en soi et en théorie, pourquoi pas? Mais là où ça me semble piégeux et 
peu académique c'est que l'auteur fait ça en mélangeant les services 
systemd (resolvconf et systemd-resolved) alors qu'il partait de 
systemd-resolved et qu'en cherchant vite-fait sur internet, 
systemd-resolved tout seul et bien paramétré semble permettre cette 
touche de contrôle manuel, cf 
https://wiki.archlinux.org/title/Systemd-resolved#Manually


donc je peux me tromper parce que je ne suis pas qualifié mais ce tuto 
ne me semble pas très pertinent.


D’après les commentaires laissés sur ce site, les résultats ont été 
variables…


resolvconf semble marcher.
systemd-resolved aussi (bien qu’il faille toujours fouiller dans la doc 
de systemd pour bien tout comprendre ; ensuite, ça va)


Quel outil de résolution de nom faut-il choisir pour quel usage ?
Sur un poste de travail ?
Sur un serveur ?


de ma fenêtre toujours, ça dépend surtout de l'efficacité, fiabilité de 
l'outil et de la pérennité du projet (équipe de maintenance qui fait son 
boulot). Je n'ai pas regardé du tout openresolv mais le projet 
resolvconf a l'air d'être hébergé sur les machines debian (Salsa) et le 
projet systemd-resolved me semble faire partie de la nébuleuse systemd 
donc il ne devrait pas casser la gueule non plus.


Perso, là, tout de suite, en étant ignare de la chose, si je devais 
faire du DNS automatique+manuel je prendrais systemd-resolved parce que 
je sais qu'il peut le faire et que j'aurais la flemme de chercher plus 
loin mais peut-être resolvconf peut-il faire la même chose (pas cherché

Et pour faire du DNS purement automatique je prendrais n'importe lequel.

PS : Quand on installe debian pour la première fois, je ne me souviens 
plus qu’on m’ait demandé quel service de résolution de nom je pouvais 
choisir.

[...]

Ben sur un poste de travail, pas un serveur, ça me paraît logique: chez 
moi aucun des trois n'est installé

Fwd: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-23 Par sujet RogerT




Début du message transféré :

> De: RogerT 
> Date: 23 juillet 2023 à 12:52:19 UTC+2
> À: debian-user-french@lists.debian.org
> Objet: Rép. : Tunnel openvpn - comment router tout le trafic dedans ou bien 
> router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un 
> process dans SON propre tunnel?
> 
> Donc ce tuto
> https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/
> qui invite à faire ce qui suit est un peu bizarre, non ?
> 
> Save the changes and restart the resolvconf.service and systemd-resolved or 
> reboot the system.
> 
> 
Correction du copier-coller incomplet ou illisible :
$ sudo systemctl restart resolvconf.service
$ sudo systemctl restart systemd-resolved.service

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-23 Par sujet RogerT



> Le 23 juil. 2023 à 09:03, didier gaumet  a écrit :
> 
> Le 23/07/2023 à 05:18, roger.tar...@free.fr a écrit :
> 
> tout ça va bien au-delà de ce que je connais donc je réponds juste sur ceci:
> 
> [...]
>> Ma question : Faut-il bien choisir resolvconf ou bien systemd-resolved ? Et 
>> lequel privilégier ?
> [...]
> 
> ni l'un ni l'autre, il faut utiliser openresolv ;-)
> 
> Non, je plaisante: dans Debian ce sont trois alternatives qui remplissent les 
> mêmes fonctions. Je suppose (pas vérifié) qu'historiquement resolvconf est 
> apparu en premier et que les deux autres plus tard. Les paquets 
> systemd-revolved et openresolv fournissent le nom de paquet resolvconf 
> lorsqu'installés.
> Donc en fait à moins d'avoir des éléments d'information (fiabilité, rapidité 
> d'exécution, réactivité des développeurs, pérennité du projet, etc...) ou des 
> expérimentations qui te permettent de privilégier un outil plutôt qu'un 
> autre, tu choisis n'importe lequel.
> 
> C'est un peu comme le choix d'un client dhcp, avant on avait le choix 
> (dhcp-client, isc-dhcp (de mémoire)) et les solutions étaient 
> interchangeables.
> 
> Par contre il ne faut pas chercher à installer plusieurs outils assurant 
> simultanément la même fonction, sinon on risque les problèmes.

Merci pour ta précision. 

Donc ce tuto
https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/
qui invite à faire ce qui suit est un peu bizarre, non ?

Save the changes and restart the resolvconf.service and systemd-resolved or 
reboot the system.

$ sudo systemctl restart resolvconf.service

$ sudo systemctl restart systemd-resolved.service


D’après les commentaires laissés sur ce site, les résultats ont été variables…

resolvconf semble marcher. 
systemd-resolved aussi (bien qu’il faille toujours fouiller dans la doc de 
systemd pour bien tout comprendre ; ensuite, ça va)

Quel outil de résolution de nom faut-il choisir pour quel usage ?
Sur un poste de travail ?
Sur un serveur ?


PS : Quand on installe debian pour la première fois, je ne me souviens plus 
qu’on m’ait demandé quel service de résolution de nom je pouvais choisir. 
A ça on ajoute les infos variées de wiki debian et de différents sites plus ou 
moins à jour et, en tant que débutant ou bien moins débutant, on se retrouve 
perdu. Et surtout coupé d’internet sur sa machine de travail car on a perdu la 
résolution des noms !

Je ne crois pas avoir vu un mécanisme de surveillance qu’il y a bien un unique 
service de résolution de noms. Est-ce que ça existe ?

Merci.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?


Le 23/07/2023 à 05:18, roger.tar...@free.fr a écrit :

tout ça va bien au-delà de ce que je connais donc je réponds juste sur ceci:

[...]
Ma question : Faut-il bien choisir resolvconf ou bien systemd-resolved ? 
Et lequel privilégier ?

[...]

ni l'un ni l'autre, il faut utiliser openresolv ;-)

Non, je plaisante: dans Debian ce sont trois alternatives qui 
remplissent les mêmes fonctions. Je suppose (pas vérifié) 
qu'historiquement resolvconf est apparu en premier et que les deux 
autres plus tard. Les paquets systemd-revolved et openresolv fournissent 
le nom de paquet resolvconf lorsqu'installés.
Donc en fait à moins d'avoir des éléments d'information (fiabilité, 
rapidité d'exécution, réactivité des développeurs, pérennité du projet, 
etc...) ou des expérimentations qui te permettent de privilégier un 
outil plutôt qu'un autre, tu choisis n'importe lequel.


C'est un peu comme le choix d'un client dhcp, avant on avait le choix 
(dhcp-client, isc-dhcp (de mémoire)) et les solutions étaient 
interchangeables.


Par contre il ne faut pas chercher à installer plusieurs outils assurant 
simultanément la même fonction, sinon on risque les problèmes.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-22 Par sujet roger . tarani

A propos de la solution wireguard suggérée par NoSpam. 

J'ai lu beaucoup de bonnes choses sur wireguard. Je me suis lancé. 

La doc officielle [ https://www.wireguard.com/quickstart/ | 
https://www.wireguard.com/quickstart/ ] m'a paru trop courte et un peu floue. 
Le tuto [ 
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04
 | 
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04
 ] m'a bien aidé. Elle semble confirmer que la doc quickstart de wg est légère 
pour les débutants. 

J'ai configuré wg sur un serveur. 
J'ai ensuite configuré wg sur mon poste de travail (géré par Network-manager, 
qui génère /etc/resolv.conf ; ce qui m'a causé les problèmes attendus avec 
resolv.conf - voir plus loin). 

La configuration de wg apparaît différente et un peu plus simple qu'avec 
Openvpn (surtout quand on doit ajuster le fichier de config openvpn). 

Chaque pair/peer doit générer une paire de clef privée/publique en Base64 ; et 
il faut déclarer un pair/client sur le serveur par sa clef publique et son 
adresse IP par une commande : 
sudo wg set wg0 peer tFxQ25iWwGMgHuCFplWeXcrSnBpRcdfQSNnA4UVpXzg= allowed-ips 
10.8.0.2 

Ce serait bien de pouvoir utiliser un fichier de conf des clients. A suivre. 


PROBLEME 1/ : Résolution des noms sur mon poste de travail 
J'ai buté sur ma configuration réseau, avec un resolv.conf cassé puis réparé. 

Dans le tuto 
[ 
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04#step-9-connecting-the-wireguard-peer-to-the-tunnel
 | 
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04#step-9-connecting-the-wireguard-peer-to-the-tunnel
 ] 
il est indiqué d'installer resolvconf : 
[ 
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-22-04#step-9-connecting-the-wireguard-peer-to-the-tunnel
 ] $ sudo apt install resolvconf 
ça m'a planté mon resolv.conf qui était géré par NM = plus d'accès à internet. 

J'ai cru trouver une solution avec [ 
https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/ | 
https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/ ] 
qui proposait aussi d'installer resolvconf, comme dans le tuto digitalocean sur 
wireguard : 
$ sudo apt install resolvconf 

Mais il recommandait aussi d'installer systemd-resolved et de démarrer les DEUX 
services : 
$ sudo systemctl restart resolvconf.service
$ sudo systemctl restart systemd-resolved.service 
Dans mon cas, seulement démarrer resolvconf.service rétablissait mon 
resolv.conf 
tandis que démarrer ensuite systemd-resolved.service le cassait immédiatement ! 

J'en ai conclu qu'il fallait l'un ou l'autre et ait conservé seulement 
resolvconf.service (et ai désactivé systemd-resolved) 

D'ailleurs, certains se sont posé la question : 
[ 
https://askubuntu.com/questions/1181346/systemd-resolved-and-resolvconf-is-it-ok-to-have-both-installed
 | 
https://askubuntu.com/questions/1181346/systemd-resolved-and-resolvconf-is-it-ok-to-have-both-installed
 ] 

Cet article compare resolv.conf , [ 
https://manpages.ubuntu.com/manpages/xenial/en/man1/systemd-resolve.1.html | 
systemd-resolve ] , and Avahi (mais pas resolvconf) et semble indiquer qu'il 
faut en choisir un... 
[ https://www.baeldung.com/linux/resolve-conf-systemd-avahi | 
https://www.baeldung.com/linux/resolve-conf-systemd-avahi ] 

Je rappelle que j'utilise NM sur mon poste de travail debian 11. 

Ma question : Faut-il bien choisir resolvconf ou bien systemd-resolved ? Et 
lequel privilégier ? 



PROBLEME 2/ : Finir la configuration de wireguard 
Je crois avoir fait le plus gros : le serveur tourne, le client semble lancé 
d'après le serveur et le client (sauf interface wg0 en state UNKNOWN) 
La configuration est faite pour envoyer tout le traffic dans le tunnel vpn. 
Mais impossible de faire un ping du serveur vpn malgré la configuration du 
serveur autorisant les pings entrants (sauf bêtise...) 
Et impossible de naviguer avec un navigateur ou en CLI quand j'ai démarré le 
client wg. 
Seul le ping vers le serveur avec son adresse IP publique fonctionne (ainsi, 
seule passe la connexion mosh vers le serveur où tourne wg) 

CLIENT 
$ sudo wg-quick up wg0 
[#] ip link add wg0 type wireguard 
[#] wg setconf wg0 /dev/fd/63 
[#] ip -4 address add 10.8.0.2/24 dev wg0 
[#] ip link set mtu 1420 up dev wg0 
[#] resolvconf -a tun.wg0 -m 0 -x 
[#] ip rule add table 200 from 192.168.1.153 
[#] ip route add table 200 default via 192.168.1.153 

$ ip addr show wg0 
37: wg0:  mtu 1420 qdisc noqueue state UNKNOWN 
group default qlen 1000 
link/none 
inet 10.8.0.2/24 scope global wg0 
valid_lft forever preferred_lft forever 

indice : state UNKNOWN 
ça indique peut-être un truc qui cloche... 


SERVEUR 
Il voit le client taper à la porte ou alors tente de taper à sa porte : 
$ sudo wg 
interface: wg0 
public key: 3e2/5eGWQvJjs7wbTdOnCwJOoB8JLDN909xYZrdlIzE= 
private key: (hidden

Re: Configuration incomplète via GUI (applet gnome openvpn)

2023-07-21 Par sujet roger . tarani




- Mail original -
De: "didier gaumet" 
À: "Liste Debian" 
Envoyé: Vendredi 21 Juillet 2023 19:48:22
Objet: Re: Configuration incomplète via GUI (applet gnome openvpn)

Le 21/07/2023 à 19:10, roger.tar...@free.fr a écrit :
[...]
> *Avec nm-openvpn, comment peut-on configurer un tunnel openvpn à partir 
> d'un fichier truc.conf openvpn 100% opérationnel ?*
[...]

Je n'y connais absolument rien, peut-être (je n'ai pas cherché parce que 
le sujet m'est totalement étranger) que l'outil CLI couvre plus de 
possibilités que l'outil GUI voire l'outil TUI?

Il semble que ce soit possible avec nmcli:
https://codybonney.com/importing-ovpn-configuration-file-into-network-manager/


Merci.
Oui.
Ça ne fait rien de plus que "import from file..." depuis l'applet.
Il faut connaître la manière de configurer via le GUI ce qui est dans le 
fichier de conf openvpn.

Re: Configuration incomplète via GUI (applet gnome openvpn)

2023-07-21 Par sujet didier gaumet


Le 21/07/2023 à 19:10, roger.tar...@free.fr a écrit :
[...]
*Avec nm-openvpn, comment peut-on configurer un tunnel openvpn à partir 
d'un fichier truc.conf openvpn 100% opérationnel ?*

[...]

Je n'y connais absolument rien, peut-être (je n'ai pas cherché parce que 
le sujet m'est totalement étranger) que l'outil CLI couvre plus de 
possibilités que l'outil GUI voire l'outil TUI?


Il semble que ce soit possible avec nmcli:
https://codybonney.com/importing-ovpn-configuration-file-into-network-manager/

Configuration incomplète via GUI (applet gnome openvpn)

2023-07-21 Par sujet roger . tarani

Bonjour, 

Aucun problème pour ouvrir une connexion openvpn en CLI 
sudo openvpen truc.conf 
Tous les flux en CLI ou via le navigateur passent par le tunnel. 

Si j'utilise le GUI, ce que j'ai configuré crée une connexion openvpn (vue sur 
le serveur) mais rien ne passe par le tunnel. 

~/.cert/nm-openvpn contient les 4 fichiers d'extension utilisés par le GUI : 
.ovpn-ca.pem 
.ovpn-cert.pem 
.ovpn-extra-certs.pem 
.ovpn-key.pem 
C'est ancien, je ne me souviens plus les avoir fournis. Ils ont peut-être été 
générés. 


Le fichier openvpn truc.conf est valide depuis des années. 
Il commence par ce qui suit. 
Il y a notamment 'redirect-gateway' qui dit de détourner tout le flux vers le 
tunnel, à ma connaissance. 

$ cat truc.conf 
client 
remote xxx.xxx.xxx.xxx 6504 
proto udp 
nobind 
dev-type tun 

pull 
dev tun0 
redirect-gateway 
auth-user-pass login.txt 
auth-retry interact 
fragment 1452 
mssfix 1452 
explicit-exit-notify 3 
cipher AES-256-CBC 
remote-cert-tls server 
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 
xx" 

certificats 
etc. 
=== 


Je ne vous remets pas de copie de tous les panneaux de l'applet nm-openvpn. 

Je viens de recommencer une configuration de zéro : 
- copier le fichier truc.conf (opérationnel en CLI) dans ~/.cert/nm-openvpn/ 
(propriétaire root) 
- VPN settings : import from file 
-> à partir de truc.conf, le GUI crée bien 4 fichiers (propriétaire local) : 
truc-ca.pem 
truc-cert.pem 
truc-extra-certs.pem 
truc-key.pem 
- j'ajoute l'id et le pwd de l'utilisateur openvpn dans le panneau ; voire 
l'éventuel pwd de la clef 
- je peux lancer la connexion en un clic mais rien ne passe dans le tunnel 
(CLI, navigateur) 

Il apparaît que les paramètres du fichier truc.conf ne sont pas repris par le 
GUI qui importe le minimum : adr IP, port, les morceaux de certificats et la 
clef. 


Avec nm-openvpn, comment peut-on configurer un tunnel openvpn à partir d'un 
fichier truc.conf openvpn 100% opérationnel ? 

Il serait utile d'importer tout ce qui existe et de dire ce qui n'a pas été 
importé. 
Je ne sais pas qui maintient l'applet ni comment le lui signaler ?... si vous 
savez...

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-09 Par sujet RogerT

Wireguard est encore différent de L2TP/IPsec et de OpenVPN. 
Très intéressant. 

Merci. 

> Le 9 juil. 2023 à 18:08, NoSpam  a écrit :
> Il te faut du marquage aussi via nftables ou iptables. Wireguard est 
> effectivement alternatif à openvpn, mais plus rapide, plus facile à 
> configurer, technologie récente proche du noyau.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-09 Par sujet roger . tarani

Je commençais juste à me mettre au marquage de paquet avec iptables 

Je vais aussi tester ce wireguard. 

Merci pour ton aide. Ça me fait gagner un temps précieux. 



De: "NoSpam"  
À: "Liste Debian"  
Envoyé: Dimanche 9 Juillet 2023 18:08:15 
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel? 



Il te faut du marquage aussi via nftables ou iptables. Wireguard est 
effectivement alternatif à openvpn, mais plus rapide, plus facile à configurer, 
technologie récente proche du noyau. 
Le 09/07/2023 à 17:23, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a 
écrit : 



Merci. 
Je vais d'abord plancher sur iproute2 puisque c'est la norme. 
wireguard : je croyais que c'était juste un vpn alternatif à openpvn ou autre. 
A creuser pour moi. 



De: "NoSpam" [ mailto:no-s...@tootai.net |  ] 
À: "Liste Debian" [ mailto:debian-user-french@lists.debian.org | 
 ] 
Envoyé: Dimanche 9 Juillet 2023 17:00:14 
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel? 



Cela s'appelle du routage, iproute2 installé d'office, fait cela en faisant du 
marquage. Sinon wireguard permet également de router via sa configuration 
Le 09/07/2023 à 14:11, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a 
écrit : 

BQ_BEGIN

Bonjour, 

Je peux me connecter à un serveur openvpn en CLI (sudo openvpn truc.conf) ou 
par le GUI (gnome VPN settings : clic). 

Je vois cette connexion client sur le serveur (10.0.0.x). 

$ ip addr 
2: enp0s25:  mtu 1500 qdisc pfifo_fast master 
br0 state UP group default qlen 1000 
link/ether 78:e7:d1:85:f0:79 brd ff:ff:ff:ff:ff:ff 

3: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000 
link/ether 92:fc:e6:5d:91:eb brd ff:ff:ff:ff:ff:ff 
inet 192.168.1.153/24 brd 192.168.1.255 scope global noprefixroute br0 
valid_lft forever preferred_lft forever 
inet6 2a02: /64 scope global dynamic 
noprefixroute 
valid_lft 604402sec preferred_lft 604402sec 
inet6 fe80::.../64 scope link noprefixroute 
valid_lft forever preferred_lft forever 
... 
21: tun0:  mtu 1500 qdisc pfifo_fast 
state UNKNOWN group default qlen 500 
link/none 
inet 10.0.0.2 peer 10.0.0.5/32 scope global tun0 
valid_lft forever preferred_lft forever 
inet6 fe80::./64 scope link stable-privacy 
valid_lft forever preferred_lft forever 


Oui, il y a un bridge car j'avais du utiliser ce mécanisme pour me tirer d'un 
problème de connexion. Avec nmcli. 
Ça fonctionne bien ainsi depuis des années. 

Malgré le tunnel, depuis un autre terminal ou depuis un navigateur ma machine a 
toujours la même adresse IP (celle publique fournie par mon opérateur), bien 
que je sois connecté au vpn. 

Je suis autonome en réseau pour des choses ordinaires . 
Là c'est plus compliqué... 


Voici le fichier .ovpn (freebox) qui bascule toutes les cnx de la machine dans 
le VPN (sans les certificats) 

client 
remote $REMOTE_IP 6504 
proto udp 
nobind 
dev-type tun 

pull 
dev tun0 
redirect-gateway 
auth-user-pass login.txt 
auth-retry interact 
fragment 1452 
mssfix 1452 
explicit-exit-notify 3 

remote-cert-tls server 
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 
xxx" 

cipher AES-256-CBC 


Et celui qui ne fait pas ce que j'attends : 

dev tun 
tls-client 
remote $REMOTE_IP 1195 
pull 
proto udp 
script-security 2 
comp-lzo 
reneg-sec 0 
cipher AES-256-CBC 
auth SHA512 
auth-user-pass 


Le fichier .opvpn m'est fourni par le détenteur du serveur openvpn. 
Je ne suis pas expert en openvpn bien qu'autonome pour l'utiliser. 

Je me dis que le problème vient de ce fichier de configuration openvpn. 

Je fouille donc du côté d'openvpn "Comment router tout le trafic d'une machine 
dans un tunnel openvpn"... 

Résultat : 
Il se pourrait que ce soit la directive suivante qui permette de router tout le 
trafic dans le tunnel vpn : 
redirect-gateway 
ou 
redirect-gateway def1 
Ou 
push "redirect-gateway" 
push "redirect-gateway def1" 

Qu'en pensez-vous ? 

Quelle est la manière de faire ça proprement ? 
- sans modifier le fichier .opvpn fourni 
- en le modifiant a minima (ex : ajouter la directive redirect-gateway ) 


Je vais plus loin : 
J'ai souvent besoin de me connecter à diverses machines en CLI ou avec un 
navigateur via un tunnel. 
Je sais faire ça successivement mais pas simultanément. 

Je veux éviter de devoir gérer successivement chaque tunnel unique. 
J'ai aussi des connexions RDP actives qui doivent rester hors des tunnels. 

Comment puis-je router SIMULTANEMENT le trafic de tel terminal, ou telle 
fenêtre de navigateur dans le tunnel ssh/vpn qui LUI correspond, sans touc

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-09 Par sujet NoSpam

Il te faut du marquage aussi via nftables ou iptables. Wireguard est 
effectivement alternatif à openvpn, mais plus rapide, plus facile à 
configurer, technologie récente proche du noyau.


Le 09/07/2023 à 17:23, roger.tar...@free.fr a écrit :

Merci.
Je vais d'abord plancher sur iproute2 puisque c'est la norme.
wireguard : je croyais que c'était juste un vpn alternatif à openpvn 
ou autre. A creuser pour moi.




*De: *"NoSpam" 
*À: *"Liste Debian" 
*Envoyé: *Dimanche 9 Juillet 2023 17:00:14
*Objet: *Re: Tunnel openvpn - comment router tout le trafic dedans ou 
bien router simultanément le trafic d'un terminal/d'une fenêtre de 
navigateur/d'un process dans SON propre tunnel?


Cela s'appelle du routage, iproute2 installé d'office, fait cela en 
faisant du marquage. Sinon wireguard permet également de router via sa 
configuration


Le 09/07/2023 à 14:11, roger.tar...@free.fr a écrit :

Bonjour,

Je peux me connecter à un serveur openvpn en CLI (sudo openvpn
truc.conf) ou par le GUI (gnome VPN settings : clic).

Je vois cette connexion client sur le serveur (10.0.0.x).

$ ip addr
2: enp0s25:  mtu 1500 qdisc
pfifo_fast master br0 state UP group default qlen 1000
link/ether 78:e7:d1:85:f0:79 brd ff:ff:ff:ff:ff:ff

3: br0:  mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether 92:fc:e6:5d:91:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.153/24 brd 192.168.1.255 scope global noprefixroute br0
valid_lft forever preferred_lft forever
inet6 2a02: /64 scope global
dynamic noprefixroute
valid_lft 604402sec preferred_lft 604402sec
inet6 fe80::.../64 scope link noprefixroute
valid_lft forever preferred_lft forever
...
21: tun0:  mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 10.0.0.2 peer 10.0.0.5/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::./64 scope link
stable-privacy
valid_lft forever preferred_lft forever


Oui, il y a un bridge car j'avais du utiliser ce mécanisme pour me
tirer d'un problème de connexion. Avec nmcli.
Ça fonctionne bien ainsi depuis des années.

Malgré le tunnel, depuis un autre terminal ou depuis un navigateur
ma machine a toujours la même adresse IP (celle publique fournie
par mon opérateur), bien que je sois connecté au vpn.

Je suis autonome en réseau pour des choses ordinaires.
Là c'est plus compliqué...


Voici le fichier .ovpn (freebox) qui bascule toutes les cnx de la
machine dans le VPN (sans les certificats)

client
remote $REMOTE_IP 6504
proto udp
nobind
dev-type tun

pull
dev tun0
redirect-gateway
auth-user-pass login.txt
auth-retry interact
fragment 1452
mssfix 1452
explicit-exit-notify 3

remote-cert-tls server
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server
xxx"

cipher AES-256-CBC


Et celui qui ne fait pas ce que j'attends :

dev tun
tls-client
remote $REMOTE_IP 1195
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass


Le fichier .opvpn m'est fourni par le détenteur du serveur openvpn.
Je ne suis pas expert en openvpn bien qu'autonome pour l'utiliser.

Je me dis que le problème vient de ce fichier de configuration
openvpn.

Je fouille donc du côté d'openvpn "Comment router tout le trafic
d'une machine dans un tunnel openvpn"...

Résultat :
Il se pourrait que ce soit la directive suivante qui permette de
router tout le trafic dans le tunnel vpn :
redirect-gateway
ou
redirect-gateway def1
Ou
push "redirect-gateway"
push "redirect-gateway def1"

Qu'en pensez-vous ?

Quelle est la manière de faire ça proprement ?
- sans modifier le fichier .opvpn fourni
- en le modifiant a minima (ex : ajouter la directive
redirect-gateway)


Je vais plus loin :
J'ai souvent besoin de me connecter à diverses machines en CLI ou
avec un navigateur via un tunnel.
Je sais faire ça successivement mais pas simultanément.

Je veux éviter de devoir gérer successivement chaque tunnel unique.
J'ai aussi des connexions RDP actives qui doivent rester hors des
tunnels.

Comment puis-je router SIMULTANEMENT le trafic de tel terminal, ou
telle fenêtre de navigateur dans le tunnel ssh/vpn qui LUI
correspond, sans toucher au trafic des autres connexions (RDP, etc.) ?
Ça c'est du vrai réseau, pas ordinaire (pour moi)...!

Merci.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-09 Par sujet roger . tarani

Merci. 
Je vais d'abord plancher sur iproute2 puisque c'est la norme. 
wireguard : je croyais que c'était juste un vpn alternatif à openpvn ou autre. 
A creuser pour moi. 



De: "NoSpam"  
À: "Liste Debian"  
Envoyé: Dimanche 9 Juillet 2023 17:00:14 
Objet: Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router 
simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process 
dans SON propre tunnel? 



Cela s'appelle du routage, iproute2 installé d'office, fait cela en faisant du 
marquage. Sinon wireguard permet également de router via sa configuration 
Le 09/07/2023 à 14:11, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a 
écrit : 



Bonjour, 

Je peux me connecter à un serveur openvpn en CLI (sudo openvpn truc.conf) ou 
par le GUI (gnome VPN settings : clic). 

Je vois cette connexion client sur le serveur (10.0.0.x). 

$ ip addr 
2: enp0s25:  mtu 1500 qdisc pfifo_fast master 
br0 state UP group default qlen 1000 
link/ether 78:e7:d1:85:f0:79 brd ff:ff:ff:ff:ff:ff 

3: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000 
link/ether 92:fc:e6:5d:91:eb brd ff:ff:ff:ff:ff:ff 
inet 192.168.1.153/24 brd 192.168.1.255 scope global noprefixroute br0 
valid_lft forever preferred_lft forever 
inet6 2a02: /64 scope global dynamic 
noprefixroute 
valid_lft 604402sec preferred_lft 604402sec 
inet6 fe80::.../64 scope link noprefixroute 
valid_lft forever preferred_lft forever 
... 
21: tun0:  mtu 1500 qdisc pfifo_fast 
state UNKNOWN group default qlen 500 
link/none 
inet 10.0.0.2 peer 10.0.0.5/32 scope global tun0 
valid_lft forever preferred_lft forever 
inet6 fe80::./64 scope link stable-privacy 
valid_lft forever preferred_lft forever 


Oui, il y a un bridge car j'avais du utiliser ce mécanisme pour me tirer d'un 
problème de connexion. Avec nmcli. 
Ça fonctionne bien ainsi depuis des années. 

Malgré le tunnel, depuis un autre terminal ou depuis un navigateur ma machine a 
toujours la même adresse IP (celle publique fournie par mon opérateur), bien 
que je sois connecté au vpn. 

Je suis autonome en réseau pour des choses ordinaires . 
Là c'est plus compliqué... 


Voici le fichier .ovpn (freebox) qui bascule toutes les cnx de la machine dans 
le VPN (sans les certificats) 

client 
remote $REMOTE_IP 6504 
proto udp 
nobind 
dev-type tun 

pull 
dev tun0 
redirect-gateway 
auth-user-pass login.txt 
auth-retry interact 
fragment 1452 
mssfix 1452 
explicit-exit-notify 3 

remote-cert-tls server 
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 
xxx" 

cipher AES-256-CBC 


Et celui qui ne fait pas ce que j'attends : 

dev tun 
tls-client 
remote $REMOTE_IP 1195 
pull 
proto udp 
script-security 2 
comp-lzo 
reneg-sec 0 
cipher AES-256-CBC 
auth SHA512 
auth-user-pass 


Le fichier .opvpn m'est fourni par le détenteur du serveur openvpn. 
Je ne suis pas expert en openvpn bien qu'autonome pour l'utiliser. 

Je me dis que le problème vient de ce fichier de configuration openvpn. 

Je fouille donc du côté d'openvpn "Comment router tout le trafic d'une machine 
dans un tunnel openvpn"... 

Résultat : 
Il se pourrait que ce soit la directive suivante qui permette de router tout le 
trafic dans le tunnel vpn : 
redirect-gateway 
ou 
redirect-gateway def1 
Ou 
push "redirect-gateway" 
push "redirect-gateway def1" 

Qu'en pensez-vous ? 

Quelle est la manière de faire ça proprement ? 
- sans modifier le fichier .opvpn fourni 
- en le modifiant a minima (ex : ajouter la directive redirect-gateway ) 


Je vais plus loin : 
J'ai souvent besoin de me connecter à diverses machines en CLI ou avec un 
navigateur via un tunnel. 
Je sais faire ça successivement mais pas simultanément. 

Je veux éviter de devoir gérer successivement chaque tunnel unique. 
J'ai aussi des connexions RDP actives qui doivent rester hors des tunnels. 

Comment puis-je router SIMULTANEMENT le trafic de tel terminal, ou telle 
fenêtre de navigateur dans le tunnel ssh/vpn qui LUI correspond, sans toucher 
au trafic des autres connexions (RDP, etc.) ? 
Ça c'est du vrai réseau, pas ordinaire (pour moi)...! 

Merci.

Re: Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-09 Par sujet NoSpam

Cela s'appelle du routage, iproute2 installé d'office, fait cela en 
faisant du marquage. Sinon wireguard permet également de router via sa 
configuration


Le 09/07/2023 à 14:11, roger.tar...@free.fr a écrit :

Bonjour,

Je peux me connecter à un serveur openvpn en CLI (sudo openvpn 
truc.conf) ou par le GUI (gnome VPN settings : clic).


Je vois cette connexion client sur le serveur (10.0.0.x).

$ ip addr
2: enp0s25:  mtu 1500 qdisc 
pfifo_fast master br0 state UP group default qlen 1000

    link/ether 78:e7:d1:85:f0:79 brd ff:ff:ff:ff:ff:ff

3: br0:  mtu 1500 qdisc noqueue state 
UP group default qlen 1000

    link/ether 92:fc:e6:5d:91:eb brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.153/24 brd 192.168.1.255 scope global noprefixroute br0
   valid_lft forever preferred_lft forever
    inet6 2a02: /64 scope global 
dynamic noprefixroute

   valid_lft 604402sec preferred_lft 604402sec
    inet6 fe80::.../64 scope link noprefixroute
   valid_lft forever preferred_lft forever
...
21: tun0:  mtu 1500 qdisc 
pfifo_fast state UNKNOWN group default qlen 500

    link/none
    inet 10.0.0.2 peer 10.0.0.5/32 scope global tun0
   valid_lft forever preferred_lft forever
    inet6 fe80::./64 scope link 
stable-privacy

   valid_lft forever preferred_lft forever


Oui, il y a un bridge car j'avais du utiliser ce mécanisme pour me 
tirer d'un problème de connexion. Avec nmcli.

Ça fonctionne bien ainsi depuis des années.

Malgré le tunnel, depuis un autre terminal ou depuis un navigateur ma 
machine a toujours la même adresse IP (celle publique fournie par mon 
opérateur), bien que je sois connecté au vpn.


Je suis autonome en réseau pour des choses ordinaires.
Là c'est plus compliqué...


Voici le fichier .ovpn (freebox) qui bascule toutes les cnx de la 
machine dans le VPN (sans les certificats)


client
remote $REMOTE_IP 6504
proto udp
nobind
dev-type tun

pull
dev tun0
redirect-gateway
auth-user-pass login.txt
auth-retry interact
fragment 1452
mssfix 1452
explicit-exit-notify 3

remote-cert-tls server
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 
xxx"


cipher AES-256-CBC


Et celui qui ne fait pas ce que j'attends :

dev tun
tls-client
remote $REMOTE_IP 1195
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass


Le fichier .opvpn m'est fourni par le détenteur du serveur openvpn.
Je ne suis pas expert en openvpn bien qu'autonome pour l'utiliser.

Je me dis que le problème vient de ce fichier de configuration openvpn.

Je fouille donc du côté d'openvpn "Comment router tout le trafic d'une 
machine dans un tunnel openvpn"...


Résultat :
Il se pourrait que ce soit la directive suivante qui permette de 
router tout le trafic dans le tunnel vpn :

redirect-gateway
ou
  redirect-gateway def1
Ou
push "redirect-gateway"
push "redirect-gateway def1"

Qu'en pensez-vous ?

Quelle est la manière de faire ça proprement ?
- sans modifier le fichier .opvpn fourni
- en le modifiant a minima (ex : ajouter la directive redirect-gateway)


Je vais plus loin :
J'ai souvent besoin de me connecter à diverses machines en CLI ou avec 
un navigateur via un tunnel.

Je sais faire ça successivement mais pas simultanément.

Je veux éviter de devoir gérer successivement chaque tunnel unique.
J'ai aussi des connexions RDP actives qui doivent rester hors des tunnels.

Comment puis-je router SIMULTANEMENT le trafic de tel terminal, ou 
telle fenêtre de navigateur dans le tunnel ssh/vpn qui LUI correspond, 
sans toucher au trafic des autres connexions (RDP, etc.) ?

Ça c'est du vrai réseau, pas ordinaire (pour moi)...!

Merci.

Tunnel openvpn - comment router tout le trafic dedans ou bien router simultanément le trafic d'un terminal/d'une fenêtre de navigateur/d'un process dans SON propre tunnel?

2023-07-09 Par sujet roger . tarani

Bonjour, 

Je peux me connecter à un serveur openvpn en CLI (sudo openvpn truc.conf) ou 
par le GUI (gnome VPN settings : clic). 

Je vois cette connexion client sur le serveur (10.0.0.x). 

$ ip addr 
2: enp0s25:  mtu 1500 qdisc pfifo_fast master 
br0 state UP group default qlen 1000 
link/ether 78:e7:d1:85:f0:79 brd ff:ff:ff:ff:ff:ff 

3: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000 
link/ether 92:fc:e6:5d:91:eb brd ff:ff:ff:ff:ff:ff 
inet 192.168.1.153/24 brd 192.168.1.255 scope global noprefixroute br0 
valid_lft forever preferred_lft forever 
inet6 2a02: /64 scope global dynamic 
noprefixroute 
valid_lft 604402sec preferred_lft 604402sec 
inet6 fe80::.../64 scope link noprefixroute 
valid_lft forever preferred_lft forever 
... 
21: tun0:  mtu 1500 qdisc pfifo_fast 
state UNKNOWN group default qlen 500 
link/none 
inet 10.0.0.2 peer 10.0.0.5/32 scope global tun0 
valid_lft forever preferred_lft forever 
inet6 fe80::./64 scope link stable-privacy 
valid_lft forever preferred_lft forever 


Oui, il y a un bridge car j'avais du utiliser ce mécanisme pour me tirer d'un 
problème de connexion. Avec nmcli. 
Ça fonctionne bien ainsi depuis des années. 

Malgré le tunnel, depuis un autre terminal ou depuis un navigateur ma machine a 
toujours la même adresse IP (celle publique fournie par mon opérateur), bien 
que je sois connecté au vpn. 

Je suis autonome en réseau pour des choses ordinaires . 
Là c'est plus compliqué... 


Voici le fichier .ovpn (freebox) qui bascule toutes les cnx de la machine dans 
le VPN (sans les certificats) 

client 
remote $REMOTE_IP 6504 
proto udp 
nobind 
dev-type tun 

pull 
dev tun0 
redirect-gateway 
auth-user-pass login.txt 
auth-retry interact 
fragment 1452 
mssfix 1452 
explicit-exit-notify 3 

remote-cert-tls server 
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 
xxx" 

cipher AES-256-CBC 


Et celui qui ne fait pas ce que j'attends : 

dev tun 
tls-client 
remote $REMOTE_IP 1195 
pull 
proto udp 
script-security 2 
comp-lzo 
reneg-sec 0 
cipher AES-256-CBC 
auth SHA512 
auth-user-pass 


Le fichier .opvpn m'est fourni par le détenteur du serveur openvpn. 
Je ne suis pas expert en openvpn bien qu'autonome pour l'utiliser. 

Je me dis que le problème vient de ce fichier de configuration openvpn. 

Je fouille donc du côté d'openvpn "Comment router tout le trafic d'une machine 
dans un tunnel openvpn"... 

Résultat : 
Il se pourrait que ce soit la directive suivante qui permette de router tout le 
trafic dans le tunnel vpn : 
redirect-gateway 
ou 
redirect-gateway def1 
Ou 
push "redirect-gateway" 
push "redirect-gateway def1" 

Qu'en pensez-vous ? 

Quelle est la manière de faire ça proprement ? 
- sans modifier le fichier .opvpn fourni 
- en le modifiant a minima (ex : ajouter la directive redirect-gateway ) 


Je vais plus loin : 
J'ai souvent besoin de me connecter à diverses machines en CLI ou avec un 
navigateur via un tunnel. 
Je sais faire ça successivement mais pas simultanément. 

Je veux éviter de devoir gérer successivement chaque tunnel unique. 
J'ai aussi des connexions RDP actives qui doivent rester hors des tunnels. 

Comment puis-je router SIMULTANEMENT le trafic de tel terminal, ou telle 
fenêtre de navigateur dans le tunnel ssh/vpn qui LUI correspond, sans toucher 
au trafic des autres connexions (RDP, etc.) ? 
Ça c'est du vrai réseau, pas ordinaire (pour moi)...! 

Merci.

Re: MTU avec OpenVPN

2022-10-21 Par sujet Basile Starynkevitch




On 21/10/2022 09:55, Olivier wrote:

C'est probablement la bonne explication !
Merci de l'avoir fournie.

Pour bien faire, il me faudrait maintenant un moyen pour déterminer la
taille des informations transmises ;-)


La commande  ip -s link affiche le nombre d'octets transmis (reçus ou 
émis) sur chaque interface réseau.


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: MTU avec OpenVPN

2022-10-21 Par sujet Olivier

C'est probablement la bonne explication !
Merci de l'avoir fournie.

Pour bien faire, il me faudrait maintenant un moyen pour déterminer la
taille des informations transmises ;-)
mais c'est une autre histoire.
Merci à tous.

Le jeu. 20 oct. 2022 à 20:19, Th.A.C  a écrit :
>
>
>
> Le 20/10/2022 à 18:02, Olivier a écrit :
> > L'existence du MTU ne me choque pas: je pense avoir bien compris
> > l'origine de cette limite.
> > Ce qui m'étonne que la valeur mesuré soit la même dans les deux cas.
> >
> > J'aurai imagine qu'OpenVPN ajoute un encapsulage qui diminue la valeur
> > du MTU quand j'emprunte le VPN.
> > Or il se trouve que non.
>
> la MTU n'est pas la taille des informations transmises dans un paquet,
> mais la taille du paquet lui-même.
>
> On pourrait comparer ca à un wagon dont la taille est la MTU.
> La quantité totale des données est le wagon.
> Les données utiles sont à l'intérieur 'encapsulées'(ou pas) par openvpn.
>
>
> OpenVPN n'a donc aucune raison de diminuer la MTU, d'autant que ca a
> tendance à réduire la vitesse globale de transmission et que ce n'est
> pas du tout son rôle.
>

Re: MTU avec OpenVPN

2022-10-20 Par sujet Th.A.C





Le 20/10/2022 à 18:02, Olivier a écrit :

L'existence du MTU ne me choque pas: je pense avoir bien compris
l'origine de cette limite.
Ce qui m'étonne que la valeur mesuré soit la même dans les deux cas.

J'aurai imagine qu'OpenVPN ajoute un encapsulage qui diminue la valeur
du MTU quand j'emprunte le VPN.
Or il se trouve que non.


la MTU n'est pas la taille des informations transmises dans un paquet, 
mais la taille du paquet lui-même.


On pourrait comparer ca à un wagon dont la taille est la MTU.
La quantité totale des données est le wagon.
Les données utiles sont à l'intérieur 'encapsulées'(ou pas) par openvpn.


OpenVPN n'a donc aucune raison de diminuer la MTU, d'autant que ca a 
tendance à réduire la vitesse globale de transmission et que ce n'est 
pas du tout son rôle.

Re: MTU avec OpenVPN

2022-10-20 Par sujet Olivier

L'existence du MTU ne me choque pas: je pense avoir bien compris
l'origine de cette limite.
Ce qui m'étonne que la valeur mesuré soit la même dans les deux cas.

J'aurai imagine qu'OpenVPN ajoute un encapsulage qui diminue la valeur
du MTU quand j'emprunte le VPN.
Or il se trouve que non.

Le jeu. 20 oct. 2022 à 17:55, Basile Starynkevitch
 a écrit :
>
>
> On 20/10/2022 17:35, Olivier wrote:
>
> Bonjour,
>
> En essayant de déterminer la cause d'une anomalie, j'ai vérifié le MTU
> entre mon PC et mon serveur OpenVPN, sur Internet.
>
> J'ai fait depuis mon PC:
> ping -M do -c1 -s 1472 ip_publique_du_serveur
> ping -M do -c1 -s 1472 ip_privée_du_serveur
>
> J'ai été surpris d'obtenir le même résultat (réussite avec 1472 et
> échec avec 1473).
>
> Qu'en pensez-vous ?
> Est-il normal d'obtenir la même valeur ?
>
>
> Oui. Cette limite de 1472 octets est liée au protocole IPv4 dont les paquets 
> ont une taille définie.
>
> Les détails se comprennent en lisant un gros pavé sur les réseaux 
> informatiques. Par exemple un livre de  Guy Pujolles sur les réseaux.
>
> Pour ma part, je cherche des partenaires pour un consortium ANR ou 
> HorizonEurope intéressé par l'intelligence artificielle symbolique (via 
> l'embryon de logiciel RefPerSys en http://refpersys.org/ )
>
> Contactez moi alors aussi sur ma boite aux lettres professionnelle (au CEA, 
> LIST ...) en basile.starynkevi...@cea.fr ...
>
> --
> Basile Starynkevitch  
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/
>

Re: MTU avec OpenVPN

2022-10-20 Par sujet Basile Starynkevitch



On 20/10/2022 17:35, Olivier wrote:

Bonjour,

En essayant de déterminer la cause d'une anomalie, j'ai vérifié le MTU
entre mon PC et mon serveur OpenVPN, sur Internet.

J'ai fait depuis mon PC:
ping -M do -c1 -s 1472 ip_publique_du_serveur
ping -M do -c1 -s 1472 ip_privée_du_serveur

J'ai été surpris d'obtenir le même résultat (réussite avec 1472 et
échec avec 1473).

Qu'en pensez-vous ?
Est-il normal d'obtenir la même valeur ?



Oui. Cette limite de 1472 octets est liée au protocole IPv4 dont les 
paquets ont une taille définie.


Les détails se comprennent en lisant un gros pavé sur les réseaux 
informatiques. Par exemple un livre 
<https://livre.fnac.com/a11161804/Guy-Pujolle-Les-reseaux> de  Guy 
Pujolles sur les réseaux.


Pour ma part, je cherche des partenaires pour un consortium ANR ou 
HorizonEurope intéressé par l'intelligence artificielle symbolique (via 
l'embryon de logiciel RefPerSys en http://refpersys.org/ )


Contactez moi alors aussi sur ma boite aux lettres professionnelle (au 
CEA, LIST <https://list.cea.fr/> ...) en basile.starynkevi...@cea.fr ...


--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

MTU avec OpenVPN

2022-10-20 Par sujet Olivier

Bonjour,

En essayant de déterminer la cause d'une anomalie, j'ai vérifié le MTU
entre mon PC et mon serveur OpenVPN, sur Internet.

J'ai fait depuis mon PC:
ping -M do -c1 -s 1472 ip_publique_du_serveur
ping -M do -c1 -s 1472 ip_privée_du_serveur

J'ai été surpris d'obtenir le même résultat (réussite avec 1472 et
échec avec 1473).

Qu'en pensez-vous ?
Est-il normal d'obtenir la même valeur ?

Slts

[RESOLU] Re: Coupures OpenVPN (Inactivity timeout)

2022-01-28 Par sujet Olivier

Je me sens un peu bête mais j'avais deux instances du client OpenVPN
qui "tournaient en parallèle". En supprimant l'une des deux instances,
tout est rentré dans l'ordre.

Merci pour votre aide !



Le jeu. 27 janv. 2022 à 16:54, NoSpam  a écrit :
>
> Bonjour
>
> Le 27/01/2022 à 16:41, Olivier a écrit :
> > Bonjour,
> >
> > J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un
> > hébergeur Internet.
> > À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine
> > Debian de toutes les générations (Jessie, à Bullseye).
> > Depuis quelques mois, j'observe des déconnexions temporaires.
> >
> > Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer.
> >
> > Dans les logs du client, j'ai la séquence ci-après répétée toutes les
> > 230 sec.2022-01-27 15:41:24 [server] Inactivity timeout
> > (--ping-restart), restarting
> > 2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting
> > 2022-01-27 15:41:29 WARNING: No server certificate verification method
> > has been enabled.  See http://openvpn.net/howto.html#mitm for more
> > info.
> > 2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address:
> > [AF_INET]1.2.3.4:1194
> > 2022-01-27 15:41:29 UDP link local: (not bound)
> > 2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194
> > 2022-01-27 15:41:29 [server] Peer Connection Initiated with
> > [AF_INET]1.2.3.4:1194
> > 2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0
> > 2022-01-27 15:41:30 Initialization Sequence Completed
> >
> > Voici la config du client:
> > client
> > dev tun
> > proto udp
> > remote 1.2.3.4 1194
> > resolv-retry infinite
> > nobind
> > user nobody
> > group nogroup
> > persist-key
> > persist-tun
> > ca /etc/openvpn/client/ca.crt
> > cert /etc/openvpn/client/client_vie.crt
> > key /etc/openvpn/client/client_vie.key
> > comp-lzo
> > verb 1
> > ping 30
>
>
> Je remplacerai ping 30 par keep-alive 10 60 et rajouterai tun-mtu 1500,
> sur le serveur également. Pas de mssfix ?
>
>
> >
> >
> > Voici la config du serveur:
> > port 1194
> > proto udp
> > dev tun
> > topology subnet
> > ca /etc/openvpn/easy-rsa/keys/ca.crt
> > cert /etc/openvpn/easy-rsa/keys/server.crt
> > key /etc/openvpn/easy-rsa/keys/server.key
> > dh /etc/openvpn/easy-rsa/keys/dh1024.pem
> > server 10.19.0.0 255.255.254.0
> > ifconfig-pool-persist /etc/openvpn/server1/ipp.txt
> > client-to-client
> > keepalive 10 120
> > comp-lzo
> > user nobody
> > group nogroup
> > persist-key
> > persist-tun
> > status /etc/openvpn/server1/openvpn-status.log
> > verb 1
> >
> > Je lance en parallèle deux séries de ping:
> > ping -c120 -q 1.2.3.4
> > ping -c120 -q 10.19.0.1
> >
> > Aucune perte, sur la première. des pertes significatives sur la deuxième.
> >
> > Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de
> > l'activité OpenVPN qui interdit en retour le inactivity Timeout.
> >
> > Qu'en pensez-vous ?
> > Dans quelle direction chercher ?
> >
> > Slts
>

Re: Coupures OpenVPN (Inactivity timeout)

2022-01-27 Par sujet NoSpam


Bonjour

Le 27/01/2022 à 16:41, Olivier a écrit :

Bonjour,

J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un
hébergeur Internet.
À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine
Debian de toutes les générations (Jessie, à Bullseye).
Depuis quelques mois, j'observe des déconnexions temporaires.

Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer.

Dans les logs du client, j'ai la séquence ci-après répétée toutes les
230 sec.2022-01-27 15:41:24 [server] Inactivity timeout
(--ping-restart), restarting
2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting
2022-01-27 15:41:29 WARNING: No server certificate verification method
has been enabled.  See http://openvpn.net/howto.html#mitm for more
info.
2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address:
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 UDP link local: (not bound)
2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 [server] Peer Connection Initiated with
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0
2022-01-27 15:41:30 Initialization Sequence Completed

Voici la config du client:
client
dev tun
proto udp
remote 1.2.3.4 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client_vie.crt
key /etc/openvpn/client/client_vie.key
comp-lzo
verb 1
ping 30



Je remplacerai ping 30 par keep-alive 10 60 et rajouterai tun-mtu 1500, 
sur le serveur également. Pas de mssfix ?






Voici la config du serveur:
port 1194
proto udp
dev tun
topology subnet
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.19.0.0 255.255.254.0
ifconfig-pool-persist /etc/openvpn/server1/ipp.txt
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /etc/openvpn/server1/openvpn-status.log
verb 1

Je lance en parallèle deux séries de ping:
ping -c120 -q 1.2.3.4
ping -c120 -q 10.19.0.1

Aucune perte, sur la première. des pertes significatives sur la deuxième.

Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de
l'activité OpenVPN qui interdit en retour le inactivity Timeout.

Qu'en pensez-vous ?
Dans quelle direction chercher ?

Slts

Coupures OpenVPN (Inactivity timeout)

2022-01-27 Par sujet Olivier

Bonjour,

J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un
hébergeur Internet.
À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine
Debian de toutes les générations (Jessie, à Bullseye).
Depuis quelques mois, j'observe des déconnexions temporaires.

Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer.

Dans les logs du client, j'ai la séquence ci-après répétée toutes les
230 sec.2022-01-27 15:41:24 [server] Inactivity timeout
(--ping-restart), restarting
2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting
2022-01-27 15:41:29 WARNING: No server certificate verification method
has been enabled.  See http://openvpn.net/howto.html#mitm for more
info.
2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address:
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 UDP link local: (not bound)
2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194
2022-01-27 15:41:29 [server] Peer Connection Initiated with
[AF_INET]1.2.3.4:1194
2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0
2022-01-27 15:41:30 Initialization Sequence Completed

Voici la config du client:
client
dev tun
proto udp
remote 1.2.3.4 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client_vie.crt
key /etc/openvpn/client/client_vie.key
comp-lzo
verb 1
ping 30


Voici la config du serveur:
port 1194
proto udp
dev tun
topology subnet
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.19.0.0 255.255.254.0
ifconfig-pool-persist /etc/openvpn/server1/ipp.txt
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /etc/openvpn/server1/openvpn-status.log
verb 1

Je lance en parallèle deux séries de ping:
ping -c120 -q 1.2.3.4
ping -c120 -q 10.19.0.1

Aucune perte, sur la première. des pertes significatives sur la deuxième.

Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de
l'activité OpenVPN qui interdit en retour le inactivity Timeout.

Qu'en pensez-vous ?
Dans quelle direction chercher ?

Slts

Re: [Résolu]: openvpn --route-up et --route-pre-down

2021-01-04 Par sujet Daniel Caillibaud

Le 02/01/21 à 01:07, Jean-Marc  a écrit :
> Bon, si j'ajoute un shebang #!/bin/bash, openvpn ne me donne plus de
> message d'erreur mais mon script ne fait rien.

C'est bizarre, /bin/bash existe et est exécutable ?

-- 
Daniel

Je m’intéresse à l’avenir car c’est là que j’ai décidé de passer le restant de 
mes jours.
Woody Allen

[Résolu]: openvpn --route-up et --route-pre-down

2021-01-01 Par sujet Jean-Marc

Le 2/01/21 à 00:07, no way a écrit :
> Salut,
> 
> Il te manque pas le shebang (#!/bin/bash) dans ton script bash ??

BINGO !

Bon, si j'ajoute un shebang #!/bin/bash, openvpn ne me donne plus de
message d'erreur mais mon script ne fait rien.

Si j'utilise #!/bin/sh, alors ça fonctionne.

Bon, c'est résolu.

Merci.

-- 
Jean-Marc



OpenPGP_signature
Description: OpenPGP digital signature

Re: openvpn --route-up et --route-pre-down

2021-01-01 Par sujet no way

Salut,

Il te manque pas le shebang (#!/bin/bash) dans ton script bash ??

On Sat, Jan 2, 2021 at 12:02 AM Jean-Marc  wrote:

> Le 1/01/21 à 18:28, NoSpam a écrit :
> > Perso j'utilise
> >
> > script-security 2
> > up "/etc/openvpn/update-routeAndmask"
> > down "/etc/openvpn/update-routeAndmask"
>
> À peu de chose près, ce que j'ai fait aussi :
> script-security 2
>
> up /etc/openvpn/client/neutrinet/neutrinet-test
>
>
> $ cat /etc/openvpn/client/neutrinet/neutrinet-test
>
> /bin/echo test logging > /tmp/openvpn.log
>
>
> $ cat /tmp/openvpn.log
>
> test logging
>
>
> Ce simple script n'est jamais exécuté quand le client openvpn démarre.
>
> Les dernières lignes du log sont celles-ci :
> [...]
> /etc/openvpn/client/neutrinet/neutrinet-test tun0 1500 1570
> 80.67.181.137 255.255.255.128 init
>
> WARNING: Failed running command (--up/--down): could not execute
> external program
>
> Exiting due to fatal error
>
>
>
>
> --
> Jean-Marc
>
>

Re: openvpn --route-up et --route-pre-down

2021-01-01 Par sujet Jean-Marc

Le 1/01/21 à 18:28, NoSpam a écrit :
> Perso j'utilise
> 
> script-security 2
> up "/etc/openvpn/update-routeAndmask"
> down "/etc/openvpn/update-routeAndmask"

À peu de chose près, ce que j'ai fait aussi :
script-security 2

up /etc/openvpn/client/neutrinet/neutrinet-test


$ cat /etc/openvpn/client/neutrinet/neutrinet-test

/bin/echo test logging > /tmp/openvpn.log


$ cat /tmp/openvpn.log

test logging


Ce simple script n'est jamais exécuté quand le client openvpn démarre.

Les dernières lignes du log sont celles-ci :
[...]
/etc/openvpn/client/neutrinet/neutrinet-test tun0 1500 1570
80.67.181.137 255.255.255.128 init

WARNING: Failed running command (--up/--down): could not execute
external program

Exiting due to fatal error




-- 
Jean-Marc



OpenPGP_signature
Description: OpenPGP digital signature

Re: openvpn --route-up et --route-pre-down

2021-01-01 Par sujet NoSpam


Bonjour et bonne année à tous

Le 01/01/2021 à 16:09, Jean-Marc a écrit :

salut la liste,

quelqu'un connaît un peu openvpn ?

J'ai un serveur Debian stable avec un client openvpn.

J'essaie sans succès d'appeler 2 scripts pendant l'init de mon vpn.

J'utilise les paramètres route-up et route-pre-down pour ce faire, j'ai,
comme indiqué dans le man, changé la valeur de script-security à 2 pour
permettre l'appel de scripts persos mais ça ne fonctionne pas.

Je me retrouve avec l'erreur suivante :

WARNING: Failed running command (--route-up): could not execute external
program

Si j'exécute les scripts à la main, pas de soucis.

J'ai cherché sur le net mais je n'ai rien trouvé de bien probant.

Toute suggestion bienvenue.

Debian 10.7
Linux 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) armv7l GNU/Linux

openvpn 2.4.7-1


Perso j'utilise

script-security 2
up "/etc/openvpn/update-routeAndmask"
down "/etc/openvpn/update-routeAndmask"

--
Daniel

openvpn --route-up et --route-pre-down

2021-01-01 Par sujet Jean-Marc

salut la liste,

quelqu'un connaît un peu openvpn ?

J'ai un serveur Debian stable avec un client openvpn.

J'essaie sans succès d'appeler 2 scripts pendant l'init de mon vpn.

J'utilise les paramètres route-up et route-pre-down pour ce faire, j'ai,
comme indiqué dans le man, changé la valeur de script-security à 2 pour
permettre l'appel de scripts persos mais ça ne fonctionne pas.

Je me retrouve avec l'erreur suivante :

WARNING: Failed running command (--route-up): could not execute external
program

Si j'exécute les scripts à la main, pas de soucis.

J'ai cherché sur le net mais je n'ai rien trouvé de bien probant.

Toute suggestion bienvenue.

Debian 10.7
Linux 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) armv7l GNU/Linux

openvpn 2.4.7-1


-- 
Jean-Marc

Re: Résolution OpenVPN

2020-03-23 Par sujet Sil


Le 19/03/2020 à 16:15, Guillaume Clercin a écrit :


Il est possible, pour le client, d'utiliser un serveur dns qui se
trouve de coté du serveur.
Dans la configuration du service openvpn, tu peut ajouter:
push "dhcp-option DNS "

et éventuellement
push "dhcp-option DOMAIN "

À noter que, une fois le client est connecté au vpn, toutes les
requêtes passeront par le vpn.


Bonjour,

J'ai ajouté l'option "dhcp-option DNS" et la résolution fonctionne. Il 
faut juste attendre un peu, car ça prend un peu de temps.


Je ne pensais pas que l'on pouvait atteindre autre chose que l'IP du 
serveur VPN.


Merci

Sil

Re: Résolution OpenVPN

2020-03-19 Par sujet Guillaume Clercin

Bonjour,

On Thu, 19 Mar 2020 09:47:19 +0100
Sil  wrote:

> Bonjour la liste,
> 
> Je voulais rebondir sur le fil OpenVPN.
> En ces temps de télétravail, j'ai des postes clients (majorité de w$)
> qui accèdent à un serveur samba via un tunnel OpenVPN en tun. Le
> serveur VPN et Samba sont sur la même machine.
> Par contre le DNS est géré par le routeur qui diffuse l'IP du serveur.
> Hors, une fois connecté au VPN, plus de DNS du routeur. Donc,
> obligation d'utiliser l'IP et non le nom du serveur.
> Ma question est, est-il possible du coté serveur VPN de spécifier une
> résolution de nom unique pour accéder au serveur ? Par exemple :
> serveurtruc 192.168.10.20
Il est possible, pour le client, d'utiliser un serveur dns qui se
trouve de coté du serveur.
Dans la configuration du service openvpn, tu peut ajouter:
push "dhcp-option DNS "

et éventuellement
push "dhcp-option DOMAIN "

À noter que, une fois le client est connecté au vpn, toutes les
requêtes passeront par le vpn.

> 
> Par avance merci
> Sil
> 

Guillaume Clercin


pgp5eNMMrX2u1.pgp
Description: Signature digitale OpenPGP

Résolution OpenVPN

2020-03-19 Par sujet Sil

Bonjour la liste,

Je voulais rebondir sur le fil OpenVPN.
En ces temps de télétravail, j'ai des postes clients (majorité de w$)
qui accèdent à un serveur samba via un tunnel OpenVPN en tun. Le
serveur VPN et Samba sont sur la même machine.
Par contre le DNS est géré par le routeur qui diffuse l'IP du serveur.
Hors, une fois connecté au VPN, plus de DNS du routeur. Donc,
obligation d'utiliser l'IP et non le nom du serveur.
Ma question est, est-il possible du coté serveur VPN de spécifier une
résolution de nom unique pour accéder au serveur ? Par exemple :
serveurtruc 192.168.10.20

Par avance merci
Sil

Re: OpenVPN

2020-03-19 Par sujet Erwan David

Le 18/03/2020 à 21:12, Damien TOURDE a écrit :
> Bonjour,
> 
> En effet, tap c'est de la propagation de L2, et tun, de L3.
> 
> C'est pas le même usage, mais il faut bien avoir en tête que tout le
> broadcast dans le domaine (de broadcast...), va transiter avec tap.
> De même que tout le reste de l'ARP.
> 
> Sur un gros réseau, ça risque de faire beaucoup d'overhead.
> Pensez aussi à votre Chromecast et votre imprimante qui floodent
> constamment (en multicast et broadcast).
> 
> Sur ces réseaux d'overlay, on est généralement en UDP, mais le TCP est
> aussi possible pour OpenVPN avec l'overhead qui va avec aussi.
> 
> A mon sens, le tun répond a tous les usages courants.
> Et pour le tap, il faut en avoir besoin, mais aussi en comprendre les
> contraintes.
> 
> Pour resumer, le tun c'est du routage classique, le tap c'est du "câble
> VPN".
> 
> 
> PS: je pense également que le multicast ne passe pas au travers d'une
> interface tun, je veux bien un avis sur la question.

Dans mon souvenir, ça passe, mais le multicats routé. Et le routage
multicast c'est assez complexe. Donc ça passe si on fait du pim ou autre
protocole de routage multicast sur l'interface tun, et ça c'est pas
standard du tout

Re: OpenVPN

2020-03-18 Par sujet Damien TOURDE

Bonjour,

En effet, tap c'est de la propagation de L2, et tun, de L3.

C'est pas le même usage, mais il faut bien avoir en tête que tout le broadcast 
dans le domaine (de broadcast...), va transiter avec tap.
De même que tout le reste de l'ARP.

Sur un gros réseau, ça risque de faire beaucoup d'overhead.
Pensez aussi à votre Chromecast et votre imprimante qui floodent constamment 
(en multicast et broadcast).

Sur ces réseaux d'overlay, on est généralement en UDP, mais le TCP est aussi 
possible pour OpenVPN avec l'overhead qui va avec aussi.

A mon sens, le tun répond a tous les usages courants.
Et pour le tap, il faut en avoir besoin, mais aussi en comprendre les 
contraintes.

Pour resumer, le tun c'est du routage classique, le tap c'est du "câble VPN".


PS: je pense également que le multicast ne passe pas au travers d'une interface 
tun, je veux bien un avis sur la question.

Cordialement,
Damien TOURDE




Le 17 mars 2020 12:58:48 GMT+01:00, "BERTRAND Joël"  
a écrit :
>NoSpam a écrit :
>> 
>> Le 17/03/2020 à 11:32, BERTRAND Joël a écrit :
>>> David BERCOT a écrit :
>>>> Bonsoir,
>>> Bonjour,
>>>
>>>> En cette période un peu... difficile, je vous propose de revenir
>aux
>>>> fondamentaux, à savoir Debian ;-)
>>>>
>>>> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
>>>> Après quelques recherches, j'ai trouvé notamment cette
>documentation :
>>>> https://wiki.debian.org/fr/OpenVPN
>>>>
>>>> Les premières étapes (installation du package et génération de la
>clé
>>>> statique) sont OK mais je ne vois pas bien comment remplir le
>tun0.conf
>>>> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
>>>> En effet, sauf erreur, la première IP est celle de mon serveur et
>la
>>>> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise
>pas
>>>> du tout les adresses IP et leur utilisation.
>>>>
>>>> Auriez-vous une piste ?
>>> Utiliser une interface tap ?
>>>
>>> La question est sérieuse, je n'ai jamais compris l'intérêt
>d'utiliser
>>> l'interface tun. tap se comporte comme une réelle interface réseau
>avec
>>> tous les avantages d'ethernet (contrairement à tun qui ne cause
>qu'IP).
>>> On peut donc faire de la tolérance de panne, de l'agrégation et tout
>ce
>>> qui est supporté par ethernet. Mais il faut router soi-même par
>derrière.
>> 
>> tap a l'énorme désavantage de faire passer out le trafic y compris
>arp &
>> co De plus,  si les réseaux connectés gèrent des postes sous Windows,
>la
>> propagation des logiciels malveillants est aisée.
>> 
>> J'ai abandonné tap pour tun depuis quelques mois et les routeurs,
>> commutateurs et autres outils de surveillance me disent merci ;)
>
>Je ne veux pas être bégueule, mais concernant les protocoles à la noix
>Windows, ça se filtre (d'autant plus qu'il y en a un bon paquet qui
>causent IP).

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: OpenVPN

2020-03-17 Par sujet BERTRAND Joël

NoSpam a écrit :
> 
> Le 17/03/2020 à 11:32, BERTRAND Joël a écrit :
>> David BERCOT a écrit :
>>> Bonsoir,
>> Bonjour,
>>
>>> En cette période un peu... difficile, je vous propose de revenir aux
>>> fondamentaux, à savoir Debian ;-)
>>>
>>> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
>>> Après quelques recherches, j'ai trouvé notamment cette documentation :
>>> https://wiki.debian.org/fr/OpenVPN
>>>
>>> Les premières étapes (installation du package et génération de la clé
>>> statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
>>> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
>>> En effet, sauf erreur, la première IP est celle de mon serveur et la
>>> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
>>> du tout les adresses IP et leur utilisation.
>>>
>>> Auriez-vous une piste ?
>> Utiliser une interface tap ?
>>
>> La question est sérieuse, je n'ai jamais compris l'intérêt d'utiliser
>> l'interface tun. tap se comporte comme une réelle interface réseau avec
>> tous les avantages d'ethernet (contrairement à tun qui ne cause qu'IP).
>> On peut donc faire de la tolérance de panne, de l'agrégation et tout ce
>> qui est supporté par ethernet. Mais il faut router soi-même par derrière.
> 
> tap a l'énorme désavantage de faire passer out le trafic y compris arp &
> co De plus,  si les réseaux connectés gèrent des postes sous Windows, la
> propagation des logiciels malveillants est aisée.
> 
> J'ai abandonné tap pour tun depuis quelques mois et les routeurs,
> commutateurs et autres outils de surveillance me disent merci ;)

Je ne veux pas être bégueule, mais concernant les protocoles à la noix
Windows, ça se filtre (d'autant plus qu'il y en a un bon paquet qui
causent IP).

Re: OpenVPN

2020-03-17 Par sujet NoSpam




Le 17/03/2020 à 11:32, BERTRAND Joël a écrit :

David BERCOT a écrit :

Bonsoir,

Bonjour,


En cette période un peu... difficile, je vous propose de revenir aux
fondamentaux, à savoir Debian ;-)

Bref, je voudrais installer OpenVPN sur mon serveur OVH.
Après quelques recherches, j'ai trouvé notamment cette documentation :
https://wiki.debian.org/fr/OpenVPN

Les premières étapes (installation du package et génération de la clé
statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
En effet, sauf erreur, la première IP est celle de mon serveur et la
seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
du tout les adresses IP et leur utilisation.

Auriez-vous une piste ?

Utiliser une interface tap ?

La question est sérieuse, je n'ai jamais compris l'intérêt d'utiliser
l'interface tun. tap se comporte comme une réelle interface réseau avec
tous les avantages d'ethernet (contrairement à tun qui ne cause qu'IP).
On peut donc faire de la tolérance de panne, de l'agrégation et tout ce
qui est supporté par ethernet. Mais il faut router soi-même par derrière.


tap a l'énorme désavantage de faire passer out le trafic y compris arp & 
co De plus,  si les réseaux connectés gèrent des postes sous Windows, la 
propagation des logiciels malveillants est aisée.


J'ai abandonné tap pour tun depuis quelques mois et les routeurs, 
commutateurs et autres outils de surveillance me disent merci ;)


--

Daniel

Re: OpenVPN

2020-03-17 Par sujet BERTRAND Joël

David BERCOT a écrit :
> Bonsoir,

Bonjour,

> En cette période un peu... difficile, je vous propose de revenir aux
> fondamentaux, à savoir Debian ;-)
> 
> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
> Après quelques recherches, j'ai trouvé notamment cette documentation :
> https://wiki.debian.org/fr/OpenVPN
> 
> Les premières étapes (installation du package et génération de la clé
> statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
> En effet, sauf erreur, la première IP est celle de mon serveur et la
> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
> du tout les adresses IP et leur utilisation.
> 
> Auriez-vous une piste ?

Utiliser une interface tap ?

La question est sérieuse, je n'ai jamais compris l'intérêt d'utiliser
l'interface tun. tap se comporte comme une réelle interface réseau avec
tous les avantages d'ethernet (contrairement à tun qui ne cause qu'IP).
On peut donc faire de la tolérance de panne, de l'agrégation et tout ce
qui est supporté par ethernet. Mais il faut router soi-même par derrière.

Bien cordialement,

JKB

Re: OpenVPN

2020-03-16 Par sujet Belaïd

Bonjour,

Ta configuration pour tun0 est correct du moment que ces adresses IP
n'entrent pas en conflit avec les adresses IP du côté serveur (si y'en a).
Tu peux aussi remplacer la ligne ifconfig en question par une ligne du
genre: server 10.8.9.0 255.255.255.0 si tu veux que le serveur VPN puisse
donner/gérer les adresses IP automatiquement aux clients

Le lun. 16 mars 2020 12:04, David BERCOT  a écrit :

> Bonsoir,
>
> En cette période un peu... difficile, je vous propose de revenir aux
> fondamentaux, à savoir Debian ;-)
>
> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
> Après quelques recherches, j'ai trouvé notamment cette documentation :
> https://wiki.debian.org/fr/OpenVPN
>
> Les premières étapes (installation du package et génération de la clé
> statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
> En effet, sauf erreur, la première IP est celle de mon serveur et la
> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
> du tout les adresses IP et leur utilisation.
>
> Auriez-vous une piste ?
>
> Dans l'intervalle, j'ai installé OpenVPN-AS qui marche très bien mais je
> préfère les solutions "propres", purement Debian ;-)
>
> Merci d'avance.
>
> David.
>
>

OpenVPN

2020-03-16 Par sujet David BERCOT

Bonsoir,

En cette période un peu... difficile, je vous propose de revenir aux
fondamentaux, à savoir Debian ;-)

Bref, je voudrais installer OpenVPN sur mon serveur OVH.
Après quelques recherches, j'ai trouvé notamment cette documentation :
https://wiki.debian.org/fr/OpenVPN

Les premières étapes (installation du package et génération de la clé
statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
En effet, sauf erreur, la première IP est celle de mon serveur et la
seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
du tout les adresses IP et leur utilisation.

Auriez-vous une piste ?

Dans l'intervalle, j'ai installé OpenVPN-AS qui marche très bien mais je
préfère les solutions "propres", purement Debian ;-)

Merci d'avance.

David.

Re: openvpn privatvpn

2019-07-12 Par sujet Daniel Huhardeaux


Le 12/07/2019 à 06:02, Daniel Caillibaud a écrit :

Le 11/07/19 à 18h50, MERLIN Philippe  a
écrit :

Une analyse par Wireshark indique seulement que les DNS ne
fonctionnent pas.


Je ne connais pas l'origine du pb, mais tu peux installer un resolver
local, c'est très léger et ça rend pas mal de services (ça évite les dns
parfois menteurs des FAI, mais surtout ça marche toujours alors que
suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu
va gagner un poil en perfs).

apt install unbound

et dans /etc/resolv.conf mettre
nameserver 127.0.0.1

(ou bien l'indiquer dans le network manager, ou ton système de gestion de
la résolution locale)


Attention si c'est systemd-resolved qui gère le DNS la valeur 127.0.0.1 
est à mettre dans /etc/systemd/resolved cle [Resolve] => DNS


--
Daniel

Re: openvpn privatvpn

2019-07-11 Par sujet Daniel Caillibaud

Le 11/07/19 à 18h50, MERLIN Philippe  a
écrit :
> Une analyse par Wireshark indique seulement que les DNS ne
> fonctionnent pas.

Je ne connais pas l'origine du pb, mais tu peux installer un resolver
local, c'est très léger et ça rend pas mal de services (ça évite les dns
parfois menteurs des FAI, mais surtout ça marche toujours alors que
suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu
va gagner un poil en perfs).

apt install unbound

et dans /etc/resolv.conf mettre
nameserver 127.0.0.1

(ou bien l'indiquer dans le network manager, ou ton système de gestion de
la résolution locale)



-- 
Daniel

La mode est ce que l’on porte. 
Ce qui est démodé, c’est ce que portent les autres.
Oscar Wilde

Re: openvpn privatvpn

2019-07-11 Par sujet MERLIN Philippe

Le jeudi 11 juillet 2019, 19:20:06 CEST Daniel Huhardeaux a écrit :
> Le 11/07/2019 à 18:50, MERLIN Philippe a écrit :
> > Bonsoir,
> 
> Bonsoir
> 
> > Je suis confronté à un problème surprenant et j'ai besoin d'aides pour
> > essayer de  le résoudre.
> > Sur mon ordinateur système Debian AMD 64 je lance un script en étant root
> > pour activer un VPN privatVPN cette procédure fonctionne parfaitement à
> > Paris ou je suis connecté à une Freebox Mini 4K mais par contre ne
> > fonctionne pas aux environs de Royan connecté à une Freebox V5. Aucun
> > message d'erreur au lancement de la procédure mais je me retrouve sans
> > réseau. Une analyse par Wireshark indique seulement que les DNS ne
> > fonctionnent pas.
> > Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
> > A l'avance merci pour votre aide.
> > Philippe Merlin
> 
> Mettre le mode verbose 8 par ex. et regarder les logs. Loguer également
> le status.
Merci pour ta réponse, malheureusement je n'arrive pas à les interpréter à vue 
de nez je ne vois pas d'erreur, n'étant pas un spécialiste réseau . Si 
quelqu'un peut se pencher sur les petits fichiers qui ont été créés à cette 
occasion, je ne peux les mettre en pj car elles ne seront pas acceptées par la 
liste. Je les enverrai personnellement.
Philippe Merlin

Re: openvpn privatvpn

2019-07-11 Par sujet Daniel Huhardeaux


Le 11/07/2019 à 18:50, MERLIN Philippe a écrit :

Bonsoir,


Bonsoir


Je suis confronté à un problème surprenant et j'ai besoin d'aides pour essayer
de  le résoudre.
Sur mon ordinateur système Debian AMD 64 je lance un script en étant root pour
activer un VPN privatVPN cette procédure fonctionne parfaitement à Paris ou je
suis connecté à une Freebox Mini 4K mais par contre ne fonctionne pas aux
environs de Royan connecté à une Freebox V5. Aucun message d'erreur au
lancement de la procédure mais je me retrouve sans réseau. Une analyse par
Wireshark indique seulement que les DNS ne fonctionnent pas.
Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
A l'avance merci pour votre aide.
Philippe Merlin



Mettre le mode verbose 8 par ex. et regarder les logs. Loguer également 
le status.


--
Daniel

openvpn privatvpn

2019-07-11 Par sujet MERLIN Philippe

Bonsoir,
Je suis confronté à un problème surprenant et j'ai besoin d'aides pour essayer 
de  le résoudre. 
Sur mon ordinateur système Debian AMD 64 je lance un script en étant root pour 
activer un VPN privatVPN cette procédure fonctionne parfaitement à Paris ou je 
suis connecté à une Freebox Mini 4K mais par contre ne fonctionne pas aux 
environs de Royan connecté à une Freebox V5. Aucun message d'erreur au 
lancement de la procédure mais je me retrouve sans réseau. Une analyse par 
Wireshark indique seulement que les DNS ne fonctionnent pas.
Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
A l'avance merci pour votre aide.
Philippe Merlin

Re: OpenVPN. Certificat ca.crt expiré. Comment éviter une redistribution de ca.crt

2019-01-28 Par sujet Daniel Huhardeaux


Le 28/01/2019 à 12:28, Olivier a écrit :

Bonjour,


Bonjour

[...]


2. Avez-vous mis en place une procédure particulière pour éviter ce 
genre de contre-temps ?


Reverse ssh
--
Daniel

OpenVPN. Certificat ca.crt expiré. Comment éviter une redistribution de ca.crt

2019-01-28 Par sujet Olivier

Bonjour,

J'ai laissé passer la date d'expiration du certificat ca.crt sur mon
serveur OpenVPN sur lequel, ce matin, je vois:

openssl x509 -noout -text -in ca.crt
Certificate:
...
Signature Algorithm: sha1WithRSAEncryption
Issuer: ...
Not Before: Jan 28 18:27:35 2009 GMT
Not After : Jan 26 18:27:35 2019 GMT

Avec le temps, j'ai distribué ce fichier avec chaque client du VPN.
Ce matin, je n'ai plus de connexion VPN avec tous mes clients du VPN.

Pour quelques uns d'entre eux, je peux encore me connecter autrement que
par le VPN mais pour les autres, je dois déranger un collaborateur sur
place et corriger au cas par cas.

1. Voyez-vous une astuce pour éviter une re-distribution manuelle, au cas
par cas, du nouveau fichier ca.crt ?

2. Avez-vous mis en place une procédure particulière pour éviter ce genre
de contre-temps ?

Slts

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Daniel Huhardeaux


Le 24/01/2019 à 11:32, Olivier a écrit :



Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux <mailto:no-s...@tootai.net>> a écrit :




Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
chez tes clients (et chez toi) sur un autre port !

Je suis d'accord.


Pour ma part, je réitère: un serveur VPN central sur lequel vont se
connecter les clients et toi, du réseau bureau ou déplacement.

                  serveur VPN
                  /     | ...\
              clt1    clt2    Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)


Je suis d'accord sauf peut-être sur la persistance des liens car ne 
l'oublions pas, j'ai des plages d'adresses identiques sur des sites 
différents et ça va rester.


Quelle techno de VPN te sembles la plus adaptée pour ça ?


tun

On garde OpenVPN (pas de logiciels supplémentaire à installer): juste 
une re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?

Ça me semble une très bonne idée mais je préfère demander.


Oui




Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
dire que tu pourras te connecter (ssh avec mot de passe) chez tes
clients à partir de n'importe quel matériel, pas seulement de ceux qui
te sont connus.


 >
 >
 >
 > Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg
mailto:pas...@plouf.fr.eu.org>
 > <mailto:pas...@plouf.fr.eu.org <mailto:pas...@plouf.fr.eu.org>>>
a écrit :
 >
 >     Le 23/01/2019 à 15:58, Olivier a écrit :
 >      >
 >      > [1]
https://serverfault.com/questions/736274/openvpn-client-to-client
 >
 >     Ce lien confirme ce que j'écrivais ci-dessous :
 >
 >      > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
 >     mailto:pas...@plouf.fr.eu.org>
<mailto:pas...@plouf.fr.eu.org <mailto:pas...@plouf.fr.eu.org>>> a
 >      > écrit :
 >      >
 >      >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
 >      >>>
 >      >>> 1. Oui tu as bien compris, client-to-client ne transite
pas le
 >     paquet par
 >      >>> le serveur. Du coup pas de filtrage possible si c'est option
 >     est activée.
 >      >>
 >      >> Si j'ai bien compris, plus précisément les paquets envoyés à
 >     l'intérieur
 >      >> du tunnel entre deux clients ne transitent pas par
l'interface
 >     tun/tap
 >      >> ni la pile réseau de la machine qui fait tourner le
serveur openvpn,
 >      >> mais les paquets transportant le tunnel passent quand
même par le
 >      >> serveur openvpn.
 >

Re: Conseils sur le routage de client à client avec OpenVPN [RESOLU]

2019-01-24 Par sujet Olivier

Grâce aux différents conseils ici reçus, j'ai pu rapidement mettre en place
un prototype de VPN dédié à la télé-gestion de réseaux locaux distants en
complément de mon VPN dédié à la télé-gestion de machines distantes.

- Mes deux VPN utilisent OpenVPN.
- On peut faire tourner parallèlement plusieurs instances d'OpenVPN mais
chacune doit avoir son propre procole/port d'écoute.
- On peut mettre en communs des certificats et clés.
- La topologie subnet est recommandée (celle par défaut est net30)
- L'option client-to-client facilite les communications "directes"
inter-clients
- Chaque instance d'OpenVPN produit son fichier openvpn-status.lo qui
contient une photo de la table de routage interne à OpenVPN à savoir la
liste des clients OpenVPN et la liste des réseaux locaux déclarés par ces
clients
- Au démarrage, un client OpenVPN modifie la table de routage du client: je
n'ai pas eu besoin d'ajouter des règles pour le NAT.

Merci infiniment à tous pour votre aide

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Olivier

Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux  a
écrit :

>
>
> Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
> chez tes clients (et chez toi) sur un autre port !
>
Je suis d'accord.


> Pour ma part, je réitère: un serveur VPN central sur lequel vont se
> connecter les clients et toi, du réseau bureau ou déplacement.
>
>  serveur VPN
>  / | ...\
>  clt1clt2Cltx
>
> Le lien est permanent pour les clients sauf pour toi (si tu le désire)
>

Je suis d'accord sauf peut-être sur la persistance des liens car ne
l'oublions pas, j'ai des plages d'adresses identiques sur des sites
différents et ça va rester.

Quelle techno de VPN te sembles la plus adaptée pour ça ?
On garde OpenVPN (pas de logiciels supplémentaire à installer): juste une
re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?
Ça me semble une très bonne idée mais je préfère demander.


>
> Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
> dire que tu pourras te connecter (ssh avec mot de passe) chez tes
> clients à partir de n'importe quel matériel, pas seulement de ceux qui
> te sont connus.
>
>
> >
> >
> >
> > Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg  > <mailto:pas...@plouf.fr.eu.org>> a écrit :
> >
> > Le 23/01/2019 à 15:58, Olivier a écrit :
> >  >
> >  > [1]
> https://serverfault.com/questions/736274/openvpn-client-to-client
> >
> > Ce lien confirme ce que j'écrivais ci-dessous :
> >
> >  > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
> > mailto:pas...@plouf.fr.eu.org>> a
> >  > écrit :
> >  >
> >  >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >  >>>
> >  >>> 1. Oui tu as bien compris, client-to-client ne transite pas le
> > paquet par
> >  >>> le serveur. Du coup pas de filtrage possible si c'est option
> > est activée.
> >      >>
> >  >> Si j'ai bien compris, plus précisément les paquets envoyés à
> > l'intérieur
> >  >> du tunnel entre deux clients ne transitent pas par l'interface
> > tun/tap
> >  >> ni la pile réseau de la machine qui fait tourner le serveur
> openvpn,
> >  >> mais les paquets transportant le tunnel passent quand même par le
> >  >> serveur openvpn.
> >
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Daniel Huhardeaux


Le 24/01/2019 à 10:54, Olivier a écrit :

Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon 
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer 
des flux entre deux clients du VPN

sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux 
pas risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée 
générale avec des précautions que j'ai du mal à respecter (adresses 
uniques, ...).


En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN 
comme un "tunnel entre mon PC et un LAN distant" et sans le 
re-configurer, ça m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) 
pour faire ce que je recherche et utilisable en parallèle à OpenVPN, ça 
m'intéresse aussi.


Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre 
mon PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel 
le temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et 
connecté à réseau local dont je ne pourrai pas modifier la configuration 
du routeur: je devrai donc passer par une machine tierce sur Internet 
qui aura les ports ouverts nécessaires.


Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le 
LAN distant) sont sous Debian avec toutefois des versions variées 
(jessie, stretch, ...).


Conseils, remarques et suggestions bienvenues !


Rien ne t'empêche de mettre une seconde configuration VPN en parallèle 
chez tes clients (et chez toi) sur un autre port !


Pour ma part, je réitère: un serveur VPN central sur lequel vont se 
connecter les clients et toi, du réseau bureau ou déplacement.


serveur VPN
/ | ...\
clt1clt2Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)

Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut 
dire que tu pourras te connecter (ssh avec mot de passe) chez tes 
clients à partir de n'importe quel matériel, pas seulement de ceux qui 
te sont connus.







Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg <mailto:pas...@plouf.fr.eu.org>> a écrit :


Le 23/01/2019 à 15:58, Olivier a écrit :
 >
 > [1] https://serverfault.com/questions/736274/openvpn-client-to-client

Ce lien confirme ce que j'écrivais ci-dessous :

 > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
mailto:pas...@plouf.fr.eu.org>> a
 > écrit :
 >
 >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
 >>>
 >>> 1. Oui tu as bien compris, client-to-client ne transite pas le
paquet par
 >>> le serveur. Du coup pas de filtrage possible si c'est option
est activée.
 >>
 >> Si j'ai bien compris, plus précisément les paquets envoyés à
l'intérieur
 >> du tunnel entre deux clients ne transitent pas par l'interface
tun/tap
 >> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
 >> mais les paquets transportant le tunnel passent quand même par le
 >> serveur openvpn.

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Olivier

Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer des
flux entre deux clients du VPN
sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux pas
risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée
générale avec des précautions que j'ai du mal à respecter (adresses
uniques, ...).

En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN comme
un "tunnel entre mon PC et un LAN distant" et sans le re-configurer, ça
m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) pour
faire ce que je recherche et utilisable en parallèle à OpenVPN, ça
m'intéresse aussi.

Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre mon
PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel le
temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et connecté
à réseau local dont je ne pourrai pas modifier la configuration du routeur:
je devrai donc passer par une machine tierce sur Internet qui aura les
ports ouverts nécessaires.

Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le
LAN distant) sont sous Debian avec toutefois des versions variées (jessie,
stretch, ...).

Conseils, remarques et suggestions bienvenues !



Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg  a
écrit :

> Le 23/01/2019 à 15:58, Olivier a écrit :
> >
> > [1] https://serverfault.com/questions/736274/openvpn-client-to-client
>
> Ce lien confirme ce que j'écrivais ci-dessous :
>
> > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg 
> a
> > écrit :
> >
> >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >>>
> >>> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet
> par
> >>> le serveur. Du coup pas de filtrage possible si c'est option est
> activée.
> >>
> >> Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
> >> du tunnel entre deux clients ne transitent pas par l'interface tun/tap
> >> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
> >> mais les paquets transportant le tunnel passent quand même par le
> >> serveur openvpn.
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Pascal Hambourg


Le 23/01/2019 à 15:58, Olivier a écrit :


[1] https://serverfault.com/questions/736274/openvpn-client-to-client


Ce lien confirme ce que j'écrivais ci-dessous :


Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :


Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :


1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.


Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
du tunnel entre deux clients ne transitent pas par l'interface tun/tap
ni la pile réseau de la machine qui fait tourner le serveur openvpn,
mais les paquets transportant le tunnel passent quand même par le
serveur openvpn.

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier

Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :

>
> Il y a une bidouille possible à base de double NAT source+destination.
> Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
> définit un réseau externe unique, on configure le routage des réseaux
> externes sur le serveur openvpn et on met en place des règles NETMAP sur
> la passerelle de chaque réseau pour faire en sorte que :
> - quand un paquet est émis vers le tunnel, son adresse source est mappée
> en son adresse externe correspondant au réseau ;
> - quant un paquet est reçu par le tunnel à destination d'une adresse
> externe, son adresse est mappée en l'adresse interne correspondante.
>
> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>
>
Excellent !
Je ne connaissait pas l'option -j NETMAP qui a l'air adaptée car si sur
beaucoup de sites distants, je retrouve les mêmes adresses IP, j'ai aussi
une nomenclature avec un entier unique pour chaque site.
Il devrait pas être difficile d'associer cet entier à une plage d'adresse
propre à chaque site.

Merci infiniment pour l'avoir signalée

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier

Mea culpa: voici le lien manquant !

[1] https://serverfault.com/questions/736274/openvpn-client-to-client

Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :

> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >
> > 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> > le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
> du tunnel entre deux clients ne transitent pas par l'interface tun/tap
> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
> mais les paquets transportant le tunnel passent quand même par le
> serveur openvpn.
>
> > 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24
> ),
> > je ne vois pas comment il sera possible de router les paquets d'un réseau
> > comme il faut. Donc je ne vois pas comment ça peut marcher.
>
> Il y a une bidouille possible à base de double NAT source+destination.
> Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
> définit un réseau externe unique, on configure le routage des réseaux
> externes sur le serveur openvpn et on met en place des règles NETMAP sur
> la passerelle de chaque réseau pour faire en sorte que :
> - quand un paquet est émis vers le tunnel, son adresse source est mappée
> en son adresse externe correspondant au réseau ;
> - quant un paquet est reçu par le tunnel à destination d'une adresse
> externe, son adresse est mappée en l'adresse interne correspondante.
>
> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>
> >> J'ai découvert que je pouvais utiliser l'option client-to-client
> d'OpenVPN
> >> pour permettre la communication directe entre deux clients OpenVPN.
> >> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> >> configuration réseau du serveur OpenVPN" : les flux passaient
> directement
> >> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
> >> serveur OpenVPN définir des régles très précises comme celle de
> n'autoriser
> >> que la communication depuis ou vers un ou deux clients OpenVPN.
>
> Qu'est-ce que [1] ?
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Pascal Hambourg


Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :


1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.


Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur 
du tunnel entre deux clients ne transitent pas par l'interface tun/tap 
ni la pile réseau de la machine qui fait tourner le serveur openvpn, 
mais les paquets transportant le tunnel passent quand même par le 
serveur openvpn.



2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
je ne vois pas comment il sera possible de router les paquets d'un réseau
comme il faut. Donc je ne vois pas comment ça peut marcher.


Il y a une bidouille possible à base de double NAT source+destination.
Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on 
définit un réseau externe unique, on configure le routage des réseaux 
externes sur le serveur openvpn et on met en place des règles NETMAP sur 
la passerelle de chaque réseau pour faire en sorte que :
- quand un paquet est émis vers le tunnel, son adresse source est mappée 
en son adresse externe correspondant au réseau ;
- quant un paquet est reçu par le tunnel à destination d'une adresse 
externe, son adresse est mappée en l'adresse interne correspondante.


Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.


J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
pour permettre la communication directe entre deux clients OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la
configuration réseau du serveur OpenVPN" : les flux passaient directement
d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
serveur OpenVPN définir des régles très précises comme celle de n'autoriser
que la communication depuis ou vers un ou deux clients OpenVPN.


Qu'est-ce que [1] ?

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Baptiste Chappe

Hello,

Première intervention sur la ML :)

Je remote avec un VPS OVH 600 sites distants via du OpenVPN et du Mikrotik
sur site. Des sites en chine (pas HK) via des protocoles exotiques pour ne
pas être filtrer (voir stunnel).
Les réseaux clients ne doivent pas avoir de même subnet.
C'est un peu compliqué au départ mais en étant rigoureux, je fais du 1
touch provisionning  sur mes clients OpenVPN

Un exemple de configuration de ma "tete" vpn vers un client Mikro en Europe.

port 443
proto tcp
dev tun


ca /etc/openvpn/CL001-XXX/ca.crt
cert /etc/openvpn/CL001-XXX/server.crt
key /etc/openvpn/CL001-XXX/server.key
dh /etc/openvpn/CL001-XXX/dh2048.pem

# IP DU SERVEUR
server 172.30.1.0 255.255.255.0

client-config-dir /etc/openvpn/CL001-XXX/CSO
ccd-exclusive

# LE SERVEUR APPRENDS LES ROUTES - TAPER ROUTE

route 192.168.1.0 255.255.255.0
route 192.168.68.0 255.255.255.0
route 192.168.5.0 255.255.255.0

keepalive 10 120
cipher aes256
auth sha1

log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 4
mute 20

Un exemple de configuration de ma "tete" vpn vers un client Mikro

### CSO ##

#ifconfig-push 172.30.1.2 172.30.1.1
push "route 172.30.2.0 255.255.255.0"
push "route 172.30.99.0 255.255.255.0"
#push "route 192.168.5.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0

Une trace depuis un autre VPS

root@ > traceroute 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
 1  VPN-OVH-MONITORING (172.30.2.1)  11.316 ms  22.360 ms  22.343 ms
 2  MF-MONITORING (192.168.1.251)  33.140 ms  44.087 ms  44.108 ms
root@ ~ >

Bon courage,

Baptiste Chappe



Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch  a
écrit :

> Bonjour Olivier,
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
>
> 3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
> propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
> peux te donner des exemples si tu en as besoin.
>
> obitwo
>
> Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :
>
>> Bonjour,
>>
>> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
>> Debian sur lequel un client OpenVPN  est installé.
>>
>> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
>> client OpenVPN, atteindre les machines connectées des différents réseaux
>> locaux distants qui par ailleurs, sont à peu près tous configurés de la
>> même façon (tous en 192.168.1.0/24, par exemple).
>>
>> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
>> +  sur mon PC:
>> A. je lance mon client OpenVPN
>> B. j'adapte ma configuration réseau en indiquant comment atteindre les
>> machines d'un réseau distant
>> + sur mon serveur OpenVPN
>> C. j'adapte ma configuration réseau
>> + sur un routeur Debian distant particulier:
>> D. j'adapte la configuration réseau afin que les machines du réseau local
>> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
>> passerelle par défaut de ces machines).
>>
>> Le serveur OpenVPN est une machine sur le cloud.
>> J'ai découvert que je pouvais utiliser l'option client-to-client
>> d'OpenVPN pour permettre la communication directe entre deux clients
>> OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
>>
>> Mes questions:
>> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>>
>> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
>> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
>> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
>> Qu'en pensez-vous ?
>>
>> 3. Que faire pour les étapes B et C ?
>> J'ai essayé sans trop de succès différentes commande "ip route add" sans
>> succès pour l'instant.
>>
>> Slts
>>
>>
>>
>>
>>
>>
>>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier

Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch  a
écrit :

> Bonjour Olivier,
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
>

Je viens d'y passer la matinée mais sans succès malheureusement.

En mode client-to-client, les clients peuvent facilement se parler mais
c'est tout:
une commande "ip route add 192.168.1.0/24 via 10.8.1.40"  est refusée même
si je peux atteindre (via openvpn) l'adresse 10.8.1.40.

J'ai l'impression qu'il faut jouer avec des paramètres OpenVPN  comme route
(côte client OpenVPN) et/ou iroute (côte serveur OpenVPN) mais je n'ai pas
encore essayé.

>
> 3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
> propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
> peux te donner des exemples si tu en as besoin.
>
> obitwo
>
> Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :
>
>> Bonjour,
>>
>> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
>> Debian sur lequel un client OpenVPN  est installé.
>>
>> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
>> client OpenVPN, atteindre les machines connectées des différents réseaux
>> locaux distants qui par ailleurs, sont à peu près tous configurés de la
>> même façon (tous en 192.168.1.0/24, par exemple).
>>
>> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
>> +  sur mon PC:
>> A. je lance mon client OpenVPN
>> B. j'adapte ma configuration réseau en indiquant comment atteindre les
>> machines d'un réseau distant
>> + sur mon serveur OpenVPN
>> C. j'adapte ma configuration réseau
>> + sur un routeur Debian distant particulier:
>> D. j'adapte la configuration réseau afin que les machines du réseau local
>> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
>> passerelle par défaut de ces machines).
>>
>> Le serveur OpenVPN est une machine sur le cloud.
>> J'ai découvert que je pouvais utiliser l'option client-to-client
>> d'OpenVPN pour permettre la communication directe entre deux clients
>> OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
>>
>> Mes questions:
>> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>>
>> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
>> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
>> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
>> Qu'en pensez-vous ?
>>
>> 3. Que faire pour les étapes B et C ?
>> J'ai essayé sans trop de succès différentes commande "ip route add" sans
>> succès pour l'instant.
>>
>> Slts
>>
>>
>>
>>
>>
>>
>>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier Bitsch

Bonjour Olivier,

1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.

2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
je ne vois pas comment il sera possible de router les paquets d'un réseau
comme il faut. Donc je ne vois pas comment ça peut marcher.

3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
peux te donner des exemples si tu en as besoin.

obitwo

Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :

> Bonjour,
>
> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
> Debian sur lequel un client OpenVPN  est installé.
>
> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
> client OpenVPN, atteindre les machines connectées des différents réseaux
> locaux distants qui par ailleurs, sont à peu près tous configurés de la
> même façon (tous en 192.168.1.0/24, par exemple).
>
> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
> +  sur mon PC:
> A. je lance mon client OpenVPN
> B. j'adapte ma configuration réseau en indiquant comment atteindre les
> machines d'un réseau distant
> + sur mon serveur OpenVPN
> C. j'adapte ma configuration réseau
> + sur un routeur Debian distant particulier:
> D. j'adapte la configuration réseau afin que les machines du réseau local
> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
> passerelle par défaut de ces machines).
>
> Le serveur OpenVPN est une machine sur le cloud.
> J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
> pour permettre la communication directe entre deux clients OpenVPN.
> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> configuration réseau du serveur OpenVPN" : les flux passaient directement
> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
> que la communication depuis ou vers un ou deux clients OpenVPN.
>
> Mes questions:
> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>
> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
> Qu'en pensez-vous ?
>
> 3. Que faire pour les étapes B et C ?
> J'ai essayé sans trop de succès différentes commande "ip route add" sans
> succès pour l'instant.
>
> Slts
>
>
>
>
>
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Daniel Huhardeaux


Le 22/01/2019 à 19:18, Olivier a écrit :



Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <mailto:no-s...@tootai.net>> a écrit :


Le 22/01/2019 à 16:48, Olivier a écrit :
 > Bonjour,

Bonjour



1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux
joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

Comment le "routage" entre le réseau distant et les clients du VPN ?


Le serveur OpenVPN sait comment joindre chaque IP puisque chaque client 
pousse sa route. Pour que cela fonctionne aussi avec les machines 
Windows un masquerade fait son job. J'ai créé un script (cde up de la 
config openvpn) qui fait le travail lorsque le VPN est monté, script 
installé sur chaque client OpenVPN d'un site.


--
Daniel

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Daniel Huhardeaux


Le 22/01/2019 à 19:16, Olivier a écrit :

Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux 
équipements distants via des commandes SSH du type ssh -f -N foo@remote 
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner 
les ports distants, choisir des ports disponibles sur ma machine, 
ajouter un éventuel rebond.


Je recherche maintenant à re-configurer le réseau afin d'avoir une 
re-configuration ponctuelle plus générique


Justement, en centralisant les connexions sur un serveur, VPN et/ou ssh, 
tu ne reconfigures plus le réseau: le fichier ~/.ssh/config contiendra 
les commandes nécessaires afin de ne faire qu'un simple "ssh "


Je trouve d'ailleurs dommage que mosh ne gère pas le fichier config de ssh.



Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux <mailto:no-s...@tootai.net>> a écrit :


Le 22/01/2019 à 16:48, Olivier a écrit :
 > Bonjour,

Bonjour

 >
 > J'ai plusieurs réseaux locaux distants dont le routeur est un
serveur
 > Debian sur lequel un client OpenVPN  est installé.
 >
 > Je souhaite pouvoir depuis mon propre PC sur lequel est aussi
installé
 > un client OpenVPN, atteindre les machines connectées des différents
 > réseaux locaux distants qui par ailleurs, sont à peu près tous
 > configurés de la même façon (tous en 192.168.1.0/24
<http://192.168.1.0/24>
 > <http://192.168.1.0/24>, par exemple).
 >
 > Pour fixer les choses, j'envisage d'opérer de la façon suivante:
 > +  sur mon PC:
 > A. je lance mon client OpenVPN
 > B. j'adapte ma configuration réseau en indiquant comment
    atteindre les
 > machines d'un réseau distant
 > + sur mon serveur OpenVPN
 > C. j'adapte ma configuration réseau
 > + sur un routeur Debian distant particulier:
 > D. j'adapte la configuration réseau afin que les machines du réseau
 > local puissent communiquer avec mon PC (par chance, le routeur
    Debian
 > est déjà la passerelle par défaut de ces machines).
 >
 > Le serveur OpenVPN est une machine sur le cloud.
 > J'ai découvert que je pouvais utiliser l'option client-to-client
 > d'OpenVPN pour permettre la communication directe entre deux clients
 > OpenVPN.
 > J'ai lu en [1], que cette communication s'opérait à "l'insu de la
 > configuration réseau du serveur OpenVPN" : les flux passaient
 > directement d'un client OpenVPN à un autre sans que je puisse,
avec le
 > firewall du serveur OpenVPN définir des régles très précises
comme celle
 > de n'autoriser que la communication depuis ou vers un ou deux
clients
 > OpenVPN.
 >
 > Mes questions:
 > 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
 >
 > 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
 > iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
 > iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
 > Qu'en pensez-vous ?
 >
 > 3. Que faire pour les étapes B et C ?
 > J'ai essayé sans trop de succès différentes commande "ip route
add" sans
 > succès pour l'instant.

Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux
joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

    L'inconvénient pour toi est que justement tous les réseaux auxquels tu
veux te joindre ont le même plan d'adressage IP

2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
avec autossh (reverse ssh).

Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
machine derrière les réseaux clients en utilisant les commandes ssh
(pour le cas 2 essentiellement ProxyCommand pour tous les clients,
Hostname en plus pour ceux en VPN)

-- 
Daniel

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Olivier

Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux  a
écrit :

> Le 22/01/2019 à 16:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour
>
>
>
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
>
> Comment le "routage" entre le réseau distant et les clients du VPN ?

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Olivier

Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux
équipements distants via des commandes SSH du type ssh -f -N foo@remote
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner les
ports distants, choisir des ports disponibles sur ma machine, ajouter un
éventuel rebond.

Je recherche maintenant à re-configurer le réseau afin d'avoir une
re-configuration ponctuelle plus générique

Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux  a
écrit :

> Le 22/01/2019 à 16:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour
>
> >
> > J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
> > Debian sur lequel un client OpenVPN  est installé.
> >
> > Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé
> > un client OpenVPN, atteindre les machines connectées des différents
> > réseaux locaux distants qui par ailleurs, sont à peu près tous
> > configurés de la même façon (tous en 192.168.1.0/24
> > <http://192.168.1.0/24>, par exemple).
> >
> > Pour fixer les choses, j'envisage d'opérer de la façon suivante:
> > +  sur mon PC:
> > A. je lance mon client OpenVPN
> > B. j'adapte ma configuration réseau en indiquant comment atteindre les
> > machines d'un réseau distant
> > + sur mon serveur OpenVPN
> > C. j'adapte ma configuration réseau
> > + sur un routeur Debian distant particulier:
> > D. j'adapte la configuration réseau afin que les machines du réseau
> > local puissent communiquer avec mon PC (par chance, le routeur Debian
> > est déjà la passerelle par défaut de ces machines).
> >
> > Le serveur OpenVPN est une machine sur le cloud.
> > J'ai découvert que je pouvais utiliser l'option client-to-client
> > d'OpenVPN pour permettre la communication directe entre deux clients
> > OpenVPN.
> > J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> > configuration réseau du serveur OpenVPN" : les flux passaient
> > directement d'un client OpenVPN à un autre sans que je puisse, avec le
> > firewall du serveur OpenVPN définir des régles très précises comme celle
> > de n'autoriser que la communication depuis ou vers un ou deux clients
> > OpenVPN.
> >
> > Mes questions:
> > 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
> >
> > 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
> > iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
> > iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
> > Qu'en pensez-vous ?
> >
> > 3. Que faire pour les étapes B et C ?
> > J'ai essayé sans trop de succès différentes commande "ip route add" sans
> > succès pour l'instant.
>
> Perso j'utilise 2 types d'organisations:
>
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
>
> L'inconvénient pour toi est que justement tous les réseaux auxquels tu
> veux te joindre ont le même plan d'adressage IP
>
> 2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
> auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
> avec autossh (reverse ssh).
>
> Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
> machine derrière les réseaux clients en utilisant les commandes ssh
> (pour le cas 2 essentiellement ProxyCommand pour tous les clients,
> Hostname en plus pour ceux en VPN)
>
> --
> Daniel
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Daniel Huhardeaux


Le 22/01/2019 à 16:48, Olivier a écrit :

Bonjour,


Bonjour



J'ai plusieurs réseaux locaux distants dont le routeur est un serveur 
Debian sur lequel un client OpenVPN  est installé.


Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé 
un client OpenVPN, atteindre les machines connectées des différents 
réseaux locaux distants qui par ailleurs, sont à peu près tous 
configurés de la même façon (tous en 192.168.1.0/24 
<http://192.168.1.0/24>, par exemple).


Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+  sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les 
machines d'un réseau distant

+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau 
local puissent communiquer avec mon PC (par chance, le routeur Debian 
est déjà la passerelle par défaut de ces machines).


Le serveur OpenVPN est une machine sur le cloud.
J'ai découvert que je pouvais utiliser l'option client-to-client 
d'OpenVPN pour permettre la communication directe entre deux clients 
OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la 
configuration réseau du serveur OpenVPN" : les flux passaient 
directement d'un client OpenVPN à un autre sans que je puisse, avec le 
firewall du serveur OpenVPN définir des régles très précises comme celle 
de n'autoriser que la communication depuis ou vers un ou deux clients 
OpenVPN.


Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec 
iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):

iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans 
succès pour l'instant.


Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode 
tun, tous les serveurs des sites clients s'y connectent, je peux joindre 
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan 
d'adresses IP.


L'inconvénient pour toi est que justement tous les réseaux auxquels tu 
veux te joindre ont le même plan d'adressage IP


2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC 
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh 
avec autossh (reverse ssh).


Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel 
machine derrière les réseaux clients en utilisant les commandes ssh 
(pour le cas 2 essentiellement ProxyCommand pour tous les clients, 
Hostname en plus pour ceux en VPN)


--
Daniel

Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Olivier

Bonjour,

J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
Debian sur lequel un client OpenVPN  est installé.

Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
client OpenVPN, atteindre les machines connectées des différents réseaux
locaux distants qui par ailleurs, sont à peu près tous configurés de la
même façon (tous en 192.168.1.0/24, par exemple).

Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+  sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les
machines d'un réseau distant
+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau local
puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
passerelle par défaut de ces machines).

Le serveur OpenVPN est une machine sur le cloud.
J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
pour permettre la communication directe entre deux clients OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la
configuration réseau du serveur OpenVPN" : les flux passaient directement
d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
serveur OpenVPN définir des régles très précises comme celle de n'autoriser
que la communication depuis ou vers un ou deux clients OpenVPN.

Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans
succès pour l'instant.

Slts

Re: OpenVPN sous Stretch avec systemd

2018-09-12 Par sujet Erwan David

On Wed, Sep 12, 2018 at 02:04:14PM CEST, daniel huhardeaux  
said:
> Le 12/09/2018 à 10:53, roger.tar...@free.fr a écrit :
> > Bonjour
> Bonjour
> > [...]
> > Quel est le comportement normal que doit avoir un client VPN qui se met en 
> > veille/hibernation ?
> > Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
> Pour quelle-s raison-s ?

Pour ne pas bouffer un slot de connexion et les ressources associées
sur le serveur de VPN pendant qu'il dormira par exemple


-- 
Erwan

Re: OpenVPN sous Stretch avec systemd

2018-09-12 Par sujet daniel huhardeaux


Le 12/09/2018 à 10:53, roger.tar...@free.fr a écrit :

Bonjour

Bonjour

[...]
Quel est le comportement normal que doit avoir un client VPN qui se met en 
veille/hibernation ?
Ne devrait-il pas au préalable se déconnecter du serveur VPN ?

Pour quelle-s raison-s ?

Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à 
vérifier plus souvent que le client connecté est présent sur le réseau ou s'il 
est juste inactif.

Quel est l'intérêt ?


* network-manager
Il me semble que l'état des connexions du système est parfois incohérent entre 
l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System 
settings/Network.
Est-ce network-manager qui est responsable de ça ?
Peut-on le configurer (ou d'autres composants) pour que les connexions du 
système soient gérées par systemd, manuellement ou par network-manager de 
manière cohérente ?
J'ai entendu quelquefois des informaticiens se plaindre de network-manager 
apparemment pour les mêmes raisons.
Ceci est un autre débat. Il y a quelques temps NM était une catastrophe, 
je trouve qu'il c'est stabilisé. Cela dit je continue à la mano avec le 
fichier interfaces et Wicd.


Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par 
network-manager ?

Option VPN du menu de NM en ayant pris soin d'installer nm-openvpn


Qu'est-ce qui est le plus robuste à l'utilisation ?
Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien 
network-manager ?

à toi de tester et choisir ce qui te conviens le mieux.

- Original Message -
From: daniel huhardeaux 
To: debian-user-french@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd

Le 09/09/2018 à 20:28, roger.tar...@free.fr a écrit :

[...] et un message d'erreur ("Authenticate/Decrypt packet error:
cipher final failed") trop discrets d'OpenVPN

Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un
niveau inférieur lorsque le VPN est validé fonctionnel.


[...]

Il semble que l'absence d'accès au réseau internet était causée par
cette "transaction en échec en boucle" qui se prolongeait entre le
client et le server OpenVPN.

Non, elle est dûe au fait que le routage était en place mais le VPN non
fonctionnel (route par défaut vers le VPN)


2/ la connaissance du système de configuration des réseaux avec
Stretch est encore plus d'actualité.
En effet, quand ça marche c'est bien, mais quand ça foire il est
crucial de savoir ce qui se passe.
Et là,rien n'a indiqué ce qui était en train de clocher.
De plus, je comprends que ce serait un système en cours de transition.

Comment faudrait-il procéder pour savoir dans quel état se trouve la
configuration de composants logiciels réseaux et la configuration
réseau d'une machine Stretch ?

Il n'y a pas de différences (peu éventuellement) entre la gestion réseau
Jessie et Stretch. Les programmes et configurations ont éventuellement
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu
cherches dans le fichier interfaces alors que c'est network-manager qui
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il
faudrait pour être cohérent faire gérer le VPN également par
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).


--
Daniel

Re: OpenVPN sous Stretch avec systemd

2018-09-12 Par sujet roger . tarani

Bonjour 

* 
En ce qui concerne la mise en veille ou en hibernation durables, cad 
suffisamment longue pour que le serveur déconnecte le client, lorsque la 
machine cliente se réveille, elle se reconnecte comme lors du démarrage. 
Si c'est plus rapide, je crois que ça marche aussi. Je vais refaire le test. 

Quel est le comportement normal que doit avoir un client VPN qui se met en 
veille/hibernation ?
Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à 
vérifier plus souvent que le client connecté est présent sur le réseau ou s'il 
est juste inactif. 

* network-manager
Il me semble que l'état des connexions du système est parfois incohérent entre 
l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System 
settings/Network. 
Est-ce network-manager qui est responsable de ça ?
Peut-on le configurer (ou d'autres composants) pour que les connexions du 
système soient gérées par systemd, manuellement ou par network-manager de 
manière cohérente ?
J'ai entendu quelquefois des informaticiens se plaindre de network-manager 
apparemment pour les mêmes raisons. 

Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par 
network-manager ?

Qu'est-ce qui est le plus robuste à l'utilisation ?
Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien 
network-manager ?

Merci
Bonne journée 






- Original Message -
From: daniel huhardeaux 
To: debian-user-french@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd

Le 09/09/2018 à 20:28, roger.tar...@free.fr a écrit :
> [...] et un message d'erreur ("Authenticate/Decrypt packet error: 
> cipher final failed") trop discrets d'OpenVPN

Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose 
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un 
niveau inférieur lorsque le VPN est validé fonctionnel.

> [...]
>
> Il semble que l'absence d'accès au réseau internet était causée par 
> cette "transaction en échec en boucle" qui se prolongeait entre le 
> client et le server OpenVPN.

Non, elle est dûe au fait que le routage était en place mais le VPN non 
fonctionnel (route par défaut vers le VPN)

>
> 2/ la connaissance du système de configuration des réseaux avec 
> Stretch est encore plus d'actualité.
> En effet, quand ça marche c'est bien, mais quand ça foire il est 
> crucial de savoir ce qui se passe.
> Et là,rien n'a indiqué ce qui était en train de clocher.
> De plus, je comprends que ce serait un système en cours de transition.
>
> Comment faudrait-il procéder pour savoir dans quel état se trouve la 
> configuration de composants logiciels réseaux et la configuration 
> réseau d'une machine Stretch ?

Il n'y a pas de différences (peu éventuellement) entre la gestion réseau 
Jessie et Stretch. Les programmes et configurations ont éventuellement 
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu 
cherches dans le fichier interfaces alors que c'est network-manager qui 
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il 
faudrait pour être cohérent faire gérer le VPN également par 
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).

-- 
Daniel

Re: OpenVPN sous Stretch avec systemd

2018-09-09 Par sujet daniel huhardeaux


Le 09/09/2018 à 20:28, roger.tar...@free.fr a écrit :
[...] et un message d'erreur ("Authenticate/Decrypt packet error: 
cipher final failed") trop discrets d'OpenVPN


Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose 
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un 
niveau inférieur lorsque le VPN est validé fonctionnel.



[...]

Il semble que l'absence d'accès au réseau internet était causée par 
cette "transaction en échec en boucle" qui se prolongeait entre le 
client et le server OpenVPN.


Non, elle est dûe au fait que le routage était en place mais le VPN non 
fonctionnel (route par défaut vers le VPN)




2/ la connaissance du système de configuration des réseaux avec 
Stretch est encore plus d'actualité.
En effet, quand ça marche c'est bien, mais quand ça foire il est 
crucial de savoir ce qui se passe.

Et là,rien n'a indiqué ce qui était en train de clocher.
De plus, je comprends que ce serait un système en cours de transition.

Comment faudrait-il procéder pour savoir dans quel état se trouve la 
configuration de composants logiciels réseaux et la configuration 
réseau d'une machine Stretch ?


Il n'y a pas de différences (peu éventuellement) entre la gestion réseau 
Jessie et Stretch. Les programmes et configurations ont éventuellement 
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu 
cherches dans le fichier interfaces alors que c'est network-manager qui 
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il 
faudrait pour être cohérent faire gérer le VPN également par 
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).


--
Daniel

Re: OpenVPN sous Stretch avec systemd

2018-09-09 Par sujet roger . tarani

Waouh !... 

1/ Voilà ce que je viens de découvrir en analysant ma configuration OpenVPN de 
la machine Stretch : 
j'utilisais un fichier de configuration OpenVPN un poil trop âgé encore en 
AES128, alors que j'utilisais le nouveau fichier de conf en AES256 pour la 
machine Jessie (le serveur a été passé en AES256). 
Cela provoquait un Warning ( 'cipher' is used inconsistently, local='cipher 
AES-128-CBC', remote='cipher AES-256-CBC') et un message d'erreur 
("Authenticate/Decrypt packet error: cipher final failed") trop discrets 
d'OpenVPN : ce qui expliquait le comportement bizarre du client qui cherchait à 
se reconnecter régulièrement et n'était en fait pas connecté comme l'indiquait 
faussement le serveur. 



Dès que j'ai remis le bon fichier de conf en AES256 (au même bon endroit) le 
comportement de la machine Stretch est redevenu normal, cad identique à celui 
de la machine Jessie avec les commandes suivantes : $ sudo systemctl start 
openvpn@monserveur.service 
$ sudo systemctl restart openvpn@monserveur.service 
$ sudo systemctl stop openvpn@monserveur.service 
On voit sur le serveur OpenVPN que le client se connecte et se déconnecte 
_immédiatement_. 
Et le ping via VPN entre les deux machines Jessie et Stretch fonctionne à 
nouveau. 

$ ip r 
default via 212.27.38.253 dev tun0 
< mon -ip-fixe-masquée> via 192.168.0.1 dev wlp32s0 
169.254.0.0/16 dev tun0 scope link metric 1000 
192.168.0.0/24 via 212.27.38.253 dev tun0 
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 metric 600 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68 

$ sudo ifconfig 
enp8s0: flags=4099 mtu 1500 
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet) 
RX... 

lo: flags=73 mtu 65536 
inet 127.0.0.1 netmask 255.0.0.0 
inet6 ::1 prefixlen 128 scopeid 0x10 
loop txqueuelen 1 (Local Loopback) 
RX... 

tun0: flags=4305 mtu 1500 
inet 192.168.27.68 netmask 255.255.255.255 destination 212.27.38.253 
inet6 fe80::bb3e:ca65:f4bc:9df3 prefixlen 64 scopeid 0x20 
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) 
RX... 

wlp32s0: flags=4163 mtu 1500 
inet 192.168.0.102 netmask 255.255.255.0 broadcast 192.168.0.255 
inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20 
ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet) 
RX... 

Il semble que l'absence d'accès au réseau internet était causée par cette 
"transaction en échec en boucle" qui se prolongeait entre le client et le 
server OpenVPN. 



2/ la connaissance du système de configuration des réseaux avec Stretch est 
encore plus d'actualité. 
En effet, quand ça marche c'est bien, mais quand ça foire il est crucial de 
savoir ce qui se passe. 
Et là,rien n'a indiqué ce qui était en train de clocher. 


De plus, je comprends que ce serait un système en cours de transition. 


Comment faudrait-il procéder pour savoir dans quel état se trouve la 
configuration de composants logiciels réseaux et la configuration réseau d'une 
machine Stretch ? 

Daniel, merci beaucoup pour le temps que tu as passé pour m'aider à régler ce 
problème.

Re: OpenVPN sous Stretch avec systemd

2018-09-09 Par sujet daniel huhardeaux


Le 09/09/2018 à 19:02, roger.tar...@free.fr a écrit :

[...]
- machine Stretch en WiFi :
$ sudo ifconfig
enp8s0: flags=4099  mtu 1500
 ether 00:17:42:7a:c8:74  txqueuelen 1000  (Ethernet)
 RX packets 16979  bytes 7973796 (7.6 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 15730  bytes 2772306 (2.6 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 device interrupt 16

lo: flags=73  mtu 65536
 inet 127.0.0.1  netmask 255.0.0.0
 inet6 ::1  prefixlen 128  scopeid 0x10
 loop  txqueuelen 1  (Local Loopback)
 RX packets 5253  bytes 417199 (407.4 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 5253  bytes 417199 (407.4 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp32s0: flags=4163  mtu 1500
 inet6 fe80::728e:fd77:36f1:a585  prefixlen 64  scopeid 0x20
 ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
 RX packets 287447  bytes 231604167 (220.8 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 221935  bytes 36433522 (34.7 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[...]


Y'a un problème, pas d'IP !

--
Daniel

Re: OpenVPN sous Stretch avec systemd

2018-09-09 Par sujet roger . tarani

Bonjour,
Suite à tes remarques, j'ai ajouté mes observations concernant les deux 
machines (Jessie qui fonctionne et Stretch qui râle).
Merci

- Original Message -
From: "daniel huhardeaux" 
To: debian-user-french@lists.debian.org
Sent: Sunday, September 9, 2018 3:05:48 PM
Subject: Re: OpenVPN sous Stretch avec systemd

Le 09/09/2018 à 02:20, roger.tar...@free.fr a écrit :
> [...]
> $ sudo ifconfig -a
> enp8s0: flags=4099  mtu 1500
>  ether 00:17:42:7a:c8:74  txqueuelen 1000  (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
>  device interrupt 16
>
> lo: flags=73  mtu 65536
>  inet 127.0.0.1  netmask 255.0.0.0
>  inet6 ::1  prefixlen 128  scopeid 0x10
>  loop  txqueuelen 1  (Local Loopback)
>  RX packets 4811  bytes 384593 (375.5 KiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 4811  bytes 384593 (375.5 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> tun0: flags=4305  mtu 1500
>  inet 192.168.27.68  netmask 255.255.255.255  destination 
> 212.27.38.253
>  inet6 fe80::fffe:d16a:8dbb:72cd  prefixlen 64  scopeid 0x20
>  unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 
> 100  (UNSPEC)
>  RX packets 0  bytes 0 (0.0 B)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 16  bytes 1031 (1.0 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> wlp32s0: flags=4163  mtu 1500
>  inet 192.168.0.5  netmask 255.255.255.0  broadcast 192.168.0.255
>  inet6 fe80::8ef3:422:1504:638f  prefixlen 64  scopeid 0x20
>  ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
>  RX packets 246563  bytes 210114507 (200.3 MiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 185695  bytes 29883060 (28.4 MiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Daniel dit :
Donc connecté en WIFI, pas de liaison filaire. L'IP destination de tun0 
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant 
que le masque est en /24 et que le serveur VPN est de type server. Je ne 
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE: 
pourquoi via VPN ?

Roger dit :
sur mon autre machine en Jessie, j'ai aussi 212.27.38.253 comme ça ;
inet 192.168.27.67 peer 212.27.38.253/32 scope global tun0
tandis que sur la machine en Stretch, j'ai :
inet 192.168.27.68  netmask 255.255.255.255  destination 212.27.38.253


machine Jessie (réseaux fonctionnels) :
$ sudo ifconfig
eth0  Link encap:Ethernet  HWaddr 00:23:26:3b:9f:15  
  inet addr:192.168.0.152  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::223:26ff:fe3b:9f15/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:3954 errors:0 dropped:1 overruns:0 frame:0
  TX packets:1586 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:2354094 (2.2 MiB)  TX bytes:209838 (204.9 KiB)
  Interrupt:16 

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:221 errors:0 dropped:0 overruns:0 frame:0
  TX packets:221 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:23287 (22.7 KiB)  TX bytes:23287 (22.7 KiB)

tun0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  inet addr:192.168.27.67  P-t-P:212.27.38.253  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:1063 errors:0 dropped:0 overruns:0 frame:0
  TX packets:716 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:1356357 (1.2 MiB)  TX bytes:46040 (44.9 KiB)


toujours la machine Jessie :
$ ip r
default via 212.27.38.253 dev tun0 
default via 212.27.38.253 dev tun0  proto static  metric 1024 
 via 192.168.0.1 dev eth0 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.152 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0  proto kernel  scope link  src 192.168.27.67



> et
> $ cat /etc/network/interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> source /etc/network/interfaces.d/*
>
> # The loopback network interface
> auto lo
> iface lo inet l

Re: OpenVPN sous Stretch avec systemd

2018-09-09 Par sujet daniel huhardeaux


Le 09/09/2018 à 02:20, roger.tar...@free.fr a écrit :

[...]
$ sudo ifconfig -a
enp8s0: flags=4099  mtu 1500
 ether 00:17:42:7a:c8:74  txqueuelen 1000  (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
 device interrupt 16

lo: flags=73  mtu 65536
 inet 127.0.0.1  netmask 255.0.0.0
 inet6 ::1  prefixlen 128  scopeid 0x10
 loop  txqueuelen 1  (Local Loopback)
 RX packets 4811  bytes 384593 (375.5 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 4811  bytes 384593 (375.5 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305  mtu 1500
 inet 192.168.27.68  netmask 255.255.255.255  destination 212.27.38.253
 inet6 fe80::fffe:d16a:8dbb:72cd  prefixlen 64  scopeid 0x20
 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100 
 (UNSPEC)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 16  bytes 1031 (1.0 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp32s0: flags=4163  mtu 1500
 inet 192.168.0.5  netmask 255.255.255.0  broadcast 192.168.0.255
 inet6 fe80::8ef3:422:1504:638f  prefixlen 64  scopeid 0x20
 ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
 RX packets 246563  bytes 210114507 (200.3 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 185695  bytes 29883060 (28.4 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Donc connecté en WIFI, pas de liaison filaire. L'IP destination de tun0 
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant 
que le masque est en /24 et que le serveur VPN est de type server. Je ne 
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE: 
pourquoi via VPN ?



et
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

Tiens, c'est bizarre puisqu'aucune interface n'est configurée ici (par rapport 
à mon habitude avec Jessie).


Tout dépend si tu utilises network-manager ou non. Si non, les 
définitions sont dans interfaces.d



Voilà ce que j'obtiens :
$ ip r
default via 212.27.38.253 dev tun0


??? Incohérent

 via 192.168.0.1 dev wlp32s0
Si la Freebox est en mode routeur elle prend en général l'IP 
192.168.0.254. As tu modifié? Si elle est en mode bridge 
 est attribuée à wlp32s0. Pour moi, tout semble 
incohérent.




169.254.0.0/16 dev tun0 scope link metric 1000
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
metric 600


2 fois la même route ...

[...]

On/je ne comprends pas quel est le but de ton VPN même le but tout court 
des manipulations. Vérifie que la table de routage et la liste des 
interfaces lorsque le VPN n'est pas monté (ifconfig sans option) sont 
cohérent et que le réseau local fonctionne.


--
Daniel

Re: OpenVPN sous Stretch avec systemd

- Original Message -
From: "daniel huhardeaux" 
To: debian-user-french@lists.debian.org
Sent: Sunday, September 9, 2018 12:51:25 AM
Subject: Re: OpenVPN sous Stretch avec systemd

Le 08/09/2018 à 21:59, roger.tar...@free.fr a écrit :
> [...]
>
> Roger dit :
> ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip

Ah, chez moi elle existe! Peu importe, c'est le résultat qui compte

> Peux-tu préciser ce que tu entends par "conformes" ?

Que les informations affichées soient celles qui correspondent à 
l'environnement. On ne peut en dire plus puisqu'aucune info réseau n'a 
été divulguée: combien de cartes réseau, identification des cartes, vpn 
en mode tun ou tapo, etc.

Roger dit :
$ ls /sys/class/net/  
enp8s0  lo  tun0  wlp32s0

Installons net-tools !
$ sudo apt-get install net-tools
Et :
$ sudo ifconfig -a
enp8s0: flags=4099  mtu 1500
ether 00:17:42:7a:c8:74  txqueuelen 1000  (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
device interrupt 16  

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 4811  bytes 384593 (375.5 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4811  bytes 384593 (375.5 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305  mtu 1500
inet 192.168.27.68  netmask 255.255.255.255  destination 212.27.38.253
inet6 fe80::fffe:d16a:8dbb:72cd  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  
(UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 16  bytes 1031 (1.0 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp32s0: flags=4163  mtu 1500
inet 192.168.0.5  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::8ef3:422:1504:638f  prefixlen 64  scopeid 0x20
ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
RX packets 246563  bytes 210114507 (200.3 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 185695  bytes 29883060 (28.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

et 
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

Tiens, c'est bizarre puisqu'aucune interface n'est configurée ici (par rapport 
à mon habitude avec Jessie).

> Voilà ce que j'obtiens :
> $ ip r
> default via 212.27.38.253 dev tun0
>  via 192.168.0.1 dev wlp32s0
> 169.254.0.0/16 dev tun0 scope link metric 1000
> 192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
> 192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 
> metric 600
> 192.168.27.64/27 via 212.27.38.253 dev tun0
> 212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68
>
> Ça vous parle ?
> Je cherche une solution pour cet autre problème de routage.

Donc le VPN devient la route par défaut: ne me semble pas logique car je 
suppose que l'IP  212.27.38.253 est celle de la box du réseau local côté 
WAN. Cela dépend également de la configuration de la box, mode routeur 
ou bridge. Lorsque le VPN n'est *PAS* monté relance cette commande pour 
vérifier les routes affichées et compare.

Roger dit :
Le VPN est en mode routé.

http://monip.fr/212.27.38.253
Adresse IP: 212.27.38.253
PTR enregistrement de ressource:freeplayer.freebox.fr
Organisation:   Free SAS
...

[...]
>
> CONSTAT INTERESSANT :
> systemd cherche à utiliser */etc/openvpn/client.conf* (avec le nom 
> client.conf) qui n'existe pas puisque j'ai le fichier de configuration 
> suivant :
> /etc/openvpn/*client*/config_openvpn_routed_debian.conf

J'ai toujours connu OpenVPN cherchant par défaut les fichiers de config 
dans /etc/openvpn pour Debian. Le répertoire de travail est dans le 
fichier de conf, /etc/init.d/openvpn: CONFIG_DIR=/etc/openvpn
En lancant manuellement (openvpn ) on peut 
définir n'importe quel chemin pour le fichier.

Roger dit : 
Oui, avec Jessie, je fais comme ça.
Je ne comprends pas l'objectif des répertoires /etc/openvpn/server et 
/etc/openvpn/client 
Je me suis dit bêtement que c'était dans /etc/openvpn/client qu'il fallait 
lancer le fichier de configuration du client...

> Je peux bricoler en copiant mon fichier de configuration client ici 
> avec ce nom client.conf (j'ai fait le test : et la commande $ sudo 
> systemctl status openvpn@client.service fonctionne)
> M

Re: OpenVPN sous Stretch avec systemd

2018-09-08 Par sujet daniel huhardeaux


Le 08/09/2018 à 21:59, roger.tar...@free.fr a écrit :

[...]

Roger dit :
ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip


Ah, chez moi elle existe! Peu importe, c'est le résultat qui compte


Peux-tu préciser ce que tu entends par "conformes" ?


Que les informations affichées soient celles qui correspondent à 
l'environnement. On ne peut en dire plus puisqu'aucune info réseau n'a 
été divulguée: combien de cartes réseau, identification des cartes, vpn 
en mode tun ou tapo, etc.



Voilà ce que j'obtiens :
$ ip r
default via 212.27.38.253 dev tun0
 via 192.168.0.1 dev wlp32s0
169.254.0.0/16 dev tun0 scope link metric 1000
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 
metric 600

192.168.27.64/27 via 212.27.38.253 dev tun0
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68

Ça vous parle ?
Je cherche une solution pour cet autre problème de routage.


Donc le VPN devient la route par défaut: ne me semble pas logique car je 
suppose que l'IP  212.27.38.253 est celle de la box du réseau local côté 
WAN. Cela dépend également de la configuration de la box, mode routeur 
ou bridge. Lorsque le VPN n'est *PAS* monté relance cette commande pour 
vérifier les routes affichées et compare.


[...]


CONSTAT INTERESSANT :
systemd cherche à utiliser */etc/openvpn/client.conf* (avec le nom 
client.conf) qui n'existe pas puisque j'ai le fichier de configuration 
suivant :

/etc/openvpn/*client*/config_openvpn_routed_debian.conf


J'ai toujours connu OpenVPN cherchant par défaut les fichiers de config 
dans /etc/openvpn pour Debian. Le répertoire de travail est dans le 
fichier de conf, /etc/init.d/openvpn: CONFIG_DIR=/etc/openvpn
En lancant manuellement (openvpn ) on peut 
définir n'importe quel chemin pour le fichier.


Je peux bricoler en copiant mon fichier de configuration client ici 
avec ce nom client.conf (j'ai fait le test : et la commande $ sudo 
systemctl status openvpn@client.service fonctionne)
Mais quelles sont les règles à respecter pour utiliser systemd avec 
OpenVPN ?


Celles des développeurs DEBIAN, donc dans /etc/openvpn


$ sudo journalctl -xe
[...]
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In 
[CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf

[...]


Dit la même chose, il cherche dans /etc/openvpn

Pouvez-vous me recommander un document de référence sur systemd que je 
me mette au niveau ?

Et, s'il existe, un document sur OpenVPN avec systemd ?


Comprendre systemd suffit. Voir dans 
/etc/systemd/system/multi-user.target.wants/openvpn.service et on 
trouvera /etc/openvpn comme working directory, ce qui rejoint init


[...]

A un moment, il faut rationnaliser et s'en tenir à un mécanisme robuste !
systemd continue a gérer la manière init (combien de temps?) afin de 
faciliter la transition.


--
Daniel

Re: OpenVPN sous Stretch avec systemd

PS :
Quand j'éteins ma machine en Jessie (shutdown), elle disparaît _instantanément_ 
du serveur OpenVPN.

Sur la machine en Stretch, quand je lance le client OpenVPN manuellement avec 
la commande 
$ sudo openvpn maconfig.conf 
le serveur l'enregistre immédiatement, et un Ctrl-C le fait disparaître 
_instantanément_ de sclients authentifiés par le serveur.

-> J'en conclue que mon serveur OpenVPN a un comportement acceptable.
 
Avec systemctl ET avec service, sur la machine en Stretch (qui me pose 
problème), il y a bien une gestion "automatique" mystérieuse du client OpenVPN.

Comment faire pour arriver à reproduire le comportement simple, naturel et 
reproductible avec ces outils de gestion de service ? (censés nous simplifier 
la vie)

Re: OpenVPN sous Stretch avec systemd





Merci. 


Roger dit : 


Je fais fonctionner sans souci un client OpenVPN sous Jessie. 
Manuellement ou automatiquement. 

Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de 
systemd). 
Je peux lancer le client OpenVPN en CLI 
$ sudo openvpn client.conf 
Et Ctrl-C pour interrompre. 



Daniel dit : 
sudo systemctl start openvpn ou openvpn@client pour ne lancer que ce client 

Roger dit : 
seule la commande suivante fonctionne (voir plus bas): 
$ sudo systemctl start openvpn 



Roger dit : 


En cherchant, j'ai réglé le problème de la façon suivante : 
$ cat /etc/default/openvpn 
... 
AUTOSTART="all" 
... 
Cette ligne est commentée par défaut. 

Puis, comme indiqué dans ce même fichier : 

$ sudo systemctl daemon-reload 
$ sudo systemctl restart openvpn 

Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et 
d'hibernation). 

Il reste cependant deux problèmes à régler : 
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme 
la machine Jessie dont l'IP est la même que toute machine qui s'y trouve). 
Je ne sais pas comment faire ? : oú dois-je chercher ? 



Daniel dit : 
systemctl ne joue en rien sur le routage, le problème doit venir d'autre part 
sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient 
conformes 
sudo ip r pour afficher les routes et vérifier qu'elles soient conformes 


Roger dit : 
ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip 
Peux-tu préciser ce que tu entends par "conformes" ? 
Voilà ce que j'obtiens : 
$ ip r 
default via 212.27.38.253 dev tun0 
 via 192.168.0.1 dev wlp32s0 
169.254.0.0/16 dev tun0 scope link metric 1000 
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 metric 600 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68 

Ça vous parle ? 
Je cherche une solution pour cet autre problème de routage. 



Roger dit : 


2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de 
reconnexion "sauvage" du client alors que le serveur voit le client connecté 
déclenche une trentaine de transactions "Failed" pendant quelques minutes et 
puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout. 
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec 
systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter) 



Daniel dit : 
sudo systemctl stop openvpn@client 
sudo systemctl start openvpn@client 
ou sudo systemctl restart openvpn@client 

Roger dit : 
$ sudo systemctl start openvpn 
fonctionne 
mais il y a un problème avec : 
$ sudo systemctl start openvpn@client 
Job for openvpn@client.service failed because the control process exited with 
error code. 
See "systemctl status openvpn@client.service" and "journalctl -xe" for details. 


$ sudo systemctl status openvpn@client.service 
● openvpn@client.service - OpenVPN connection to client 
Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled; vendor preset: 
enabled) 
Active: failed (Result: exit-code) since Sat 2018-09-08 21:06:04 CEST; 10min 
ago 
Docs: man:openvpn(8) 
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage 
https://community.openvpn.net/openvpn/wiki/HOWTO 
Process: 924 ExecStart=/usr/sbin/openvpn --daemon ovpn-client --status 
/run/openvpn/client.status 10 --cd /etc/openvpn --config 
/etc/openvpn/client.conf --writepid /run/openvpn/client.pid (code=exited, 
status=1/FAILURE) 

Sep 08 21:06:04 debian systemd[1]: Starting OpenVPN connection to client... 
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In [CMD-LINE]:1: Error 
opening configuration file: /etc/openvpn/client.conf 
Sep 08 21:06:04 debian ovpn-client[924]: Use --help for more information. 
Sep 08 21:06:04 debian systemd[1]: openvpn@client.service: Control process 
exited, code=exited status=1 
Sep 08 21:06:04 debian systemd[1]: Failed to start OpenVPN connection to 
client. 
Sep 08 21:06:04 debian systemd[1]: openvpn@client.service: Unit entered failed 
state. 
Sep 08 21:06:04 debian systemd[1]: openvpn@client.service: Failed with result 
'exit-code'. 


CONSTAT INTERESSANT : 
systemd cherche à utiliser /etc/openvpn/client.conf (avec le nom client.conf) 
qui n'existe pas puisque j'ai le fichier de configuration suivant : 
/etc/openvpn/ client /config_openvpn_routed_debian.conf 

Je peux bricoler en copiant mon fichier de configuration client ici avec ce nom 
client.conf (j'ai fait le test : et la commande $ sudo systemctl status 
openvpn@client.service fonctionne ) 
Mais quelles sont les règles à respecter pour utiliser systemd avec OpenVPN ? 


$ sudo journalctl -xe 
Sep 08 21:06:04 debian sudo[921]: truc : TTY=pts/6 ; PWD=/etc/openvpn/client ; 
USER=root ; COMMAND=/bin/systemctl start openvpn@client 
Sep 08 21:06:04 debian sudo[921]: pam_unix(sud

Re: OpenVPN sous Stretch avec systemd

2018-09-08 Par sujet daniel huhardeaux

Le 08/09/2018 à 14:40, roger.tar...@free.fr a écrit :

Salut

Bonjour

Je fais fonctionner sans souci un client OpenVPN sous Jessie.
Manuellement ou automatiquement.

Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de
systemd).
Je peux lancer le client OpenVPN en CLI
$ sudo openvpn client.conf
Et Ctrl-C pour interrompre.

sudo systemctl start openvpn ou openvpn@client pour ne lancer que ce client

En cherchant, j'ai réglé le problème de la façon suivante :
$ cat /etc/default/openvpn
...
AUTOSTART="all"
...
Cette ligne est commentée par défaut.

Puis, comme indiqué dans ce même fichier :

$ sudo systemctl daemon-reload
$ sudo systemctl restart openvpn

Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et
d'hibernation).

Il reste cependant deux problèmes à régler :
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme
la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
Je ne sais pas comment faire ? : oú dois-je chercher ?

systemctl ne joue en rien sur le routage, le problème doit venir d'autre
part

sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient
conformes

sudo ip r pour afficher les routes et vérifier qu'elles soient conformes

2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion
"sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine
de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant
ce temps là, pas de réseau du tout.
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec
systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)

sudo systemctl stop openvpn@client
sudo systemctl start openvpn@client
ou sudo systemctl restart openvpn@client

--
Daniel

OpenVPN sous Stretch avec systemd