lid's stuff

Se faire son VPN perso

Alors, quel est l'intérêt de se faire son propre VPN perso, cette technologie de terroris'/hacker/whatever creepy definition? (comment ça le bullshit médiatico-politique autour de la tech' et notamment du chiffrement me gave?)

  • Primo, pouvoir se connecter à son réseau local "comme à la maison", sans avoir à NATter une tonne de services
  • Pouvoir router son trafic à travers le VPN, pour sécuriser sa connexion (hotspot wifi, réseau inconnu, etc)
  • Pouvoir router son trafic à travers le VPN pour protéger un peu sa vie privée (FaceBook© et cie "croiront" que vous vous connectez depuis chez vous (think géolocalisation)

Un petit prérequis si vous utilisez votre accès perso: NATter le port utilisé par votre VPN dans la configuration de votre *box (liveboite, freeboite, sfrboite, etc).

Un petit plus: un FQDN si vous avez une IP fixe, sinon un DNS dynamique (meh) type noip ou dyndns. Comme ça en cas de changement d'IP (redémarrage de la box, etc), vous pourrez toujours accéder à votre VPN avec une adresse du type michel.noip.org et cie.

Installation

très simple, il suffit d'un bon vieux:

$ sudo apt install openvpn easy-rsa

et on est bons :)

Génération des certificats

Deux méthodes:

  • générer une clef statique sur le serveur. Simple mais tant qu'à faire, autant se générer un "vrai" certif'
  • utiliser easy-rsa pour générer un ou plusieurs certificats

Comme c'est plus fun d'utiliser de vrais certificats faits maison (ahah) on va donc utiliser easy-rsa, qui est planqué dans /usr/share/doc/openvpn/:

# cd /etc/openvpn
# cp -R /usr/share/easy-rsa ./

Ensuite, nous allons modifier le fichier de configuration d'easy-rsa:

# cd easy-rsa
# vim vars
modifier les clefs exportées (KEY_COUNTRY, etc)

IMPORTANT: on ajoutera la directive export HASH_ALGO=sha256 afin de ne pas utiliser sha1 (déprécié) pour nos certifs.

# source ./vars
# ./clean-all # on part de clefs neuves
# ./build-ca # on crée notre certif d'autorité de certification
# ./build-key-server nomdeclef # on crée le certificat du serveur
# ./build-dh # on génère les paramètres diffie-hellman du serveur

On va ensuite pouvoir créer les clefs de nos clients:

# ./build-key client1

on peut aussi utiliser build-key-pass pour que le client soit obligé de rentrer un mot de passe lors de sa connexion. Ici, je vais utiliser la méthode simple, à fin de tests, donc: build-key client1

Configuration du serveur

Rien de bien méchant, on va juste créer le fichier de configuration du tunnel:

vim /etc/openvpn/server.conf

port 1194 # port standard d'openvpn - on pourra utiliser le port 443 par exemple si jamais le 1194 est indisponible (en tcp dans ce cas)
proto udp # on utilisera udp. Si on veut utiliser tcp: proto tcp-server
dev tun   # on veut créer un tunnel IP. On peut aussi créer un tunnel ethernet: dev tap
comp-lzo  # compression des paquets - peut etre utile en cas de bande passante moisie
persist-key
persist-tun
keepalive 10 120
server 10.10.10.0 255.255.255.0 # si on veut que notre subnet pour le vpn soit 10.10.10/24
#params SSL
ca /chemin/vers/clef/ca.crt
cert /chemin/vers/clef/nomdeclef.crt
key /chemin/vers/clef/nomdeclef.key
dh /chemin/vers/clef/dh1024.pem
cipher AES-256-CBC # algo de chiffrement utilisé
user nobody
group nogroup
max-clients 20 # nombre max de clients
client-to-client # si on veut que nos clients puissent communiquer entre eux
push "route 192.168.10.0 255.255.255.0" # si on veut que les clients aient une route vers 192.168.10.0/24 
# si c'est le subnet de votre réseau local
push "route 0.0.0.0 0.0.0.0" # pour la route par défaut, ou sinon:
push "redirect-gateway def1 bypass-dhcp" # si on veut conserver 
# la route même après un renouvellement du bail DHCP. plus propre
push "dhcp-option DNS ip.dns.ser.ver" # pour pusher un serveur dns sur les clients

Et voilà, on est presque bons pour notre serveur.

En effet, si on veut que notre vpn forwarde vers le grand Ternet nos jolis paquets tous certifiés, il va falloir gentiment lui dire de forwarder nos paquets, premièrement, et aussi régler 2/3 trucs avec notre copain iptables:

Relai du trafic par notre vpn

Premièrement, on autorise l'ip forwarding:

  • Méthode rapide, pendant que la machine tourne:

      # echo 1 > /proc/sys/net/ipv4/ip_forward
      idem pour ipv6, je vous laisse découvrir ;p
    
  • Méthode pour activer dès le boot l'ip forwarding

      # vim /etc/sysctl.conf, décommenter la ligne:
      net.ipv4.ip_forward = 1
    
  • Ensuite, notre copain iptables:

      # iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
      # iptables -A FORWARD -s 10.10.10.0/24 -o eth0 -j ACCEPT
      # iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
    

Si tout fonctionne, on sauvegardera nos règles iptables:

# iptables-save > /etc/iptables.up.rules

Et par exemple, pour que ces règles soient chargées automatiquement au boot, on peut ajouter dans /etc/network/interfaces, à la fin de la définition de notre interface réseau:

# vim /etc/network/interfaces
iface eth0 inet dhcp # ou static
…
gateway ip.gate.way
up iptables-restore < /etc/iptables-rules

Et là normalement on est bons :)

