Re: Scripter build-key d'EasyRSA/OpenVPN

[didier gaumet]

Y a de la doc sur le site concerné, et probablement que celle-ci est la 
plus adaptée à ton cas pour défricher les options:

https://github.com/OpenVPN/easy-rsa/blob/master/doc/EasyRSA-Advanced.md

Scripter build-key d'EasyRSA/OpenVPN

[Olivier]

Bonjour,

J'ai un serveur sous Stretch sur lequel j'ai installé OpenVPN et
indirectement EasyRSA.

Avec cette version d'EasyRSA, je génère des des clés/certificats avec
les commandes

cd 
. ./vars
;/build-key foobar

Ce qui précède fonctionne bien mais la procédure est interactive.
J'aimerai scripter celle-ci pour l'intégrer dans une procédure plus générale.

J'ai essayé avec ce qui suit mais la commande échoue (je ne me
rappelle plus du message exact).
echo -e -n "\n\n\n\n\n\n\n\n\n\ny\ny\n"|./build-key foobar

J'observe que le script build-key contient simplement:
export EASY_RSA="${EASY_RSA:-.}"
"$EASY_RSA/pkitool" --interact $*

J'imagine qu'en supprimant l'option --interact, on devrait s'approcher
du but mais je n'ai pas trouvé de doc sur pkitool et je suis réticent
à faire beaucoup d'essais sur une machine en production et aussi
ancienne.

Qui pourrait m'aider ?

Slts

Re: systemd service oddness with openvpn

[Richard Hector]

On 12/11/23 04:47, Kamil Jońca wrote:

Richard Hector  writes:


Hi all,

I have a machine that runs as an openvpn server. It works fine; the
VPN stays up.


Are you sure? Have you client conneted and so on?


Yes. I can ssh to the machines at the other end.


However, after running for a while, I get these repeatedly in syslog:

Nov 07 12:17:24 ovpn2 openvpn[213741]: Options error: In [CMD-LINE]:1:
Error opening configuration file: opvn2.conf

Here you have something like typo (opvn2c.conf - I would expect ovpn2.conf)


Bingo - I was confused by the extra c, but that's not what you were 
referring to.


The logrotate postrotate line has

systemctl restart openvpn-server@opvn2

which is the source of the misspelling.

So it's trying to restart the wrong service.

To be honest, I haven't been very happy with the way the services get 
made up on the fly like that, only to fail ... it's bitten me in other 
ways before.


Thank you very much :-)

Richard

Re: systemd service oddness with openvpn

[Kamil Jońca]

Richard Hector  writes:

> Hi all,
>
> I have a machine that runs as an openvpn server. It works fine; the
> VPN stays up.

Are you sure? Have you client conneted and so on?

>
> However, after running for a while, I get these repeatedly in syslog:
>
> Nov 07 12:17:24 ovpn2 openvpn[213741]: Options error: In [CMD-LINE]:1:
> Error opening configuration file: opvn2.conf
Here you have something like typo (opvn2c.conf - I would expect ovpn2.conf)

[..]

>
> Why would it firstly think it needs starting, and secondly fail to do
> so? The config file /etc/openvpn/server/ovpn2.conf file which it

and here you talk about ovpn2.conf

I suspect that your vpn server never starts.
KJ

Re: systemd service oddness with openvpn

[Richard Hector]

On 7/11/23 12:41, Richard Hector wrote:

Hi all,

I have a machine that runs as an openvpn server. It works fine; the VPN 
stays up.


However, after running for a while, I get these repeatedly in syslog:


I don't know if anyone's watching, but ...

It appears that this happens when logrotate restarts openvpn. I just 
have "systemctl restart openvpn-server@ovpn2" in my postrotate section 
in the logrotate config.


I've seen other people recommend using 'copytrucate' instead of 
restarting openvpn, and others suggesting that openvpn should be 
configured to log via syslog, or that it should just log to stdout, and 
init (systemd) can then capture it.


I'm not sure what's the best option here - and I still don't know why 
restarting it causes this failure.


Richard

Re: systemd service oddness with openvpn

[Richard Hector]

On 7/11/23 12:41, Richard Hector wrote:

Hi all,

I have a machine that runs as an openvpn server. It works fine; the VPN 
stays up.


However, after running for a while, I get these repeatedly in syslog:


I should also have mentioned - this is debian bookworm (12.2)

Richard

systemd service oddness with openvpn

[Richard Hector]

Hi all,

I have a machine that runs as an openvpn server. It works fine; the VPN 
stays up.


However, after running for a while, I get these repeatedly in syslog:

Nov 07 12:17:24 ovpn2 openvpn[213741]: Options error: In [CMD-LINE]:1: 
Error opening configuration file: opvn2.conf

Nov 07 12:17:24 ovpn2 openvpn[213741]: Use --help for more information.
Nov 07 12:17:24 ovpn2 systemd[1]: openvpn-server@opvn2.service: Main 
process exited, code=exited, status=1/FAILURE
Nov 07 12:17:24 ovpn2 systemd[1]: openvpn-server@opvn2.service: Failed 
with result 'exit-code'.
Nov 07 12:17:24 ovpn2 systemd[1]: Failed to start 
openvpn-server@opvn2.service - OpenVPN service for opvn2.
Nov 07 12:17:29 ovpn2 openvpn[213770]: Options error: In [CMD-LINE]:1: 
Error opening configuration file: opvn2.conf

Nov 07 12:17:29 ovpn2 openvpn[213770]: Use --help for more information.
Nov 07 12:17:29 ovpn2 systemd[1]: openvpn-server@opvn2.service: Main 
process exited, code=exited, status=1/FAILURE
Nov 07 12:17:29 ovpn2 systemd[1]: openvpn-server@opvn2.service: Failed 
with result 'exit-code'.
Nov 07 12:17:29 ovpn2 systemd[1]: Failed to start 
openvpn-server@opvn2.service - OpenVPN service for opvn2.


This is the openvpn-server@.service:

[Unit]
Description=OpenVPN service for %I
After=network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/server
ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_SYS_CHROOT 
CAP_DAC_OVERRIDE CAP_AUDIT_WRITE

LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process
RestartSec=5s
Restart=on-failure

[Install]
WantedBy=multi-user.target

And this is my override.conf:

[Service]
ExecStart=
ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --config %i.conf


(because I want timestamps)

As I say, the VPN is functioning, and systemctl status shows it's running.

Why would it firstly think it needs starting, and secondly fail to do 
so? The config file /etc/openvpn/server/ovpn2.conf file which it "fails 
to open" hasn't gone away ...


Any tips?

Note the machine is quite low powered; it's an old HP thin client. But 
this is all it does, and it seems to perform adequately.


Thanks,
Richard

Re: Serveur OpenVPN

[BERTRAND Joël]

Trouvé.

C'est l'option comp-lzo qui met le bazar. Je l'avais sur les deux
machines clientes (l'une est sur un accès Wanadoo-Santé de 512 kbps, si,
si, ça existe /encore/), l'autre sur un accès GPRS. Je n'avais pas cette
option côté serveur. Visiblement, jusqu'à la dernière version d'OpenVPN,
le chiffrement asymétrique était autorisé. Là, même en l'autorisant
explicitement, ça ne fonctionnait pas. Donc suppression des deux
comp-lzo sur les clients et ça fonctionne à nouveau.

JKB

Serveur OpenVPN

[BERTRAND Joël]

Bonjour à tous,

J'ai un petit souci avec un serveur OpenVPN (qui fonctionnait
parfaitement jusqu'ici). Les clients se connectent bien sur le serveur
mais rien ne passe sur l'interface tap0. Je n'ai rien de particulier
dans les sorties d'OpenVPN (même avec verb=10).

Le serveur est sur une machine régulièrement mise à jour. Les clients
vivent leur vie et sont mis à jour nettement moins souvent (ça ne dépend
pas de moi).

