Journal Un peu de configuration réseau pour VPN

Posté par  .
16
14
juin
2020

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


  1. et aussi DHCP, mais on ne se servira pas de cette fonctionnalité ici ↩

  • # StabilitĂ©

    Posté par  (site web personnel) . É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 :

    #!/bin/bash
    while true ; do
        if [ ! -s /var/run/vpnc/pid ] || ! kill -0 $(< /var/run/vpnc/pid) ; then
            logger -t vpnc "VPN connection seems down, kicking the client"
            /usr/sbin/vpnc
        fi
        sleep 600
    done

    ¹ 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  (site web personnel) . É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 :

      #!/bin/bash
      
      case "$reason" in
      pre-init)
          ;;
      
      connect)
          # Setup interface for the tunnel
          /sbin/ifconfig $TUNDEV inet $INTERNAL_IP4_ADDRESS \
            pointopoint $INTERNAL_IP4_ADDRESS \
            netmask 255.255.255.255 mtu 1412 up
          # Setup a route to the mail server through the tunnel
          /sbin/route add mail.university.example dev $TUNDEV
          ;;
      
      disconnect)
          /sbin/ifconfig $TUNDEV down
          ;;
      esac
      

      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  . É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  . Évalué à 6. Dernière modification le 14 juin 2020 à 22:52.

      Il n’était pas nécessaire de pinguer une mire à travers le VPN[…]

      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.

      il suffisait de vérifier si le démon était toujours vivant

      Quitte à du coup tu pouvais l'empêcher de se détacher :

      #!/bin/bash
      while true ; do
          /usr/sbin/vpnc --no-detach
          logger -t vpnc "VPN connection seems down, restart the client"
      done

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