Configuration du client

La configuration du client est bien plus simple.

IMPORTANT: les fichiers de certificats ainsi que le fichier de config doivent etre placés dans un répertoire utilisateur, par exemple $HOME/vpnmaison/

le fichier de conf' client:

client # bin oui, faut bien lui dire qu'on est pas le serveur :)
port 1194 # utile si on veut que notre vpn utilise le port 443, par exemple
proto udp # proto tcp-client si on utilise tcp
remote ip-publique.du.serveur.vpn # ou FQDN
nobind
dev tun
comp-lzo
ca ~/vpnmaison/ca.crt
cert ~/vpnmaison/client1.crt
key ~/vpnmaison/client1.key
remote-cert-tls server # on vérifie bien l'identité du serveur sur lequel on se connecte (pour éviter un MITM)
cipher AES-256-CBC # algo de chiffrement
# logs
log /var/log/openvpn.log
verb 3

Connexion au VPN

On vérifie d'abord que le serveur vpn tourne bien sur notre... hum, serveur :)

Si on utilise systemd, et que le fichier de configuration du serveur s'appelle server.conf:

# systemctl enable openvpn@server
# systemctl start openvpn@server
# systemctl status openvpn@server
# ip route show #pour vérifier si nos routes sont ok, ça peut etre sympa pour un premier test ;p

Puis, sur le client, il suffit de lancer:

$ sudo openvpn ~/vpnmaison/client.conf

Et voilà :D

On peut ensuite tester qu'on ping bien notre réseau local, par exemple notre passerelle - disons qu'elle a pour IP 192.168.10.1:

$ ping 192.168.10.1

Et tant qu'à faire, qu'on ping bien aussi le Grant Ternet:

$ ping wikipedia.org

Si ça ne fonctionne pas, vérifier quel DNS est utilisé sur le client (/etc/resolv.conf) et le modifier si nécessaire par un DNS public (par exemple ceux de FDN).

Note 18/6/2017 - mise à jour Debian Stretch: la directive push route "subnet mask" devient push "route subnet mask" - pensez donc bien à mettre à jour la configuration du serveur :)


Tagged under: sysadmin, network