Sommaire
Comme d'autres, j'ai découverts ces derniers temps les joies du travail à distance.
Pour cela toujours dans l'originalité nous utilisons vpnc. J'ai déjà utilisé ce vpn quand j'étais à la fac, pas de problème particulier pour une utilisation de base. Néanmoins, j'ai mis en place quelques astuces pour rendre l'usage plus agréable pour moi et c'est ce que je vais décrire ici.
Rien d'incroyable, mais si ça peut aider quelqu'un c'est toujours ça.
Le DNS : dnsmasq
C'est le plus important. vpnc quand il s'active modifie vos DNS (dans /etc/resolv.conf
). C'est logique si le réseau auquel vous tentez d'accéder gère lui-même ses domaines, mais ça pose des soucis :
- vous ne voulais pas forcément que toutes vos requêtes DNS transitent par le DNS de votre entreprise. Si vous oubliez d'arrêter votre client VPN (entre midi et 2 ou le soir par exemple), vous pouvez ne pas vouloir que votre employeur sache sur quels sites vous allez
- on peut imaginer que les DNS de votre entreprise fassent du filtrage
- plus prosaïquement, ces DNS sont loin, le réseau peut ne pas être très bon et avoir tout son trafic ralentit parce que la connexion avec le réseau de votre entreprise a des problèmes c'est dommage et assez frustrant
La solution la plus simple est d'utiliser dnsmasq
. C'est un serveur DNS1 qui est fait soit pour être utilisé au sein d'un réseau privé soit directement sur votre machine (pour un usage sur internet on privilégiera bind
par exemple).
L'objectif est simple : il va nous servir de proxy :
- les requêtes concernant un domaine de votre entreprise vont vers les DNS de votre entreprise (ceux qui sont configurés par le VPN)
- les autres vont vers le DNS que vous souhaitez (celui de votre FAI ou autre)
Pour faire tout ça c'est simple :
apt install dnsmasq
J'ai laissé sa conf de base et j'ai simplement ajouté un fichier /etc/dnsmasq.d/ma-config.conf
contenant :
server=/{domaine1}/{dns1}
server=/{domaine2}/{dns2}
server={dns FAI 1}
server={dns FAI 2}
Chaque ligne indique pour un domaine donné (et tous ses sous domaines) quel DNS utiliser.
Quand on indique pas de domaine c'est le DNS par défaut.
On a un DNS tout beau et tout propre, maintenant ce serait bien de s'en servir.
Config réseau : NetworkManager
J'utilise NetworkManager (nm) pour configurer mon réseau généralement. J'en suis pas forcément fan, mais pour des réseaux wifi il est pratique.
Il est possible de demander à nm de lancer lui-même dnsmasq. Je n'en ai pas l'intérêt personnellement.
Pour pouvoir choisir son serveur DNS, il faut éditer sa configuration réseau pour demander "Adresse only" et on peut ainsi choisir un DNS qui ne sera pas pris depuis la configuration DHCP.
VPN : vpnc
Il reste à lancer vpnc. La base pour le lancer c'est :
vpnc plouf.conf # démarré avec la conf décrite dans `/etc/vpnc/plouf.conf`
vpnc-disconnect # pour l'arrĂŞter
Encore une fois il est possible d'utiliser l'intégration avec nm, mais ce n'est pas ce que j'utilise.
Sur ma debian stable, ce qui gère la configuration système autour de l'ouverture de la connexion par vpnc est le script /usr/share/vpnc-scripts/vpnc-script
C'est un script qui est lancé après l'ouverture de la connexion par vpnc. Malheureusement, il ne gère pas d'ensemble de script pour que je puisse faire ma modif dans mon coin.
On peut trouver sur internet des gens qui parlent d'une configuration DNSUpdate
, mais elle n'est pas reconnue chez moi.
J'aurais pu utiliser une diversion debian, mais je vais partir sur un truc bête et méchant je crée le fichier /usr/share/vpnc-scripts/vpnc-script.custom.sh
#!/bin/sh
/usr/share/vpnc-scripts/vpnc-script
cat > /etc/resolv.conf <<EOF
# custom server by vpnc
nameserver 127.0.0.1
EOF
Et dans le fichier /etc/vpnc/plouf.conf
, j'ajoute la ligne :
Script /usr/share/vpnc-scripts/vpnc-script.custom.sh
Et nous voila avec une configuration DNS correct pour pouvoir utiliser un vpn sans dommage :)
vpn instable
Et pour finir… Je ne sais pas si c'est quelque chose d'habituel, mais mon vpnc n'est pas très stable. Il lui arrive de "tomber" de temps en temps.
Initialement, j'avais simplement ajouté un indicateur dans mon interface. J'utilise i3blocks.
Je me crée un script qui ping une IP accessible via le vpn et indique sur sa sortie standard si ça fonctionne ou pas :
#!/bin/bash
ping -c1 -W1 10.181.80.20 &> /dev/null
if [[ $? == 0 ]]; then
echo "vpn: on"
else
echo "vpn: off"
fi
et le petit bout de conf i3blocks qui va bien :
[vpn]
command=/usr/local/bin/vpn-check
interval=5
color=#C5D86D
Ça fonctionne bien, mais c'est assez frustrant. C'est à nous de remonter la connexion manuellement.
Pour palier à ça, j'ai choisi de mettre en place un watchdog.
Pour le plaisir de la découverte, j'ai choisi d'utiliser systemd pour ça. L'idée c'est de voir le vpn comme un service, je le lance et systemd se débrouille (en fait je vais l'aider un peu hein) pour maintenir la connexion.
Je crée un petit script perl :
#!/usr/bin/env perl
use strict;
use warnings;
use Net::Ping;
use 5.010;
use autodie;
use Time::HiRes qw(usleep);
use Systemd::Daemon qw( -hard notify );
sub watchdog {
my $ip = shift;
my $sleep = ($ENV{WATCHDOG_USEC} // 2_000_000) / 2;
my $ping = Net::Ping->new("icmp", 1);
while(1) {
if ($ping->ping($ip)) {
notify( WATCHDOG => 1 );
}
usleep $sleep;
}
}
system("/usr/sbin/vpnc-disconnect");
system("/usr/sbin/vpnc --no-detach plouf.conf");
sleep(1);
notify( READY => 1 );
watchdog("{ip for check}");
On a besoin de Systemd::Daemon
qui nécessite libsystemd-dev
.
Et le service systemd qui va avec my-vpnc.service
 :
[Unit]
Description=VPN with watchdog
[Service]
ExecStart=/home/michel/bin/resilient-vpn
Restart=on-watchdog
WatchdogSec=5
Voila un coup de systemctl start my-vpnc.service
et mon vpn est lancé et en cas de défaillance il va tout seul le relancer.
(Le journal est sous licence CC0 et si vraiment le code présenté pourrait être sous le coup de la propriété intellectuel il utilise la licence WTFPL
-
et aussi DHCP, mais on ne se servira pas de cette fonctionnalité ici ↩
# Stabilité
Posté par gouttegd . Évalué à  7.
J’ai utilisé vpnc de 2008 à 2013 pour accéder au serveur IMAP de mon université¹. Pour ce que ça vaut, chez moi non plus ça n’a jamais été stable.
À l’époque j’avais une solution à LA RACHE pour botter le cul du client. Il n’était pas nécessaire de pinguer une mire à travers le VPN, il suffisait de vérifier si le démon était toujours vivant :
¹ Serveur IMAP qui n’était accessible que depuis le réseau de l’université, ce que je trouve personnellement assez stupide — autant pour un serveur d’envoi de mails je peux comprendre qu’on ne veuille pas accepter de connexions depuis n’importe où, autant pour un serveur de réception l’intérêt m’a toujours échappé…
[^] # Re: Stabilité
Posté par gouttegd . Évalué à  6. Dernière modification le 14 juin 2020 à 22:22.
Pendant que j’y suis, je partage un autre souvenir qui peut intéresser des utilisateurs de vpnc.
Une des choses qui me dérangeaient était que, lors de l’établissement de la connexion, le client installait une route par défaut qui envoyait tout le trafic à travers le VPN, y compris le trafic qui n’était pas destiné à l’université. Non seulement c’était peu efficace, mais il n’y avait aucune raison pour que l’université voit tout mon trafic réseau, y compris mes activités n’ayant aucun rapport avec mon travail au sein de ladite université.
La consigne standard de l’université face à cela était de ne lancer le VPN que lorsqu’on avait besoin d’accéder à une ressource du réseau universitaire, et de le couper juste après. Faisable, certes, mais pas vraiment satisfaisant.
Dans mon cas, comme la seule ressource à laquelle je voulais accéder était le serveur de messagerie, j’avais remplacé le script par défaut de vpnc par celui-ci :
qui ne faisait que le strict minimum pour me permettre d’accéder au serveur de messagerie (mettre en place le tunnel et installer une route bien spécifique pour que seul le trafic destiné au serveur de messagerie ne soit envoyé dans le tunnel) sans rien toucher au reste de ma configuration réseau.
Voilà , ce n’est pas nécessairement applicable à tout le monde, mais si ça peut être utile à quelqu’un… (Merci barmic de m’avoir donné une raison de me replonger dans mes vieilles archives. :D )
[^] # Re: Stabilité
Posté par barmic 🦦 . Évalué à  3.
C'est aussi ce que faisait ma fac… J'avais pas pris le temps de faire ce genre de route à l'époque, j'étais aussi débrouillard qu'aujourd'hui (bien que ça ne m'avais pas empêché d'outrepasser leur vérification par adresse mac pour utiliser le réseau filaire (
apt-get dist-upgrade
sur renater c'est cool :p).C'est cool pour le partage :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Stabilité
Posté par barmic 🦦 . Évalué à  6. Dernière modification le 14 juin 2020 à 22:52.
C'est moi aussi une solution à LA RACHE. Je l'ai mis en place quand il m'a claqué dans les doigts et plutôt que de chercher dans la finesse, je me suis dis qu'en vérifiant l'accès à une ressource je gère forcément le cas.
Quitte à du coup tu pouvais l'empêcher de se détacher :
J'ai un truc du même genre pour discord (il plantait de temps en temps avec le paquet pour debian/ubuntu, je crois que depuis je suis passé au flatpak il n'a plus le problème).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# NetworkManager & dnsmasq
Posté par millman . Évalué à  2.
NetworkManager sait gérer dnsmasq. Avec cela on peut charger une config uniquement lorsqu'on active la connexion vpn.
Il y a un exemple ici.
[^] # Re: NetworkManager & dnsmasq
Posté par barmic 🦦 . Évalué à  3.
Tout à fait, mais je vois pas de problème particulier à lancer en permanence dnsmasq et je n'ai pas essayé, mais se caler entre le plugin NetworkManager et vpnc pour avoir un système de watchdog ne doit pas être trivial.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.