Internet regorge de guides concernant le déploiement d’un VPN privatif à partir d’un serveur VPS offshore. Cependant, et quand ce n’est pas des newbies qui recopient mal un guide mal expliqué, souvent ça ne marche pas et une étape clef est oubliée. On se retrouve alors avec des erreurs assez ésotériques et incompréhensibles …

Ici, nous allons voir comment mettre en place de manière exhaustive un serveur VPN à partir d’un VPS. Concrètement, après ce tutoriel, vous devriez pouvoir naviguer sur internet de manière anonyme, rapide, illimitée et pour des prix aussi bas que 3.6€/mois. Attention tout de même aux hébergeurs trop confidentiels, ils sont souvent incompétents et voleurs (hein nisarsoft.com ?).

Ceci devrait fonctionner sur toutes les machines basées Debian.


Organisation
  • Généralités sur les serveurs VPS
    • Prix
    • Anonymat
  • Installation & paramétrage de easyRSA
    • Génération du certificat serveur
    • Génération du certificat client
    • Génération des clefs cryptographiques
  • Installation & paramétrage de openVPN
    • Gestion de la configuration serveur
    • Gestion de la configuration client
    • Lancement du service
  • Paramétrage de Iptables
    • Gestion de la configuration ipv4
    • Gestion de la configuration ipv6
    • Conservation de la configuration
  • Désactivation de ipv6
  • Paramétrage avancé – à venir

VPS

Pour commencer il faut sous la main un serveur VPS (Virtual Private Server) ou dédié avec Debian 9.

Les prix varient, je ne donnerais pas de noms commerciaux ici mais il est facile de trouver des offres à 20€/6 mois soit 3.3€/mois. Attention au volume de données mensuel et à la bande passante effective, 100Mb/s dans les deux sens sans limitations est un must abordable. 

Vous n’aurez pas besoin d’espace disque, de RAM ni même de puissance CPU. Le réseau en revanche devra être de grande qualité, de même que l’uptime.