Lorsque je lance le serveur, je trouve ceci :

2023-08-25 16:58:39 86.212.205.101:58146 TLS: Initial packet from
[AF_INET]86.212.205.101:58146, sid=b28dac4a 65656374
2023-08-25 16:58:40 86.212.205.101:58146 VERIFY OK: depth=1, C=FR,
ST=FR, L=Paris, O=Systella, CN=Systella CA,
emailAddress=joel.bertr...@systella.fr
2023-08-25 16:58:40 86.212.205.101:58146 VERIFY OK: depth=0, C=FR,
ST=FR, L=Paris, O=Systella, CN=cervantes,
emailAddress=joel.bertr...@systella.fr
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_VER=2.4.6
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_PLAT=linux
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_PROTO=2
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_NCP=2
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZ4=1
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZ4v2=1
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZO=1
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_COMP_STUB=1
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_COMP_STUBv2=1
2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_TCPNL=1
2023-08-25 16:58:40 86.212.205.101:58146 TLS: move_session:
dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-08-25 16:58:40 86.212.205.101:58146 TLS: tls_multi_process: initial
untrusted session promoted to trusted
2023-08-25 16:58:40 86.212.205.101:58146 Control Channel: TLSv1.3,
cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA,
signature: RSA-SHA1
2023-08-25 16:58:40 86.212.205.101:58146 [cervantes] Peer Connection
Initiated with [AF_INET]86.212.205.101:58146
2023-08-25 16:58:40 cervantes/86.212.205.101:58146 MULTI_sva: pool
returned IPv4=192.168.2.2, IPv6=(Not enabled)
2023-08-25 16:58:40 cervantes/86.212.205.101:58146 OPTIONS IMPORT:
reading client specific options from: /etc/openvpn/ccd/cervantes
2023-08-25 16:58:41 cervantes/86.212.205.101:58146 Data Channel: cipher
'AES-256-GCM', peer-id: 0
2023-08-25 16:58:41 cervantes/86.212.205.101:58146 Timers: ping 10,
ping-restart 240
2023-08-25 16:58:41 cervantes/86.212.205.101:58146 PUSH: Received
control message: 'PUSH_REQUEST'
2023-08-25 16:58:41 cervantes/86.212.205.101:58146 SENT CONTROL
[cervantes]: 'PUSH_REPLY,route-gateway 192.168.2.1,ping 10,ping-restart
120,ifconfig 192.168.2.5 255.255.255.0,peer-id 1,cipher AES-256-GCM'
(status=1)
2023-08-25 16:58:51 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:58:56 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 16:59:00 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:59:06 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 16:59:10 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:59:17 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 16:59:21 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:59:26 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 16:59:31 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:59:36 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 16:59:41 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:59:46 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 16:59:50 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 16:59:57 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 17:00:00 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 17:00:07 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 17:00:11 cervantes/86.212.205.101:58146 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146
2023-08-25 17:00:17 nietzsche/92.184.124.63:50216 MULTI: Learn:
1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216
2023-08-25 17:00:21 cervantes/

Re: No puedo ejecutar openvpn desde la terminal

[Marcelo Eduardo Giordano]

Gracias estimado.

Quedo en deuda con Ud.

No puedo ejecutar openvpn desde la terminal

[Marcelo Eduardo Giordano]

Estimados:

ejecuto $ openvpn ejemploopenvp.ovpn

y me dice

bash: openvpn: orden no encontrada

Debe ser una tontería pero no se como resolverlo

Gracias

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?

[didier gaumet]

Le lundi 24 juillet 2023 à 08:30:04 UTC+2, Michel Verdier a écrit :

> Je crois que apt purge fonctionne même si le paquet est désinstallé

Je viens de vérifier et tu as parfaitement raison :-)

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?

[Michel Verdier]

Le 23 juillet 2023 didier gaumet a écrit :

> A moins que tu n'aies un besoin bien particulier, l'ordinateur dont tu 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)

Je crois que apt purge fonctionne même si le paquet est désinstallé

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?

[roger . tarani]

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?

[roger . tarani]

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 ...

