Journal Un peu de configuration réseau pour VPN

Posté par  .
15
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  . É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  . É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.