Vous trouverez des serveurs offshores un peu partout mais soyez conscients que plus la distance client – serveur augmente, plus vous risquez d’augmenter le temps de réponse. Une bonne idée pour se rendre compte de la performance réseau du serveur est de faire un ping du DNS global de Cloudfare, puis un ping du client au potentiel serveur : 

ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=61 time=2.77 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=61 time=2.78 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=2.97 ms
ping germanium.top
PING germanium.top (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from xxx (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=55 time=32.2 ms
64 bytes from xxx (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=55 time=32.5 ms
64 bytes from xxx (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=55 time=31.3 ms

Cloudfare devrait répondre en quelques millisecondes ; pour le client des valeurs en dessous de 70ms sont excellentes pour ce type de serveur virtualisé trop souvent mal géré du point de vue ressources.

C’est une bonne idée de fournir une identité disons … différente lors de l’inscription, de même qu’il est une bonne idée de payer avec le truc qui a une blockchain … 


easyRSA

easyRSA est un utilitaire qui contient tout ce qu’il faut pour construire une infrastructure à clefs publiques. Ce type d’architecture est indispensable pour assurer la sécurité des échanges clients/serveur. 

Premièrement, on installe easyRSA et openVPN

apt install easy-rsa openvpn

On créé ensuite un dossier de travail easyrsa dans /etc/openvpn/server :

make-cadir /etc/openvpn/server/easyrsa

On se déplace dans ce dossier de travail :

cd /etc/openvpn/server/easyrsa

Un petit ls -la nous indiquera si tout est bien en place :

lrwxrwxrwx 1 root root   28 May 31 05:55 build-ca -> /usr/share/easy-rsa/build-ca
lrwxrwxrwx 1 root root   28 May 31 05:55 build-dh -> /usr/share/easy-rsa/build-dh
lrwxrwxrwx 1 root root   31 May 31 05:55 build-inter -> /usr/share/easy-rsa/build-inter
lrwxrwxrwx 1 root root   29 May 31 05:55 build-key -> /usr/share/easy-rsa/build-key
lrwxrwxrwx 1 root root   34 May 31 05:55 build-key-pass -> /usr/share/easy-rsa/build-key-pass
lrwxrwxrwx 1 root root   36 May 31 05:55 build-key-pkcs12 -> /usr/share/easy-rsa/build-key-pkcs12
lrwxrwxrwx 1 root root   36 May 31 05:55 build-key-server -> /usr/share/easy-rsa/build-key-server
lrwxrwxrwx 1 root root   29 May 31 05:55 build-req -> /usr/share/easy-rsa/build-req
lrwxrwxrwx 1 root root   34 May 31 05:55 build-req-pass -> /usr/share/easy-rsa/build-req-pass
lrwxrwxrwx 1 root root   29 May 31 05:55 clean-all -> /usr/share/easy-rsa/clean-all
lrwxrwxrwx 1 root root   33 May 31 05:55 inherit-inter -> /usr/share/easy-rsa/inherit-inter
lrwxrwxrwx 1 root root   28 May 31 05:55 list-crl -> /usr/share/easy-rsa/list-crl
lrwxrwxrwx 1 root root   27 May 31 05:55 pkitool -> /usr/share/easy-rsa/pkitool
lrwxrwxrwx 1 root root   31 May 31 05:55 revoke-full -> /usr/share/easy-rsa/revoke-full
lrwxrwxrwx 1 root root   28 May 31 05:55 sign-req -> /usr/share/easy-rsa/sign-req
-rw-r--r-- 1 root root 2054 May 31 05:57 vars
lrwxrwxrwx 1 root root   35 May 31 05:55 whichopensslcnf -> /usr/share/easy-rsa/whichopensslcnf
-rw-r--r-- 1 root root 7859 May 31 05:55 openssl-0.9.6.cnf
-rw-r--r-- 1 root root 8416 May 31 05:55 openssl-0.9.8.cnf
-rw-r--r-- 1 root root 8313 May 31 05:55 openssl-1.0.0.cnf

On indique aux scripts l’utilisation de la dernière version de OpenSSL :

ln -s openssl-1.0.0.cnf openssl.cnf

Il est maintenant temps de paramétrer le générateur de certificats en éditant le fichier vars dans le répertoire /etc/openvpn/server/easyrsa. Un certificat est normalement signé par une organisation officielle, ici pour un simple VPN à usage domestique nous pouvons mettre n’importe quoi dans les champs, soyez inventifs. 

Veillez en revanche à bien paramétrer une longueur de clef de 4096 bits, c’est le minimum en 2019.

Modifiez les valeurs des champs correspondants : 

export KEY_SIZE=4096 # Longueur de la clef cryptographique

# Informations par défaut du générateur de certificats
export KEY_COUNTRY="RU"
export KEY_PROVINCE="FR"
export KEY_CITY="Boston"
export KEY_ORG="Space"
export KEY_EMAIL="contact@germanium.germ"
export KEY_OU="example"

export KEY_NAME="cert" # X509 Subject Field

On exporte les paramètres précédents :

source ./vars
./clean-all # à n'utiliser qu'à la première initialisation

Il est maintenant possible de générer le certificat :

./build-ca

On peut maintenant générer la clef serveur à partir du précédent certificat :

./build-key-server server

On génère maintenant une clef HMAC directement avec openVPN dans le dossier keys précédemment généré par easyRSA :

openvpn --genkey --secret keys/ta.key

On génère une clef Diffie-Hellman de 4096 bits :

openssl dhparam 4096 > keys/dh-4096.pem

Cette étape peut facilement prendre plusieurs heures si votre serveur manque d’entropie. Comptez 20 minutes sur un VPS avec deux cœurs virtualisés.

Il est maintenant temps de générer une clef client. Il est possible d’en utiliser une seule pour tout les clients ou d’en générer une spécifique par machine. Ici, une clef client est utilisée pour toutes les machines. 

Génération de la clef client :

./build-key client

Normalement, à cette étape, le dossier keys  contient tout les certificats/clefs et ressemble à ça :

-rw-r--r-- 1 root root    3 Jun  1 12:00 serial
-rw-r--r-- 1 root root   21 Jun  1 12:00 index.txt.attr
-rw-r--r-- 1 root root 2419 Jun  1 11:59 ca.crt
-rw-r--r-- 1 root root 8172 Jun  1 12:00 client.crt
-rw-r--r-- 1 root root 8275 Jun  1 12:00 server.crt
-rw-r--r-- 1 root root 1760 Jun  1 12:00 client.csr
-rw-r--r-- 1 root root 1756 Jun  1 12:00 server.csr
-rw------- 1 root root 3272 Jun  1 11:59 ca.key
-rw------- 1 root root 3272 Jun  1 12:00 client.key
-rw------- 1 root root  636 Jun  1 12:04 ta.key
-rw------- 1 root root 3272 Jun  1 11:59 server.key
-rw-r--r-- 1 root root   21 Jun  1 12:00 index.txt.attr.old
-rw-r--r-- 1 root root  123 Jun  1 12:00 index.txt.old
-rw-r--r-- 1 root root    3 Jun  1 12:00 serial.old
-rw-r--r-- 1 root root 8275 Jun  1 12:00 01.pem
-rw-r--r-- 1 root root 8172 Jun  1 12:00 02.pem
-rw-r--r-- 1 root root  769 Jun  1 12:35 dh-4096.pem
-rw-r--r-- 1 root root  249 Jun  1 12:00 index.txt

C’est terminé pour easyRSA, passons maintenant à openVPN.


openVPN

openVPN est un puissant logiciel libre basé sur openSSL qui permet de connecter deux pairs au travers d’un virtual private network, autrement dit l’architecture client/serveur utilisée par openVPN permet de construire un tunnel bidirectionnel crypté entre deux cartes réseau, virtuelles ou non. 

Il faut différencier cette notion de tunnel crypté et le fait de faire rebondir une connexion sur un serveur pour cacher son IP : ceci n’est possible qu’à l’aide d’une manipulation de la table IP entre les interfaces réseau du serveur, ce que nous verrons plus loin. 

Commençons par créer un utilisateur openvpn, en effet le service tourne normalement sous root par défaut ce qui constitue un défaut de sécurité :

adduser --system --shell /usr/sbin/nologin --no-create-home openvpn

On copie ensuite le fichier de configuration d’exemple directement dans /etc/openvpn :

gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

Il est ensuite temps d’indiquer où sont nos certificats et clefs :

# Localisation des clefs et certificats
ca /etc/openvpn/server/easyrsa/keys/ca.crt
cert /etc/openvpn/server/easyrsa/keys/server.crt
key /etc/openvpn/server/easyrsa/keys/server.key 
dh /etc/openvpn/server/easyrsa/keys/dh-4096.pem
tls-auth /etc/openvpn/server/easyrsa/keys/ta.key 0

# Définition des normes cryptographiques
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

# Modification de l'utilisateur par défaut
user openvpn
group nogroup

# Redirection de tout le trafic client sur le VPN
# et utilisation du DNS de cloufare 
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1" # Cloudfare DNS

# Compression - attention aux ressources CPU serveur
compress lz4-v2
push "compress lz4-v2"

# i don't like logs 
# enable this AFTER first successfull launch !
#status /dev/null
#log         /dev/null
#log-append  /dev/null

Je conseille l’utilisation du DNS de Cloudfare (1.1.1.1), à ce jour le plus rapide et qui apparemment respecte la vie privée.

Il est également possible de modifier le protocole utilisé (tcp/udp) et le port d’écoute (udp:1194 par défaut). Attention cependant, les changements apportés devront suivre à l’étape du paramétrage de la table IP.

On peut maintenant faire un test pour s’assurer que la configuration est bonne :

openvpn --config /etc/openvpn/server.conf

Si la sortie ressemble à ça, c’est bon :

Sun Jun  2 10:15:22 2019 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 14 2018
Sun Jun  2 10:15:22 2019 library versions: OpenSSL 1.0.2r  26 Feb 2019, LZO 2.08
Sun Jun  2 10:15:22 2019 Diffie-Hellman initialized with 4096 bit key
Sun Jun  2 10:15:22 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun Jun  2 10:15:22 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun Jun  2 10:15:22 2019 ROUTE_GATEWAY xxx.xxx.xxx.xxx/255.255.255.0 IFACE=xxxx HWADDR=xx:xx:xx:xx:xx
Sun Jun  2 10:15:22 2019 TUN/TAP device xxxx opened
Sun Jun  2 10:15:22 2019 TUN/TAP TX queue length set to 100
Sun Jun  2 10:15:22 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Jun  2 10:15:22 2019 /sbin/ip link set dev tun0 up mtu 1500
Sun Jun  2 10:15:22 2019 /sbin/ip addr add dev tun0 local xx.xx.xx.xx peer xx.xx.xx.xx
Sun Jun  2 10:15:22 2019 /sbin/ip route add xx.xx.xx.xx via xx.xx.xx.xx
Sun Jun  2 10:15:22 2019 Could not determine IPv4/IPv6 protocol. Using AF_INET
Sun Jun  2 10:15:22 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Jun  2 10:15:22 2019 UDPv4 link local (bound): [AF_INET][undef]:1194
Sun Jun  2 10:15:22 2019 UDPv4 link remote: [AF_UNSPEC]
Sun Jun  2 10:15:22 2019 GID set to xxxx
Sun Jun  2 10:15:22 2019 UID set to xxxx
Sun Jun  2 10:15:22 2019 MULTI: multi_init called, r=256 v=256
Sun Jun  2 10:15:22 2019 IFCONFIG POOL: base=xx.xx.xx.xx size=xx, ipv6=0
Sun Jun  2 10:15:22 2019 Initialization Sequence Completed

Si vous rencontrez des difficultés pour lancer openVPN avec la configuration précédente, vous pouvez augmenter le niveau de log dans le fichier server.conf avec le paramètre verb

Si le test est concluant, la configuration de base du serveur est maintenant terminée. Il est possible de lancer le serveur avec systemctl comme suivant :

systemctl start openvpn
systemctl start openvpn@server

server représente le fichier server.conf dans lequel nous avons travaillé précédemment et qui se trouve dans /etc/openvpn. Si le lancement du service échoue, vous avez très probablement une erreur de localisation des clefs/certificats générés dans la partie easyRSA, un petit systemctl status openvpn devrait alors aider. Il est également possible de lancer plusieurs serveurs parallèles en spécifiant d’autres fichiers de configuration, mais pas sur le même port évidemment.

Si le service se lance correctement, il est temps d’activer le lancement du serveur au boot

systemctl enable openvpn
systemctl enable openvpn@server

Si pour une raison ou pour une autre systemctl start openvpn@server foire, il est possible d’ajouter cette ligne au crontab via crontab -e :

@reboot /usr/sbin/openvpn --config /etc/openvpn/server.conf

Passons maintenant à la configuration client. On importe un fichier d’exemple dans /etc/openvpn/server :

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/server/client.ovpn

Modifiez, décommentez ou créez ces paramètres dans le fichier client.ovpn précédemment copié :

remote vpn.mydns.com 1194
user nobody
group nogroup
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

EDIT : La ligne auth SHA512 pose parfois problème, si une erreur relative à l’authentification TLS apparaît dans le log serveur, commentez là pour repasser sur SHA1.

Remplacez vpn.mydns.com par l’adresse DNS de votre serveur, à défaut une IP suffira. Assurez vous quand même qu’elle soit fixe ! Ajustez également le protocole et le port suivant vos préférences, tant qu’elles matchent la configuration du serveur.

On prépare ensuite les certificats/clefs/configurations pour le client :

cd /etc/openvpn/server/easyrsa/keys
zip client.zip ca.crt ta.key client.key client.crt dh-4096.pem /etc/openvpn/server/client.ovpn

Il ne reste plus qu’à récupérer le fichier client.zip sur la machine client et indiquer à openVPN où se trouve le fichier de configuration.

Il est possible de faire descendre ce fichier client.zip chez le client avec la commande scp ou son cousin windows : pscp.

A cette étape, je conseille d’essayer de connecter un client pour s’assurer que les certificats sont correctement reconnus, que les clefs sont en place et que la configuration est correcte. Le client n’a pas accès à internet à ce stade, c’est normal.

Ne passez pas à la partie suivante si vous n’arrivez pas à connecter un client.


iPTables

EDIT : J’assume ici que l’interface réseau opérationnelle sur le serveur se nomme eth0 comme c’était le cas avant la version 9 de Debian, remplacez suivant convenance.

Iptables est un vieux programme de l’environnement linux qui gère les règles du pare feu à bas niveau, dans le noyau. C’est donc un outils très puissant mais aussi dangereux, avec le traditionnel `rm -vrf /*`, il constitue l’une des principales erreurs de débutant : être bloqué à la porte de son serveur. Vous êtes prévenus ! 

Maintenant, il faut bien comprendre ce qui se passe. Notre serveur VPN final vise à garantir l’anonymat et la sécurité d’un client à travers ses interfaces réseau, hors pour le moment sous sommes juste capables de connecter deux cartes réseau entre elles de manière sécurisée, en encapsulant le trafic du client vers l’interface tun0 du serveur. Il va falloir créer un lien entre les deux interfaces réseaux eth0 et tun0 sur ce dernier, de manière à pouvoir router les paquets vers l’extérieur.

On créé un fichier v4.rules dans /tmp, puis on ajoute les règles suivantes, à adapter suivant le port/protocole que vous avez choisis plus haut et la configuration réseau de votre serveur :

*filter

# loopback full authority
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A OUTPUT -o lo -j ACCEPT

# ping answer
-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT

# ssh i/o
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT

# openvpn trough
-A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED --dport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state ESTABLISHED --sport 1194 -j ACCEPT

# dns on 53
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED --sport 53 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 53 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT

# debian update allow
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 80 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT

# ntp clock sync
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED --sport 123 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED --dport 123 -j ACCEPT

# TUN tunnel trough vpn
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

# openvpn forward
-A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# log blocked trafic
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 4
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 4
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_OUTPUT_denied: " --log-level 4

# reject other trafic
-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT

COMMIT

On créer un fichier v6.rules dans /tmp, puis on ajoute les règles suivantes de manière à bloquer complètement le trafic ipv6 sur le VPN : 

*filter

-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT

COMMIT

On vire toutes les règles déjà existantes :

iptables -F && iptables -X

On ajoute ensuite une règle qui permet le transfert de paquets entre les deux interfaces réseau tun0 et eth0 (c’est le lien)

 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

On ajoute le reste des règles :

iptables-restore < /tmp/v4.rules
ip6tables-restore < /tmp/v6.rules

On rend la configuration Iptable persistante (elle est normalement reset à chaque reboot) avec l’aide de iptables-persistent :

 apt install iptables-persistent
 service netfilter-persistent save

Si iptables-persistent ne fonctionne pas pour une raison ou pour une autre, il faut placer les fichiers v4.rules & v6.rules dans /etc/openssh puis créer le script suivant nommé iptable-update.sh, également dans /etc/openvpn :

iptables -F && iptables -X
iptables-restore < /etc/openvpn/v4.rules
ip6tables-restore < /etc/openvpn/v6.rules
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

N’oubliez pas de le rendre exécutable par le cron :

chmod 700 /etc/openvpn/iptables-update.sh

Puis de l’importer dans la config du cron via crontab -e :

@reboot sh /etc/openvpn/iptables-update.sh > /dev/null 2>&1

 


ipv6

Il faut ensuite virer tout ce qui attrait de près ou de loin au protocole ipv6 dans le système, premièrement dans /etc/hosts en commentant toutes les lignes ipv6 :

127.0.0.1       localhost
127.0.1.1       debian

# The following lines are desirable for IPv6 capable hosts
#::1     localhost ip6-localhost ip6-loopback
#ff02::1 ip6-allnodes
#ff02::2 ip6-allrouters

Maintenant on trouve et on commente cette ligne dans /etc/sysctl.d/99-sysctl.conf :

net.ipv4.ip_forward=1

Dans le même fichier /etc/sysctl.d/99-sysctl.conf, on ajoute :

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

On applique les changements :

sysctl -p

Conclusion

Notre VPN est maintenant entièrement opérationnel. Il suffit sous linux de donner le fichier de configuration client à openVPN, adjoint de ses certificats et clefs, pour se connecter à son serveur offshore :

openvpn client.ovpn

S’il ne l’est pas, identifiez bien la partie qui pose problème – la configuration openVPN, un mauvais certificat, une clef mal renommée ou une erreur dans la reconfiguration du pare-feu ? Sous windows, pensez bien à exécuter le client openVPN avec les droits administrateurs, sinon le trafic ne sera pas envoyé vers l’adaptateur TAP.


Script bonus !

Voici un petit script à planquer dans /etc/openvpn/easyrsa/keys, il permettra de générer facilement un fichier zip contenant tout le nécessaire à envoyer sur le client :

name=$1
source ./../vars &&
./../build-key "$name"
cp germanium.ovpn "$name".ovpn
sed -i -e "s/TAG/$name/g" "$name".ovpn
zip "$name".zip "$name".* ca.crt ta.key dh-4096.pem

Deuxième bonus !

Il est possible d’installer le serveur DNS Pi-Hole directement sur le VPN pour bloquer à l’aide de fichiers hosts le trafic de prise d’empreinte, de tracking, de pub, d’adwares, etc …

Je n’ai pas vraiment le temps décrire sur le sujet mais voici la procédure accélérée : 

  • Installer Pi-Hole sur tun0
  • Paramétrer OpenVPN pour pousser l’IP de résolution DNS du serveur VPN au client et non celui de Cloudfare

L’interface administrative de Pi-Hole est ensuite accessible sur http://10.8.0.1 (une fois connecté au VPN)


2 commentaires

cyril · 16 avril 2020 à 18 h 56 min

Bonjour,
article très intéressant, mais j’ai beau chercher des serveurs dédiés vps offshre aux prix que tu annonce, et ben j’en trouve pas, minimum 15€/mois. Donc si tu as des adresses je suis preneur. En attendant merci pour ce tuto !!!

Corentin Douay · 19 avril 2020 à 22 h 32 min

Hello,

J’ai un peu galéré aussi avec les hébergeurs pour finalement atterrir chez VPS9, 25e/6 mois, quelque chose comme ça. Mon serveur reste en Europe mais pour ce que j’en fais ça suffit ! Tiens moi au courant une fois devant la console si des étapes ne sont plus à jour 😉

Corentin

Laisser un commentaire

%d blogueurs aiment cette page :