[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?

[didier gaumet]

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 ...

[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 ...

[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?

[roger . tarani]

- 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?

[roger . tarani]

- 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?

[didier gaumet]

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?

[didier gaumet]

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?

[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?

[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?

[didier gaumet]

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?

[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)

[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)

[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)

[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?

[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?

[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?

[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?

[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?

[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?

[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. 

SOLUCIONADO Re: OFF TOPIC - openvpn en Debian 12 error

[Marcelo Eduardo Giordano]

Gracias estimado. Me funcionó perfecto.

Pero tuve que hacer algunas cosas que yo no sabía:

primero modifiqué el archivo ovpn directamente y no el archivo que 
estaba alojado


/etc/NetworkManager/system-connections/vpn.nmconnection

Saludos

Re: OFF TOPIC - openvpn en Debian 12 error

[Camaleón]

El 2023-06-24 a las 18:09 -0300, Marcelo Eduardo Giordano escribió:

> me sigue saliendo el mismo mensaje de error.

Vaya :-?

¿Te conectas mediante consola o algún componente gráfico?

> Alguna otra alternativa?

Revisa este otro hilo, el error parece bastante común y la solución 
rápida pasa por lo mismo (bajar los requisitos de seguridad), pero 
según se desprende de los que comentan en el hilo, dependiendo de cómo 
te conectes (consola o cliente gráfico) tendrás que configurar el 
parámetro en un archivo o en otro:

Lab Access Openvpn certificate verify failed
https://forum.hackthebox.com/t/lab-access-openvpn-certificate-verify-failed/

Prueba a añadirlo en el archivo que indican y a conectar mediante 
consola, a ver qué sucede.

> Gracias por tan importante ayuda
> 
> 
> openvpn megiordano.ovpn
> 2023-06-24 18:04:56 WARNING: Compression for receiving enabled. Compression
> has been used in the past to break encryption. Sent packets are not
> compressed unless "allow-compression yes" is also set.
> 2023-06-24 18:04:56 Note: --cipher is not set. OpenVPN versions before 2.5
> defaulted to BF-CBC as fallback when cipher negotiation failed in this case.
> If you need this fallback please add '--data-ciphers-fallback BF-CBC' to
> your config
> uration and/or add BF-CBC to --data-ciphers.
> 2023-06-24 18:04:56 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO]
> [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
> 2023-06-24 18:04:56 library versions: OpenSSL 3.0.9 30 May 2023, LZO 2.10
> 2023-06-24 18:04:56 DCO version: N/A
> 2023-06-24 18:04:56 WARNING: No server certificate verification method has
> been enabled.  See http://openvpn.net/howto.html#mitm for more info.
> Enter Private Key Password: 
> 2023-06-24 18:05:58 WARNING: this configuration may cache passwords in
> memory -- use the auth-nocache option to prevent this
> 2023-06-24 18:05:58 TCP/UDP: Preserving recently used remote address:
> [AF_INET]181.13.51.141:1194
> 2023-06-24 18:05:58 UDPv4 link local: (not bound)
> 2023-06-24 18:05:58 UDPv4 link remote: [AF_INET]181.13.51.141:1194
> 2023-06-24 18:05:58 VERIFY ERROR: depth=0, error=CA signature digest
> algorithm too weak: C=AR, ST=MZ, L=Mendoza, O=DIC, CN=server,
> emailAddress=ry...@mendoza.gov.ar, serial=465
> 2023-06-24 18:05:58 OpenSSL: error:0A86:SSL routines::certificate verify
> failed
> 2023-06-24 18:05:58 TLS_ERROR: BIO read tls_read_plaintext error
> 2023-06-24 18:05:58 TLS Error: TLS object -> incoming plaintext read error
> 2023-06-24 18:05:58 TLS Error: TLS handshake failed

Saludos, 

-- 
Camaleón 

Re: OFF TOPIC - openvpn en Debian 12 error

[Camaleón]

El 2023-06-23 a las 15:13 -0300, Marcelo Eduardo Giordano escribió:

> Le agregué
> 
> |tls-cipher=DEFAULT:@SECLEVEL=0|
> 
> 
> al archivo /etc/NetworkManager/system-connections/vpn.nmconnection
> 
> que estaba vacio y no cambió nada.
> 
> alguna otra alternativa?

Prueba a ver si tras reiniciar el sistema te funciona. 

Si sigue igual, revisa los registros nuevamente y mándalos a la lista, 
a ver si hay algún cambio. 

Saludos,

-- 
Camaleón 

Re: OFF TOPIC - openvpn en Debian 12 error

[Marcelo Eduardo Giordano]

Le agregué

|tls-cipher=DEFAULT:@SECLEVEL=0|


al archivo /etc/NetworkManager/system-connections/vpn.nmconnection

que estaba vacio y no cambió nada.

alguna otra alternativa?

Re: OFF TOPIC - openvpn en Debian 12 error

[Camaleón]

El 2023-06-21 a las 16:23 -0300, Marcelo Eduardo Giordano escribió:

> Amigos:
> 
> Usaba debian 11 con una VPN sin ningún problema. Realizo una instalación
> limpia de Debian 12 y ahora me sale esto
> 
> 2023-06-21 09:56:28 WARNING: Compression for receiving enabled. Compression
> has been used in the past to break encryption. Sent packets are not
> compressed unless "allow-compression yes" is also set.
> 2023-06-21 09:56:28 Note: --cipher is not set. OpenVPN versions before 2.5
> defaulted to BF-CBC as fallback when cipher negotiation failed in this case.
> If you need this fallback please add '--data-ciphers-fallback BF-CBC' to
> your config
> uration and/or add BF-CBC to --data-ciphers.
> 2023-06-21 09:56:28 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO]
> [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
> 2023-06-21 09:56:28 library versions: OpenSSL 3.0.9 30 May 2023, LZO 2.10
> 2023-06-21 09:56:28 DCO version: N/A
> 2023-06-21 09:56:28 WARNING: No server certificate verification method has
> been enabled.  See http://openvpn.net/howto.html#mitm for more info.
> Enter Private Key Password: 
> 2023-06-21 09:56:33 WARNING: this configuration may cache passwords in
> memory -- use the auth-nocache option to prevent this
> 2023-06-21 09:56:33 TCP/UDP: Preserving recently used remote address:
> [AF_INET]xx
> 2023-06-21 09:56:33 UDPv4 link local: (not bound)
> 2023-06-21 09:56:33 UDPv4 link remote: [AF_INET] xx

Estos no parecen mensajes de error sino de notificación.

Parece que ha habido algunos cambios desde la versión 2.5, y te avisa 
por si quieres revisar la configuración actual.

> 2023-06-21 09:56:33 VERIFY ERROR: depth=0, error=CA signature digest
> algorithm too weak: C=AR, ST=MZ, L=Mendoza, O=DIC, CN=server,
> emailAddress=, serial=465

Quito la dirección IP y la dirección de correo electrónico por 
privacidad y seguridad. Gente, cuidado con lo que enviáis a la lista.

> 2023-06-21 09:56:33 OpenSSL: error:0A86:SSL routines::certificate verify
> failed
> 2023-06-21 09:56:33 TLS_ERROR: BIO read tls_read_plaintext error
> 2023-06-21 09:56:33 TLS Error: TLS object -> incoming plaintext read error
> 2023-06-21 09:56:33 TLS Error: TLS handshake failed
> 2023-06-21 09:56:33 SIGUSR1[soft,tls-error] received, process restarting
> ^C2023-06-21 09:56:34 SIGINT[hard,init_instance] received, process exiting
> 
> Alguna idea?

Estos mensajes con el certificado sí parecen de error.

A ver... Google tiene varios enlaces que hablan de este problema que 
te aparece en la nueva versión de OpenVPN.

Este creo que te podrá servir:

[SOLVED] OpenVPN - How to allow too weak certificate?
https://bbs.archlinux.org/viewtopic.php?id=281136

Saludos,

-- 
Camaleón 

OFF TOPIC - openvpn en Debian 12 error

[Marcelo Eduardo Giordano]

Amigos:

Usaba debian 11 con una VPN sin ningún problema. Realizo una instalación 
limpia de Debian 12 y ahora me sale esto


2023-06-21 09:56:28 WARNING: Compression for receiving enabled. 
Compression has been used in the past to break encryption. Sent packets 
are not compressed unless "allow-compression yes" is also set.
2023-06-21 09:56:28 Note: --cipher is not set. OpenVPN versions before 
2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in 
this case. If you need this fallback please add '--data-ciphers-fallback 
BF-CBC' to your config

uration and/or add BF-CBC to --data-ciphers.
2023-06-21 09:56:28 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]

2023-06-21 09:56:28 library versions: OpenSSL 3.0.9 30 May 2023, LZO 2.10
2023-06-21 09:56:28 DCO version: N/A
2023-06-21 09:56:28 WARNING: No server certificate verification method 
has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

Enter Private Key Password: 
2023-06-21 09:56:33 WARNING: this configuration may cache passwords in 
memory -- use the auth-nocache option to prevent this
2023-06-21 09:56:33 TCP/UDP: Preserving recently used remote address: 
[AF_INET]181.13.51.141:1194

2023-06-21 09:56:33 UDPv4 link local: (not bound)
2023-06-21 09:56:33 UDPv4 link remote: [AF_INET]181.13.51.141:1194
2023-06-21 09:56:33 VERIFY ERROR: depth=0, error=CA signature digest 
algorithm too weak: C=AR, ST=MZ, L=Mendoza, O=DIC, CN=server, 
emailAddress=ry...@mendoza.gov.ar, serial=465
2023-06-21 09:56:33 OpenSSL: error:0A86:SSL routines::certificate 
verify failed

2023-06-21 09:56:33 TLS_ERROR: BIO read tls_read_plaintext error
2023-06-21 09:56:33 TLS Error: TLS object -> incoming plaintext read error
2023-06-21 09:56:33 TLS Error: TLS handshake failed
2023-06-21 09:56:33 SIGUSR1[soft,tls-error] received, process restarting
^C2023-06-21 09:56:34 SIGINT[hard,init_instance] received, process exiting

Alguna idea?

Re: MTU avec OpenVPN

[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

[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

[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

[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

[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

[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

Re: Certificado gratis para openvpn.

[Luis]

Todo lo que intento es configurar un cliente openvpn, y sin resultados aún. Mi 
conexión no es por cable, con IP real, es más bien compartiendo la conexión de 
datos del móvil mediante zona wifi, de modo que la IP que adquiere debian es 
192.168.43.x, que se la asigna el móvil 樂Sent from my Metro By T-Mobile 4G LTE 
Android Device
 Mensaje original De: Gonzalo Rivero  
Fecha: 26/4/22  7:33 p. m.  (GMT-05:00) A: luiseded...@nauta.cu Asunto: Re: 
Certificado gratis para openvpn. 

El 26/4/22 a las 16:51,
  luiseded...@nauta.cu escribió:

Hola,
  
  
  Es posible obtener algun cerfificado
  
  confiable para usar en openvpn?
  
  

Si estás por hacer tu propia conexión,
también podés generar tus propios certificados. 
  
Como en el fondo no es mas que una
cuestión de confianza, si establecés algún canal seguro para
transmitirlos (por ejemplo, llevarlos vos mismo a la otra
computadora), no tendrías que tener mayores problemas. 
  
Fijate los scripts en el directorio el
paquete extra easyrsa que antes era parte de la distribución de
openvpn

  

  

  
--
Gonzalo Rivero
(-.(-.(-.(-.(-.-).-).-).-).-)
  

Re: Certificado gratis para openvpn.

[Yoel Villarreal]

LetsEncrypt?

En 26 de abril de 2022 3:52:07 p. m. luiseded...@nauta.cu escribió:


Hola,

Es posible obtener algun cerfificado
confiable para usar en openvpn?

Saludos,

Luis Esteban.



Enviado con Aqua Mail para Android
https://www.mobisystems.com/aqua-mail

Certificado gratis para openvpn.

[luisededios]

Hola,

Es posible obtener algun cerfificado
confiable para usar en openvpn?

Saludos,

Luis Esteban.

Re: Manual OpenVPN

[Paynalton]

El jue, 24 mar 2022 a las 1:09, Camaleón () escribió:

> El 2022-03-23 a las 18:14 -0600, Paynalton escribió:
>
> > Hola, alguien sabe donde hay un manual para instalar OpenVPN Server en
> > debian actualizado?
>
> Pues Google devuelve varios, por ejemplo:
>
> Install OpenVPN Server on Debian 11/Debian 10
> https://kifarunix.com/install-openvpn-server-on-debian-11-debian-10/
>
> How To Set Up an OpenVPN Server on Debian 10
>
> https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-debian-10
>
> > He seguido este: https://wiki.debian.org/OpenVPN
> >
> > Pero me da un error porque la versión 2.4 no acepta el parámetro
> data-ciphers,
> > así que no creo que esté actualizado.
> >
> > Estoy usando BullSeye
>
> Hum... la versión de OpenVPN en Debian 11 es la 2.5.1, ¿seguro que tienes
> la 2.4 instalada? :-?
>
> Porque entonces lo que necesitas es un manual para una versión
> anterior de OpenVPN, no uno actualizado.
>
> En cualquier caso, revisa la documentación de OpenVPN, seguro que te
> servirá para resolver el problema, independientemente de la versión que
> tengas instalada:
>
> OpenVPN Cipher Negotiation (Quick reference) ¶
>
> https://community.openvpn.net/openvpn/wiki/CipherNegotiation#Commonconfigurations
>
> Saludos,
>
> --
> Camaleón


Muchas gracias.

Si, estoy usando un EC2 en amazon y, en efecto, es debian 10.
Con esos manuales me ayud{o, muchas gracias.

Re: Manual OpenVPN

[Camaleón]

El 2022-03-23 a las 18:14 -0600, Paynalton escribió:

> Hola, alguien sabe donde hay un manual para instalar OpenVPN Server en
> debian actualizado?

Pues Google devuelve varios, por ejemplo:

Install OpenVPN Server on Debian 11/Debian 10
https://kifarunix.com/install-openvpn-server-on-debian-11-debian-10/

How To Set Up an OpenVPN Server on Debian 10
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-debian-10

> He seguido este: https://wiki.debian.org/OpenVPN
> 
> Pero me da un error porque la versión 2.4 no acepta el parámetro data-ciphers,
> así que no creo que esté actualizado.
> 
> Estoy usando BullSeye

Hum... la versión de OpenVPN en Debian 11 es la 2.5.1, ¿seguro que tienes
la 2.4 instalada? :-?

Porque entonces lo que necesitas es un manual para una versión 
anterior de OpenVPN, no uno actualizado.

En cualquier caso, revisa la documentación de OpenVPN, seguro que te 
servirá para resolver el problema, independientemente de la versión que 
tengas instalada:

OpenVPN Cipher Negotiation (Quick reference) ¶
https://community.openvpn.net/openvpn/wiki/CipherNegotiation#Commonconfigurations

Saludos,

-- 
Camaleón 

Manual OpenVPN

[Paynalton]

Hola, alguien sabe donde hay un manual para instalar OpenVPN Server en
debian actualizado?

He seguido este: https://wiki.debian.org/OpenVPN

Pero me da un error porque la versión 2.4 no acepta el parámetro data-ciphers,
así que no creo que esté actualizado.

Estoy usando BullSeye

Si un ave no rompe su huevo morirá antes de nacer.
Nosotros somos el ave y el mundo es nuestro huevo.
POR LA REVOLUCIÓN DEL MUNDO

Ciudad de México

[RESOLU] Re: Coupures OpenVPN (Inactivity timeout)

[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)

[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)

[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: [Openvpn-users] surf the internet through openvpn

[Joe]

On Sat, 5 Jun 2021 07:59:40 +0200
Stella Ashburne  wrote:

> Hi guys,
> 
> This mailing list is for discussions concerning Debian.
> 
> For discussions on specific topics such as openvpn, please post your
> questions on https://forums.openvpn.net/ or
> https://www.reddit.com/r/OpenVPN/ 
> 
> 

In general, yes, particularly with standalone applications.

But most applications when supplied through a distribution are
customised to some degree, and this is particularly true of networky
things like openvpn. The things that get customised are the fine
details of how the program interacts with the rest of the distribution,
and that is often where people need help, particularly if they are
familiar with a different distribution. Different distributions may
well have different policies about /etc/resolv.conf, for example, a
file often central to vpn issues.

So I'd agree that openvpn forums are the best place to get information
on openvpn, but there may be questions about it that only users of both
Debian and openvpn can answer. If I had recently had doings with
openvpn, I could probably have answered this one, but the last time was
too long ago. Configurations often change between Debian versions. There
are two broad applications of openvpn, either pure point-to-point for
secure remote access or, as in this case, route everything through the
tunnel to place the client effectively within the server's network.
I've always used it for the latter function, and I know that the advice
given so far has been necessary, but I couldn't say from recent
knowledge if it is sufficient.

It does seem likely in this case that the trouble is in the
configuration file. There are many of these around the Net, but it is
likely that most of the Debian-specific tweaks to openvpn affect this
file and a Debian-compatible example is vital. 

It is also possible that someone using a firewall generating
application may need to do something to it, or that may happen
automatically, while someone using raw iptables or nftables will already
know they have to do this themselves. An entirely new kind of interface
appears with openvpn, and the firewall may be written to reject
anything from previously-unknown interfaces. Some firewall issues may be
Debian-dependent as they are also networky things.

-- 
Joe

Re: [Openvpn-users] surf the internet through openvpn

[Stella Ashburne]

Hi guys,

This mailing list is for discussions concerning Debian.

For discussions on specific topics such as openvpn, please post your questions 
on https://forums.openvpn.net/ or https://www.reddit.com/r/OpenVPN/
 


Sent: Saturday, June 05, 2021 at 7:04 AM
From: "Bonno Bloksma" 
To: "debian-user list" 
Cc: "Fermin Francisco" 
Subject: Re: [Openvpn-users] surf the internet through openvpn

Please keep the discussion on the list.
And sorry for top posting, this client refuses todo otherwise :-(
 
Make sure traffic coming from the openvpn client can indeed access the 
internet, test with ping.  If that does not work solve that problem first. Look 
at routing and NAT on your openvpn server.
 
Once that works try what happens with a browser, go to whatismyip.com or a 
similar website. The client ip the website sees should the ip of your openvpn 
server.
If ping works but http(s) does not you probably have a firewall issue.
 
If that works then SMTP should work as well as long as the receiving server has 
no problem with the discrepency in the ip number, hostname and PTR record.
 

Bonno Bloksma (mobile)
 
 Op 4 jun. 2021 om 22:01 heeft Fermin Francisco  het volgende 
geschreven:
 


Hi!
My problems are two:
 
After I putted the push "redirect-gateway local def1" in server conf file.
 
1. OpenVPN Linux's clients can't surf into the internet (Windows clients can 
surf into the internet), but can connect to remote software.
2. SMTP cannot worked (Thunderbird).
 
 
Sorry, my english is not good.
 
 
José Fermín Francisco Ferreras Registered User #579535 (LinuxCounter.net)
 
 

El viernes, 4 de junio de 2021 02:05:40 a. m. AST, Bonno Bloksma 
 escribió:
 
 

Hello

> How can I make openvpn clients (Linux clients) surf the internet through 
> openvpn using the public ip of the openvpn server

The client config should contain the line
redirect-gateway local def1

This will let OpenVpn add some lines to you routing table that make sure that:
- your client can still reach the OpenVPN server via the normal internet 
connection.
- All other traffic will leave the client via the openVPN tunnel.

Make sure the routing on your openVPN server and your firewall are set up 
correctly.

>(the openvpn server is on Windows)? And also that emails using Thunderbird can 
>work with this method (that emails can enter and leave without problems).
This is just routing via another node, it has no influence on the protocol as 
the client still initiates all traffic sessions.

Ps. If you want you can push the line from the servers if you want to have it 
configures on all clients.

Bonno Bloksma
 

Re: [Openvpn-users] surf the internet through openvpn

[Bonno Bloksma]

Please keep the discussion on the list.
And sorry for top posting, this client refuses todo otherwise :-(

Make sure traffic coming from the openvpn client can indeed access the 
internet, test with ping.  If that does not work solve that problem first. Look 
at routing and NAT on your openvpn server.

Once that works try what happens with a browser, go to whatismyip.com or a 
similar website. The client ip the website sees should the ip of your openvpn 
server.
If ping works but http(s) does not you probably have a firewall issue.

If that works then SMTP should work as well as long as the receiving server has 
no problem with the discrepency in the ip number, hostname and PTR record.

Bonno Bloksma (mobile)


Op 4 jun. 2021 om 22:01 heeft Fermin Francisco  het volgende 
geschreven:


Hi!
My problems are two:

After I putted the push "redirect-gateway local def1" in server conf file.

1. OpenVPN Linux's clients can't surf into the internet (Windows clients can 
surf into the internet), but can connect to remote software.
2. SMTP cannot worked (Thunderbird).


Sorry, my english is not good.



José Fermín Francisco Ferreras Registered User #579535 (LinuxCounter.net)


El viernes, 4 de junio de 2021 02:05:40 a. m. AST, Bonno Bloksma 
 escribió:


Hello

> How can I make openvpn clients (Linux clients) surf the internet through 
> openvpn using the public ip of the openvpn server

The client config should contain the line
redirect-gateway local def1

This will let OpenVpn add some lines to you routing table that make sure that:
- your client can still reach the OpenVPN server via the normal internet 
connection.
- All other traffic will leave the client via the openVPN tunnel.

Make sure the routing on your openVPN server and your firewall are set up 
correctly.


>(the openvpn server is on Windows)? And also that emails using Thunderbird can 
>work with this method (that emails can enter and leave without problems).

This is just routing via another node, it has no influence on the protocol as 
the client still initiates all traffic sessions.

Ps. If you want you can push the line from the servers if you want to have it 
configures on all clients.

Bonno Bloksma

Re: Openvpn 2fa google

[Gokan Atmaca]

the error is as follows.  Verification code is correct.

-% error:
openvpn(pam_google_authenticator)[16239]: Invalid verification code for usi21

On Wed, Jun 2, 2021 at 10:58 PM Gokan Atmaca  wrote:
>
> Hello
>
> I use Google for 2FA. My configuration is as follows. However, I could
> not log in. Stn. When I configure it with TLS I am able to login. But
> unfortunately it doesn't work when I add 2fa. What could be the
> problem ?
>
> -% error:
> TLS Auth Error: Auth Username/Password verification failed for peer
>
> -% Pam_config:
> auth required /usr/lib/x86_64-linux-gnu/security/pam_google_authenticator.so
> secret=/etc/openvpn/google-authenticator/${USER} forward_pass
> accountrequired pam_permit.so
>
> -% usr_create:
> sudo su -c "google-authenticator -t -d -r3 -R30 -f -l \"My VPN\" -s
> /etc/openvpn/google-authenticator/client2981" - gauth
>
>
>
> Thanks.
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄

Openvpn 2fa google

[Gokan Atmaca]

Hello

I use Google for 2FA. My configuration is as follows. However, I could
not log in. Stn. When I configure it with TLS I am able to login. But
unfortunately it doesn't work when I add 2fa. What could be the
problem ?

-% error:
TLS Auth Error: Auth Username/Password verification failed for peer

-% Pam_config:
auth required /usr/lib/x86_64-linux-gnu/security/pam_google_authenticator.so
secret=/etc/openvpn/google-authenticator/${USER} forward_pass
accountrequired pam_permit.so

-% usr_create:
sudo su -c "google-authenticator -t -d -r3 -R30 -f -l \"My VPN\" -s
/etc/openvpn/google-authenticator/client2981" - gauth



Thanks.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: OpenVpn Mac Address Filter

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-02 8:45 a.m., Gokan Atmaca wrote:
> Hello
> 
> There I am trying to compile openvpn. I am getting an error as below.
> 
> What can be the problem ?
> 
> -% error:
> /usr/bin/install: cannot stat './openvpn.8': No such file or directory
> make[4]: *** [Makefile:515: install-man8] Error 1
> make[4]: Leaving directory '/root/openvpn/doc'
> make[3]: *** [Makefile:773: install-am] Error 2
> make[3]: Leaving directory '/root/openvpn/doc'
> make[2]: *** [Makefile:606: install-recursive] Error 1
> make[2]: Leaving directory '/root/openvpn/doc'
> make[1]: *** [Makefile:615: install-recursive] Error 1
> make[1]: Leaving directory '/root/openvpn'
> make: *** [Makefile:915: install] Error 2
> 

Maybe you could get more help...
But please give more information...

What version ?
Are you compiling from the upstream source code (author) ?
Are you compiling from a debian source code package ?
What platform are you using ?

Give as much information you can so we can try to reproduce what you are
trying. This way we'll be able to solve this problem.

I presume you are using a debian source code package (DSC) ?
Are you compiling the stable ? the unstable ? testing ?

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: OpenVpn Mac Address Filter

[Gokan Atmaca]

Hello

There I am trying to compile openvpn. I am getting an error as below.

What can be the problem ?

-% error:
/usr/bin/install: cannot stat './openvpn.8': No such file or directory
make[4]: *** [Makefile:515: install-man8] Error 1
make[4]: Leaving directory '/root/openvpn/doc'
make[3]: *** [Makefile:773: install-am] Error 2
make[3]: Leaving directory '/root/openvpn/doc'
make[2]: *** [Makefile:606: install-recursive] Error 1
make[2]: Leaving directory '/root/openvpn/doc'
make[1]: *** [Makefile:615: install-recursive] Error 1
make[1]: Leaving directory '/root/openvpn'
make: *** [Makefile:915: install] Error 2

On Mon, May 31, 2021 at 12:18 PM Gokan Atmaca  wrote:
>
> > Mac address is available only on the local network. You usually do not
> > get the mac address of the openvpn client but the mac address of nic of
> > the last router facing your openvpn server.
>
> You are right. I will try Google 2fa.
>
>
>
> On Sat, May 29, 2021 at 9:57 PM Erwan David  wrote:
> >
> > Le 29/05/2021 à 20:09, Gokan Atmaca a écrit :
> > > Hello
> > >
> > > Can we filter MAC addresses of Openvpn clients ?
> > >
> > > Thanks.
> > >
> > >
> > >
> > Mac address is available only on the local network. You usually do not
> > get the mac address of the openvpn client but the mac address of nic of
> > the last router facing your openvpn server.
> >

Re: OpenVpn Mac Address Filter

[Gokan Atmaca]

> Mac address is available only on the local network. You usually do not
> get the mac address of the openvpn client but the mac address of nic of
> the last router facing your openvpn server.

You are right. I will try Google 2fa.



On Sat, May 29, 2021 at 9:57 PM Erwan David  wrote:
>
> Le 29/05/2021 à 20:09, Gokan Atmaca a écrit :
> > Hello
> >
> > Can we filter MAC addresses of Openvpn clients ?
> >
> > Thanks.
> >
> >
> >
> Mac address is available only on the local network. You usually do not
> get the mac address of the openvpn client but the mac address of nic of
> the last router facing your openvpn server.
>

Re: OpenVpn Mac Address Filter

[Erwan David]

Le 29/05/2021 à 20:09, Gokan Atmaca a écrit :
> Hello
>
> Can we filter MAC addresses of Openvpn clients ?
>
> Thanks.
>
>
>
Mac address is available only on the local network. You usually do not
get the mac address of the openvpn client but the mac address of nic of
the last router facing your openvpn server.

OpenVpn Mac Address Filter

[Gokan Atmaca]

Hello

Can we filter MAC addresses of Openvpn clients ?

Thanks.



-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Multicasting entre oficinas con OpenVPN

[Eugenio Muñoz Doyague]

Es factible, pero te recomiendo wireguard para lo que quieres hacer Es muy
sencillo de configurar.

El dom., 23 may. 2021 13:03, Roberto Leon Lopez 
escribió:

> Buenos días, estoy a modo de piloto planteando la cuestión de conectar dos
> oficinas con OpenVPN en modo Site to Site, es decir que se ven en la misma
> subred.
>
> En las dos oficinas contamos con un switch con IGMP Snooping activado. Y
> por las lecturas que he hecho veo necesario usar un enrutador de mensajes
> multicast con pimd para que dichos mensajes multicasting de un switch y
> otro se vean. Una oficina envía un stream a un grupo multicasting y en la
> otra oficina están los mensajes de los que quieren unirse al grupo para
> leer el stream. Una oficina envía y la otra lo recibe.
>
> ¿Es factible el planteamiento que he expuesto? ¿Hay otras soluciones
> mejores?
>

Multicasting entre oficinas con OpenVPN

[Roberto Leon Lopez]

Buenos días, estoy a modo de piloto planteando la cuestión de conectar dos 
oficinas con OpenVPN en modo Site to Site, es decir que se ven en la misma 
subred. 

En las dos oficinas contamos con un switch con IGMP Snooping activado. Y por 
las lecturas que he hecho veo necesario usar un enrutador de mensajes multicast 
con pimd para que dichos mensajes multicasting de un switch y otro se vean. Una 
oficina envía un stream a un grupo multicasting y en la otra oficina están los 
mensajes de los que quieren unirse al grupo para leer el stream. Una oficina 
envía y la otra lo recibe.

¿Es factible el planteamiento que he expuesto? ¿Hay otras soluciones mejores?

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 16:41:17 +0100
Paul van der Vlis  wrote:

> Jawel, Networkmanager doet dat.
> 
> > Vandaar dat ik er
> > een link van zou maken die naar een andere dir wijst.
> 
> Het overschrijft dan het file in die ander dir lijkt me.

Of hij zet een file neer ipv die symlink

> > Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel
> > met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets
> > verwacht-ie natuurlijk niet...
> 
> Inderdaad, dat ding bedoel ik. Gebruik ik normaal alleen op laptops,
> maar die Freedombox-software gebruikt het nogal intensief dus vandaar.
> 
> En nee, het crashed niet, geeft zelfs geen melding in de logs dat
> schrijven niet kan.

Tsja...

> Ik vond dit overigens nog:
> https://github.com/wknapik/vpnfailsafe

Ja, ik zou dan toch liever m'n eigen scripts gebruiken en policy routing
gebruiken, dan hoef je niet zo moeilijk te doen. Zodra de
tunnel opkomt gewoon een andere routetabel kiezen en die heeft z'n
eigen [ip|nf]tables scripts. Overigens draait openvpn bij hen wel als
root, ik ben daar niet zo'n voorstander van.

Misschien is het handig het eindpunt van de tunnel in /etc/hosts te
zetten, als de DNS het een keer om wat voor reden het niet doet kun je
wel een tunnel opbouwen.

Maar waarom draai je niet unbound die direct de rootservers benadert?
Zo vindt de provider het niet in de logs van de DNS, maar met een dump
kun je altijd zien wat er gevraagd wordt, maar dat zie je aan het eind
van de tunnel ook. Dus wat win je ermee?

Overigens is dat ge-VPN ook maar een hype. Mensen denken dat ze veilig
zitten. Maar wie garandeert dat? Zonder vpn ziet je provider het, met
een vpn ziet de vpn aanbieder het. Een vpn is niets meer dan een
virtueel stuk draad die je ergens in een switch steekt.

Als je iets wilt uitvreten gebruik dan Tor. En dan nog.

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 26-02-2020 om 14:07 schreef Richard Lucassen:
> On Wed, 26 Feb 2020 13:35:55 +0100
> Paul van der Vlis  wrote:
> 
>>>>> Dat is wel erg bot. 
>>
>> Het is bot, maar geeft niet eens een foutmelding in de logs.
>> En wat is er erg aan bot?
> 
> Nou, zelfs root krijgt dan een permission denied, en als resolvconf
> verwijderd is zou niemand er meer aan mogen zitten. 

Jawel, Networkmanager doet dat.

> Vandaar dat ik er
> een link van zou maken die naar een andere dir wijst.

Het overschrijft dan het file in die ander dir lijkt me.

>>> ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf
>>
>> Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het
>> zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In
>> de praktijk doet hij dat niet, maar als de andere uitvalt wel.
> 
> Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel
> met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets
> verwacht-ie natuurlijk niet...

Inderdaad, dat ding bedoel ik. Gebruik ik normaal alleen op laptops,
maar die Freedombox-software gebruikt het nogal intensief dus vandaar.

En nee, het crashed niet, geeft zelfs geen melding in de logs dat
schrijven niet kan.

>>> Ja ok, het gaat dus niet om security maar om het verbergen van
>>> illegale activiteiten :-)
>>
>> Een vertrouwde DNS server willen gebruiken is ook security.
> 
> Maar ook van die resolver kun je volgen wat-ie opvraagt...
> 
>> Er zijn vele mensen die een VPN willen gebruiken om verschillende
>> redenen, en dat DNS-leak ergerde mij.  In de GUI clients schijnt het
>> opgelost, maar op de commandline gaat het niet goed.
> 
> Huh? Dat lijkt me onlogisch. Of heeft Poettering weer iets "gefixt"?

Goed mogelijk...

Ik vond dit overigens nog:
https://github.com/wknapik/vpnfailsafe

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 13:35:55 +0100
Paul van der Vlis  wrote:

> >>> Dat is wel erg bot. 
> 
> Het is bot, maar geeft niet eens een foutmelding in de logs.
> En wat is er erg aan bot?

Nou, zelfs root krijgt dan een permission denied, en als resolvconf
verwijderd is zou niemand er meer aan mogen zitten. Vandaar dat ik er
een link van zou maken die naar een andere dir wijst.

> > ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf
> 
> Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het
> zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In
> de praktijk doet hij dat niet, maar als de andere uitvalt wel.

Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel
met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets
verwacht-ie natuurlijk niet...

> > Ja ok, het gaat dus niet om security maar om het verbergen van
> > illegale activiteiten :-)
> 
> Een vertrouwde DNS server willen gebruiken is ook security.

Maar ook van die resolver kun je volgen wat-ie opvraagt...

> Er zijn vele mensen die een VPN willen gebruiken om verschillende
> redenen, en dat DNS-leak ergerde mij.  In de GUI clients schijnt het
> opgelost, maar op de commandline gaat het niet goed.

Huh? Dat lijkt me onlogisch. Of heeft Poettering weer iets "gefixt"?

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 26-02-2020 om 13:18 schreef Richard Lucassen:
> On Wed, 26 Feb 2020 12:11:37 +0100
> Paul van der Vlis  wrote:
> 
>>> Dat is wel erg bot. 

Het is bot, maar geeft niet eens een foutmelding in de logs.
En wat is er erg aan bot?

> Je kunt openvpn ook de resolv.conf laten
>>> aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb
>>> je sudo voor nodig.
>>
>> Heb je daar een mooi scriptje voor?
> 
> Nee, ik gebruik die optie nooit, alhoewel ja, om routes toe te voegen of
> policy routing aan te sturen, maar dat hoeft alleen maar bij het "up"
> komen van het device want als het device verdwijnt ruimt de kernel de
> bijbehorende routes op.
> 
> In de config:
> 
> up /path/to/script start
> down /path/to/script stop
> 
> Het "up" script draait als "root", maar bij "down" moet je wel sudo
> gebruiken omdat de tunnel default dan onder de user nobody draait (ik
> zou daar een aparte user voor nemen iig)
> 
> Je zou simpelweg een
> 
> /etc/openvpn/resolv/resolv-ovpn.conf
> /etc/openvpn/resolv/resolv-default.conf
> 
> kunnen aanmaken en daar in die specifieke dir /etc/openvpn/resolv (die
> writable is voor de user openvpn) een "ln -sf  resolv.conf" op
> kunnen loslaten door dat script dat openvpn aanstuurt. En dan maak
> je als root in de /etc/ dir een link naar
> 
> ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf

Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het
zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In de
praktijk doet hij dat niet, maar als de andere uitvalt wel.

>>> En je vertrouwt de DNS aan de andere kant van de tunnel wel?
>>
>> Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst
>> naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat
>> rechtsstreeks bij de root-servers navraagt.
> 
> Ik zou unbound gebruiken, dat is een recursive only resolver. Maar dat
> terzijde.
> 
>>> Verplaats je niet gewoon het probleem?
>>
>> Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier
>> kan de ISP niet meer zien wat voor naam je resolved.
>>
>> En als er een andere nameserver gebruikt zou worden dan ziet die ook
>> alleen het IP van de VPN.
> 
> Ja ok, het gaat dus niet om security maar om het verbergen van illegale
> activiteiten :-)

Een vertrouwde DNS server willen gebruiken is ook security.

Er zijn vele mensen die een VPN willen gebruiken om verschillende
redenen, en dat DNS-leak ergerde mij.  In de GUI clients schijnt het
opgelost, maar op de commandline gaat het niet goed.

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 12:11:37 +0100
Paul van der Vlis  wrote:

> > Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten
> > aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb
> > je sudo voor nodig.
> 
> Heb je daar een mooi scriptje voor?

Nee, ik gebruik die optie nooit, alhoewel ja, om routes toe te voegen of
policy routing aan te sturen, maar dat hoeft alleen maar bij het "up"
komen van het device want als het device verdwijnt ruimt de kernel de
bijbehorende routes op.

In de config:

up /path/to/script start
down /path/to/script stop

Het "up" script draait als "root", maar bij "down" moet je wel sudo
gebruiken omdat de tunnel default dan onder de user nobody draait (ik
zou daar een aparte user voor nemen iig)

Je zou simpelweg een

/etc/openvpn/resolv/resolv-ovpn.conf
/etc/openvpn/resolv/resolv-default.conf

kunnen aanmaken en daar in die specifieke dir /etc/openvpn/resolv (die
writable is voor de user openvpn) een "ln -sf  resolv.conf" op
kunnen loslaten door dat script dat openvpn aanstuurt. En dan maak
je als root in de /etc/ dir een link naar

ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf

> > En je vertrouwt de DNS aan de andere kant van de tunnel wel?
> 
> Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst
> naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat
> rechtsstreeks bij de root-servers navraagt.

Ik zou unbound gebruiken, dat is een recursive only resolver. Maar dat
terzijde.

> > Verplaats je niet gewoon het probleem?
> 
> Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier
> kan de ISP niet meer zien wat voor naam je resolved.
> 
> En als er een andere nameserver gebruikt zou worden dan ziet die ook
> alleen het IP van de VPN.

Ja ok, het gaat dus niet om security maar om het verbergen van illegale
activiteiten :-)

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 26-02-2020 om 11:39 schreef Richard Lucassen:
> On Wed, 26 Feb 2020 11:27:18 +0100
> Paul van der Vlis  wrote:
> 
>> Wat ik uiteindelijk maar heb gedaan is het volgende:
>> Ik heb resolvconf verwijderd.
>> Ik heb /etc/resolv.conf niet te wijzigen gemaakt met:
>> chattr +i /etc/resolv.conf
> 
> Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten aanpassen,
> up is niet zo'n probleem (dan is-ie nog root), down heb je sudo voor
> nodig.

Heb je daar een mooi scriptje voor?

>> Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal
>> wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver.
>>
>> Geen DNS leakage meer volgens https://www.dnsleaktest.com/ .
> 
> En je vertrouwt de DNS aan de andere kant van de tunnel wel?

Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst
naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat
rechtsstreeks bij de root-servers navraagt.

> Verplaats je niet gewoon het probleem?

Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier
kan de ISP niet meer zien wat voor naam je resolved.

En als er een andere nameserver gebruikt zou worden dan ziet die ook
alleen het IP van de VPN.

Groeten,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 11:27:18 +0100
Paul van der Vlis  wrote:

> Wat ik uiteindelijk maar heb gedaan is het volgende:
> Ik heb resolvconf verwijderd.
> Ik heb /etc/resolv.conf niet te wijzigen gemaakt met:
> chattr +i /etc/resolv.conf

Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten aanpassen,
up is niet zo'n probleem (dan is-ie nog root), down heb je sudo voor
nodig.

> Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal
> wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver.
> 
> Geen DNS leakage meer volgens https://www.dnsleaktest.com/ .

En je vertrouwt de DNS aan de andere kant van de tunnel wel? Verplaats
je niet gewoon het probleem?

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 24-02-2020 om 18:50 schreef Paul van der Vlis:
> Hoi,
> 
> Ik probeer OpenVPN zo op te zetten dat er geen "dns leakage" is.
> 
> Als ik de VPN start dan wordt netjes de dns gewijzigd in
> /etc/resolv.conf door update-resolv-conf. Echter, er wordt hier alleen
> een DNS toegevoegd, de oude is er ook nog. Ik wil dat alleen de DNS
> wordt gebruikt die door OpenVPN wordt gepushed.
> 
> Heeft iemand hier een mooie CLI oplossing voor?
> 
> Het gaat om een Freedombox, dit gebruikt networkmanager en firewalld.
> Ik heb "resolvconf" geinstalleerd om update-resolv-conf werkend te
> krijgen, dit was niet standaard geinstalleerd.

Wat ik uiteindelijk maar heb gedaan is het volgende:
Ik heb resolvconf verwijderd.
Ik heb /etc/resolv.conf niet te wijzigen gemaakt met:
chattr +i /etc/resolv.conf

Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal wat
ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver.

Geen DNS leakage meer volgens https://www.dnsleaktest.com/ .

Groet,
Paul

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

OpenVPN en "dns leakage"

[Paul van der Vlis]

Hoi,

Ik probeer OpenVPN zo op te zetten dat er geen "dns leakage" is.

Als ik de VPN start dan wordt netjes de dns gewijzigd in
/etc/resolv.conf door update-resolv-conf. Echter, er wordt hier alleen
een DNS toegevoegd, de oude is er ook nog. Ik wil dat alleen de DNS
wordt gebruikt die door OpenVPN wordt gepushed.

Heeft iemand hier een mooie CLI oplossing voor?

Het gaat om een Freedombox, dit gebruikt networkmanager en firewalld.
Ik heb "resolvconf" geinstalleerd om update-resolv-conf werkend te
krijgen, dit was niet standaard geinstalleerd.

Ik vond hier wel wat informatie, maar geen bruikbare oplossing:
https://wiki.archlinux.org/index.php/OpenVPN#DNS

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

network-manager-openvpn GUI not keeping automatic VPN connection setting

[Jape Person]

I hope that subject line doesn't obfuscate the issue.

I'm using Sid/testing with Xfce4 desktop environment, fully updated.

openvpn 2.4.7-1
network-manager-openvpn 1.8.10-1
network-manager-openvpn-gnome 1.8.10-1

Using the GUI I set openvpn to connect automatically to a chosen VPN. I 
reboot. I do connect to the vpn I selected. However, an examination of 
the openvpn setting in the GUI indicates a different VPN locale. 
Subsequent reboots still connect me to the VPN I chose, but the 
indicator in the GUI still indicates that I have chosen a different VPN.


For instance, I just selected the Atlanta, GA VPN in the interface, 
rebooted, logged in, and checked which VPN I was connected to. I'm 
connected to the Atlanta VPN, but the settings GUI says Finland!


Not a serious problem, but an odd one, to say the least.

I have no idea whether or not the following message which occurs at boot 
time is related in some way:


[FAILED] Failed to start OpenVPN connection to update-systemd-resolved.
See 'systemctl status openvpn@update-systemd-resolved.service' for details.

Issuing the indicated command yields:

● openvpn@update-systemd-resolved.service - OpenVPN connection to 
update-systemd-resolved
   Loaded: loaded (/lib/systemd/system/openvpn@.service; 
enabled-runtime; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 
2019-11-05 15:17:58 EST; 1s ago

 Docs: man:openvpn(8)
   https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
   https://community.openvpn.net/openvpn/wiki/HOWTO
  Process: 4314 ExecStart=/usr/sbin/openvpn --daemon 
ovpn-update-systemd-resolved --status 
/run/openvpn/update-systemd-resolved.status 10 --cd /etc/openvpn 
--config /etc/ope>

 Main PID: 4314 (code=exited, status=1/FAILURE)

Please excuse short wrap length. Since recent Thunderbird upgrade the 
client seems unable to write longer lines. Haven't looked into it, yet. 
Quite annoying, but a subject for another thread.


Thanks!

Re: openvpn-systemd-resolved vs gui

[Andrea Borgia]

Il 02/09/19 19:52, john doe ha scritto:


Those messages are error messages, if I were you I would put the missing
file 'scripts/update-systemd-resolved' in the directory
'/etc/openvpn/scripts' or look in your openvpn config file for the '--up
script' directive.


They sure behave like warnings, though: the bulk of traffic goes through 
the vpn interface ;)


Anyhow, given the sheer amount of those errors it looks like I've been 
bitten by this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933987


I moved the script from /etc/openvpn to /etc/openvpn/scripts and now I 
get a different error:
ovpn-update-systemd-resolved[6820]: disabling NCP mode (--ncp-disable) 
because not in P2MP client or server mode


Next, I saw the dependency from openvpn was just "Suggest" so I removed 
it altogether and now there are no errors. I will note in the system log 
this thread and for the moment I'll leave it at that.


Thanks for your help.

Re: openvpn-systemd-resolved vs gui

[john doe]

On 9/2/2019 7:08 PM, Andrea Borgia wrote:
> Il 01/09/19 19:09, john doe ha scritto:
>
>
>
>>> After seeing some warnings in the system logs, I decided to
>>> investigate and
>> It would help if we could see those warnings as well.
>
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Service RestartSec=5s expired,
> scheduling restart.
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Scheduled restart job, restart
> counter is at 266.
> Sep  2 16:59:40 clarisse systemd[1]: Stopped OpenVPN connection to
> update-systemd-resolved.
> Sep  2 16:59:40 clarisse systemd[1]: Starting OpenVPN connection to
> update-systemd-resolved...
> Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
> error: --up script fails with
> '/etc/openvpn/scripts/update-systemd-resolved': No such file or
> directory (errno=2)
> Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
> error: Please correct this error.
> Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Use --help
> for more information.
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Main process exited,
> code=exited, status=1/FAILURE
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Failed with result 'exit-code'.
> Sep  2 16:59:40 clarisse systemd[1]: Failed to start OpenVPN connection
> to update-systemd-resolved.
>
>
>
>>> found out that I am supposed to enable this script to integrate the dns
>> Which script are you refering to?
>
> In package openvpn-systemd-resolved, there is a config file which also
> installed under /etc/openvpn. This config references a script to be
> installed as /etc/openvpn/scripts/update-systemd-resolved
>
>
>
>>> Do I really have to do it if I am not worried about dns leaks? I'm
>>> actually
>>> ok with using whatever server the local network has, as long as the
>>> traffic
>>> itself is encrypted I'm fine.
>> If you are happy with how things are working, that is up to you to
>> ignore the warnings.
>> In my view, warnings are to be dealt with! :)
>
> Once I am sure I understand the implications, ignoring them is not a bad
> idea. That said, my main concern was integrating the config with the n-m
> gui... now that I think about it, the warnings are proof that this is a
> non-issue :)
>
>

From your logs above:

"Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
error: --up script fails with
'/etc/openvpn/scripts/update-systemd-resolved': No such file or
directory (errno=2)
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
error: Please correct this error."


Those messages are error messages, if I were you I would put the missing
file 'scripts/update-systemd-resolved' in the directory
'/etc/openvpn/scripts' or look in your openvpn config file for the '--up
script' directive.

--
John Doe

Re: openvpn-systemd-resolved vs gui

[Andrea Borgia]

Il 01/09/19 19:09, john doe ha scritto:




After seeing some warnings in the system logs, I decided to investigate and

It would help if we could see those warnings as well.


Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Service RestartSec=5s expired, 
scheduling restart.
Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Scheduled restart job, restart 
counter is at 266.
Sep  2 16:59:40 clarisse systemd[1]: Stopped OpenVPN connection to 
update-systemd-resolved.
Sep  2 16:59:40 clarisse systemd[1]: Starting OpenVPN connection to 
update-systemd-resolved...
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options 
error: --up script fails with 
'/etc/openvpn/scripts/update-systemd-resolved': No such file or 
directory (errno=2)
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options 
error: Please correct this error.
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Use --help 
for more information.
Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Main process exited, 
code=exited, status=1/FAILURE
Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Failed with result 'exit-code'.
Sep  2 16:59:40 clarisse systemd[1]: Failed to start OpenVPN connection 
to update-systemd-resolved.





found out that I am supposed to enable this script to integrate the dns

Which script are you refering to?


In package openvpn-systemd-resolved, there is a config file which also 
installed under /etc/openvpn. This config references a script to be 
installed as /etc/openvpn/scripts/update-systemd-resolved





Do I really have to do it if I am not worried about dns leaks? I'm actually
ok with using whatever server the local network has, as long as the traffic
itself is encrypted I'm fine.

If you are happy with how things are working, that is up to you to
ignore the warnings.
In my view, warnings are to be dealt with! :)


Once I am sure I understand the implications, ignoring them is not a bad 
idea. That said, my main concern was integrating the config with the n-m 
gui... now that I think about it, the warnings are proof that this is a 
non-issue :)



Thanks,
Andrea.

Re: openvpn-systemd-resolved vs gui

[john doe]

On 9/1/2019 6:33 PM, Andrea Borgia wrote:
> Hi.
>
> After seeing some warnings in the system logs, I decided to investigate and

It would help if we could see those warnings as well.

> found out that I am supposed to enable this script to integrate the dns

Which script are you refering to?

> information supplied from the server into the local configuration.
>
> Do I really have to do it if I am not worried about dns leaks? I'm actually
> ok with using whatever server the local network has, as long as the traffic
> itself is encrypted I'm fine.
>

If you are happy with how things are working, that is up to you to
ignore the warnings.
In my view, warnings are to be dealt with! :)

--
John Doe

openvpn-systemd-resolved vs gui

[Andrea Borgia]

Hi.

After seeing some warnings in the system logs, I decided to investigate and
found out that I am supposed to enable this script to integrate the dns
information supplied from the server into the local configuration.

Do I really have to do it if I am not worried about dns leaks? I'm actually
ok with using whatever server the local network has, as long as the traffic
itself is encrypted I'm fine.

If yes, how do I enable it from the network-manager applet?

Thanks,
Andrea.