No log, no cry

Cet article n'est pas sponsorisé par ***VPN !

Mais cet article va avoir pour but de vulgariser l'usage d'un VPN et évidemment on va se pencher sur l'usage d'un VPN dans l'IT qui est très différent d'un VPN dit "commercial".

1. Qu'est ce qu'un V.P.N

C'est un acronyme pour Virtual Private Network (Réseau privé virtuel).

Il permet de créer un tunnel entre deux appareils (le serveur et le client ou entre deux clients en fonction du protocole utilisé).

Qu'il soit grand public ou d'entreprise le principe d'un VPN c'est de créer un réseau entre 2 appareils afin de former un tunnel dont l'ensemble des connexions sont chiffrées, les regroupant ainsi dans un même réseau.

Les usages sont évidemment très différents en fonction de la nature du VPN.

2. Le V.P.N grand public

Pour ce type de VPN, le fonctionnement est simple, on installe un logiciel (fourni par notre prestataire), on clique et on rejoint le serveur de destination.

Aux yeux d'internet, on apparaît donc à cet endroit-là.

Avant la connexion tu es identifié par ta connexion de ton fournisseur d'accès internet avec ton adresse IP qui permet de connaître "d'où tu viens" et vers "où tu vas".

Après ta connexion, tu sors par le serveur du prestataire sous son adresse IP à lui et par conséquent, ton emplacement réel est "protégé" et les informations entre toi et le serveur VPN sont confidentielles. 

C'est comme si tu avais un ami au Japon et que tu te connectais chez lui physiquement. Sauf que là c'est instantané et moins cher qu'un vol vers Haneda.

Pour en savoir un peu plus sur la vulgarisation des différents protocoles réseaux et comment fonctionne internet en général, la video de V2F est top.

La confidentialité et le "no-log"

En utilisant un VPN tu es protégé mais il faut savoir que même si tes informations sont chiffrées entre toi et le VPN, lui sait vers quelles destinations tu te rends avec tes requêtes.

C'est un point essentiel en matière de confidentialité.
Et pour moi, c'est le critère le plus important quand tu choisis un VPN commercial.

En réalité, tu ne supprimes pas la confiance tu la déplaces de ton FAI vers ton fournisseur VPN.

Or, ces dernières années, le marketing de certains VPN est devenu particulièrement agressif.
Selon l'Arcom, 29 % des internautes français utilisent un VPN, dont 15 % de manière régulière.

Le VPN commercial est désormais bien ancré dans les usages.

Mais il faut qu'on évoque un point fondamental : le no-log (littéralement "sans journalisation").

Un VPN étant ton point de sortie vers Internet, il sait où tu vas et quand, puisqu'il relaie tes requêtes vers leur destination.

Il ne voit pas forcément le contenu si celui-ci est chiffré (HTTPS), mais il voit les métadonnées essentielles.

C'est précisément là que se joue la question de la confiance.

Maintenir une infrastructure VPN coûte cher : datacenters, bande passante, énergie, équipes techniques, audits de sécurité…

Par conséquent, les VPN dits "gratuits" doivent se financer d'une manière ou d'une autre :

• Publicité
• Collecte ou exploitation de données
• Modèle freemium avec version payante

Les entreprises qui revendiquent une politique no-log sont parfois auditées pour vérifier leurs affirmations.

Mais des zones grises ou des critiques récurrentes existent, y compris chez des acteurs payants.

Même si tu penses n'avoir rien à cacher tu as tout à protéger. Je suis certain que tu ne laisserais pas un inconnu fouiller ton téléphone dans la rue, même s'il ne contient rien de compromettant. Ta navigation en ligne est une extension de ta vie privée.

Bref, si tu choisis un VPN commercial, ne laisse pas une publicité YouTube décider à ta place.

Regarde les audits, la juridiction, l'historique de transparence. Ce n'est pas une question de complotisme, c'est juste être maître de tes données et à qui tu les donnes.

Un VPN n'est pas une solution magique. C'est un contrat de confiance.

Et un contrat de confiance mérite plus qu'un code promo sponsorisé et qu'une application gratuite.

D'ailleurs on parle de "no-log" mais les logs "techniques" eux peuvent rester longtemps chez ton fournisseur, tes coordonnées bancaires également etc …

J'ai peint un tableau un peu alarmiste avec le dernier paragraphe, mais voyons ensemble les avantages à protéger sa navigation.

Les avantages d'un VPN grand public

Grâce au changement de localisation, on peut obtenir des achats moins chers en fonction de là où le commerce pense nous trouver :

• Un billet d'avion moins cher
• Un abonnement (musique, jeu etc …) moins cher

Le tunnel chiffré quant à lui permet de sécuriser sa connexion dans des lieux avec des wifis publics (gares, hôtels ou cafés). Les attaques étant régulières sur ce genre de réseaux et cela permet de se protéger contre ce genre de danger.

Attention cependant à ton hygiène numérique, ça ne doit pas te faire baisser ta garde à propos du risque de phishing, de la navigation en HTTPS etc …

Et dernier avantage pour moi et pas des moindres, il permet à des personnes résidant dans des pays où la liberté d'expression est une menace d'état de pouvoir s'informer et s'exprimer sans crainte (même si malheureusement certaines censures arrivent à passer outre les VPN).

Et rappelons également que ce n'est pas parce qu'un droit nous semble acquis qu'il n'est pas en danger. Courant 2026, le Royaume-Uni a mis sur la table l'interdiction des VPN. Même chose chez nous en France. C'est une mesure anti-liberté très grave.

C'est terminé pour la partie VPN commercial grand public etc …

Le but était surtout de faire un petit rappel sur l'usage de ce genre de VPN et de voir maintenant la différence avec un VPN type d'entreprise pour introduire sa mise en place.

3. Le VPN d'entreprise

Le VPN commercial repose sur un modèle de confiance. Le VPN d'entreprise, lui, repose sur un modèle de contrôle.

Il permet ainsi de créer un réseau virtuel sécurisé où des machines distantes sont interconnectées, comme si tu étais branché à la machine d'à côté.

Grâce à ce système, le réseau peut contrôler et sécuriser le trafic qui y circule, en utilisant différents protocoles VPN adaptés à la sécurité et à la performance.

Et dans ce réseau, les appareils bénéficient des effets des autres machines comme un service DNS, un serveur de fichiers etc …

Il faut voir ça comme un immeuble sécurisé, avec des fenêtres opaques. On entre par la porte avec une adresse "réelle" puis on se déplace dedans avec des adresses "privées" vers les appartements. Le monde extérieur ne sait pas que "2ème porte à gauche" c'est dans tel immeuble.

On se connecte avec un VPN via une IP publique comme par exemple 161.224.108.40 (logique puisqu'il faut pouvoir se connecter à un endroit précis où se situe le serveur VPN).

Mais à l'intérieur de ce réseau, on nous y attribue une IP dite "privée" qui est unique à l'intérieur.

On peut en trouver de diverses formes mais les plus courantes sont :

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16 (oui comme à la maison)

(le /8, /12, /16 est la notation CIDR qui permet de cibler une plage plutôt qu'une IP précise).

Le gros avantage de ce genre de réseau c'est qu'on a accès à des outils qui sont normalement fermés au reste du monde. Et là tu vois très bien où je veux en venir : On va pouvoir héberger des services web de manière ultra privée et pas juste par un allow tonIP; deny all; de Nginx (qui en plus écoute sur l'interface réseau 0.0.0.0). Le but étant de réduire la surface d'attaque.

Bref l'objectif de l'article n'est donc pas de créer un VPN à audience d'entreprise mondiale, mais plus de faire un VPN pour des usages de développeur.

Ici le but va être d'héberger une page web, accessible uniquement via le VPN, desservie par un Nginx qui n'écoute cette fois-ci que sur l'interface réseau du VPN installé sur la machine.

On va s'attarder juste avant sur les différents types de protocoles VPN.

Les protocoles

Il existe aujourd'hui trois grands protocoles VPN connus, qui servent globalement à la même chose.

(il y a des nuances techniques, mais je ne suis pas là pour te faire un cours réseau complet.)

• WireGuard : fonctionne sur UDP et utilise une paire de clés publique/privée (un peu comme les clés SSH). Les pairs se connectent directement entre eux, chacun identifié par sa clé publique et son adresse (endpoint), sans serveur de coordination central.
• OpenVPN : basé sur SSL/TLS, mature et flexible, utilisé pour des configurations plus complexes ou des VPN commerciaux.
• L2TP/IPsec : pratique pour des clients Windows ou macOS, parce qu'il est souvent nativement supporté et simple à configurer pour les employés.

Pour notre usage, nous allons partir sur WireGuard.

Pourquoi ?

C'est le protocole contenant le moins de lignes de code pour son fonctionnement.

OpenVPN est d'une part plus complexe à mettre en place mais également beaucoup plus imposant en code ce qui lui donne une plus grosse surface d'attaque.

On va y aller doucement, étape par étape, ça va bien se passer.

Mise en pratique

Côté serveur

Pour l'installation, on va faire côté serveur et côté client, pour ça, on se rend sur cette page et on choisit son OS.

Pour ma part : apt install wireguard .

Wireguard reposant sur une paire de clés privée et publique, on va se créer un dossier où les stocker et on génère les 2 clés :

mkdir /etc/wireguard/keys && cd /etc/wireguard/keys

// partie privée
wg genkey > server.key
chmod 0600 server.key # on protège toujours les clés privées

// partie publique
wg pubkey < server.key > server.pub

On va dire à notre système de forwarder les requêtes qui ne sont pas destinées au serveur lui-même (pour éviter de bloquer le client).

D'abord au niveau du noyau Linux : nano /etc/ufw/sysctl.conf ⇒ net/ipv4/ip_forward=1

Puis ensuite au niveau du firewall (chez moi UFW) :

ufw route allow in on wg0 out on eth0

Puis on ajoute une règle de "MASQUERADE" qui permet au client de passer par l'IP du serveur (côté IP publique) lorsqu'il sort vers Internet à partir d'une interface (ici eth0).

Comment je sais que mon interface réseau ip publique c'est eth0 ? J'utilise la commande ip a et c'est celle qui me donne mon ip publique :

(Pour les petits malins qui veulent tenter sur l'ip, c'est un cloud public pour le tuto, l'instance sera reset après coup).

Cette règle on l'ajoute dans /etc/ufw/before.rules juste avant le bloc "filter" :

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.100.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Dans /etc/default/ufw on change la règle DEFAULT_FORWARD_POLICY de ACCEPT à DROP .

Et dernière étape pour le firewall, on laisse le port ouvert sur le pare-feu ufw allow 51820/udp sinon … on aura beau tenter de s'y connecter, on sera bloqué (c'est pas du vécu … promis !). Et on restart avec service ufw restart .

À présent, on va paramétrer notre nouvelle interface wg0 avec nano /etc/wireguard/wg0.conf:

[Interface]
Address = 10.100.0.1/24 # CIDR : 10.100.0.1 => 10.100.0.254
ListenPort = 51820
PrivateKey = taCléSecrête

Le nom du fichier donnera le nom de la nouvelle interface (ici wg0.conf donne wg0 pour interface).

Si j'ai un vpn pour la maison et un autre pour un serveur de travail, je peux aisément multiplier les réseaux.

On instancie notre nouvelle interface réseau : wg-quick up wg0.

S'il y a une erreur, c'est explicite et l'interface réseau n'est pas créée.

On peut s'assurer de sa création avec wg show wg0 ou ip a .

C'est bon ! Notre serveur de coordination est créé.

Côté client

Direction un second serveur, où on installe également Wireguard en faisant les mêmes étapes jusqu'à la génération des clés (strictement la même chose que l'étape 1) :

mkdir /etc/wireguard/keys && cd /etc/wireguard/keys

// partie privée
wg genkey > server.key
chmod 0600 server.key # on protège toujours les clés privées

// partie publique
wg pubkey < server.key > server.pub

 

 

Maintenant on crée notre interface wg0 côté client : nano /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = TacléPrivéeDeTaMachineCliente
Address = 10.100.0.2/32 # IP de ta machine sur le VPN
DNS = 1.1.1.1 

[Peer]
PublicKey = TaCléPubliqueDeTaMachineServeur
Endpoint = IPDeTaMachineServeur:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

OK donc là on a quelques nouveautés au niveau des paramètres.

Dans [Interface] on a ajouté DNS qui permet au client de faire ses requêtes à un DNS "public".

Sans DNS =, le client utilise son résolveur d'origine, ce qui peut provoquer une fuite DNS (ou une panne de résolution si ce résolveur, étant une IP privée, devient injoignable dans le tunnel).

Si je recherche "google.com" sans avoir mis un DNS public, il faut que le serveur Wireguard ait lui même une config de DNS connaissant google.com, sinon les requêtes vers internet vont échouer.

Nouvelle zone : [Peer] c'est le nœud que l'interface est autorisée à contacter.

Pour ça on lui donne la clé publique du serveur (et le serveur pourra vérifier via sa propre clé privée).

Endpoint c'est l'IP publique du nœud, ici notre serveur Wireguard.

AllowedIPs a un double rôle. Le premier, c'est celui de l'émission (ici côté client) : quelle destination ira dans le tunnel pour ce client. Ici 0.0.0.0/0, ::/0 signifie "tout" : toutes les requêtes vers les IP de cette plage passeront par le tunnel.

Le second rôle, c'est celui de la réception (filtre) : de quelles IP source on accepte les paquets venant de ce peer. C'est le même champ, lu différemment selon qu'on émet ou qu'on reçoit. Dans notre cas on ne limite pas, donc le client acceptera les paquets de n'importe quelle source du réseau (à condition qu'ils lui parviennent via le serveur).

On retrouvera ce champ côté serveur, mais cette fois avec un rôle de sécurité à l'entrée du réseau : on y indiquera que tel Peer possède telle IP (un /32). Si un paquet de ce peer arrive avec une autre source, il sera rejeté. C'est ce qui garantit qu'un client ne peut pas usurper l'identité d'un autre, et donc l'intégrité du réseau. En fait, côté serveur, il vérifie que AllowedIPs du peer correspond bien à l'Address de l'Interface côté client.

Et le petit dernier : PersistentKeepalive = 25 c'est pour indiquer au client d'envoyer un paquet vers ce peer toutes les 25 secondes pour éviter que la connexion ne soit coupée par un pare-feu ou par le NAT (cela maintient le tunnel actif).

On va pouvoir prendre notre clé publique cliente et aller créer le Peer côté serveur cette fois.

Copions la clé publique, puis rendons-nous sur notre serveur Wireguard dans notre conf créée plus tôt (nano /etc/wireguard/wg0.conf )

[Interface]
Address = 10.100.0.1/24 # CIDR : 10.100.0.1 => 10.100.0.254
ListenPort = 51820
PrivateKey = taCléSecrête


[Peer]
PublicKey = CléPubliqueDuClient
AllowedIPs = 10.100.0.2/32

Ici on a juste ajouté la zone Peer avec la clé publique du client et son AllowedIPs en /32 l'IP unique que ce nœud est censé avoir. C'est ce qui sert de filtre : un paquet de ce peer portant une autre source sera rejeté.

Lancement du tunnel

On relance le serveur : wg-quick down wg0 && wg-quick up wg0 et on démarre la connexion côté client avec wg-quick up wg0.

Ce qui distingue un nœud "serveur" d'un nœud "client" ne tient qu'à leur configuration.

Le client connaît l'Endpoint du serveur et route tout son trafic vers lui (0.0.0.0/0), tandis que le serveur attend les connexions et identifie chaque client par son /32. WireGuard, lui, ne connaît que des peers.

Si tout s'est bien passé, essaye un curl ifconfig.me depuis ton client. Il devrait te retourner l'IP du serveur. En résumé, tu demandes une IP via le nom de domaine ifconfig.me qui lui te renvoie l'IP qui le contacte (c'est le rôle de ifconfig.me). Et bingo ! Il pense que c'est le serveur qui est à l'origine de la requête car il renvoie l'IP publique, or c'est faux ! C'est la magie du VPN "commercial" qu'on vient de refaire chez nous !

On peut mettre en pratique le passage dans le tunnel en limitant uniquement l'envoi des paquets à destination du VPN via cette config côté client : 

[Interface]
PrivateKey = TacléPrivéeDeTaMachineCliente
Address = 10.100.0.2/32
# DNS = 1.1.1.1

[Peer]
PublicKey = TaCléPubliqueDeTaMachineServeur
Endpoint = IPDeTaMachineServeur:51820
AllowedIPs = 10.100.0.0/24
PersistentKeepalive = 25

De cette manière, si on relance le tunnel avec wg-quick down wg0 && wg-quick up wg0 et que l'on retente un curl ifconfig.me alors on voit que ifconfig.me nous renvoie l'IP publique du client cette fois-ci. Avec AllowedIPs on décide ce qu'on fait passer par le VPN.

C'était juste pour le test, on va revenir à notre configuration précédente, avec tout le trafic dans le tunnel.

Si je ping 10.100.0.1, on voit que ça répond bien et que la configuration est bien remise sans erreur.

Le serveur D.N.S

Si on fait un VPN de ce type, c'est souvent pour avoir un réseau virtuel à soi et donc avoir des noms de domaine que l'on peut contacter (plus simple que 10.100.X.X …). Pour ça, il nous faut un Domain Name Server.

On retourne côté serveur et on installe un gestionnaire de DNS : dnsmasq.

Dnsmasq c'est un gestionnaire de DNS et de DHCP.

Pour rappel le DNS c'est le résolveur qui donne une correspondance entre un nom de domaine et son IP correspondante. Le DHCP c'est un serveur qui attribue une IP automatiquement à un appareil qui se connecte à un réseau.

apt install dnsmasq 

Par défaut dnsmasq va juste rediriger les requêtes vers le DNS du système, comme ça à l'installation il ne casse rien et son DHCP est désactivé (on aura pas besoin de lui d'ailleurs pour ce tuto).

Nous on va lui dire d'écouter les demandes de DNS sur notre interface wg0 spécifique.

On ouvre pour ça le fichier de config de dnsmasq : nano /etc/dnsmasq.conf et on rajoute les informations suivantes tout en bas du fichier (il y a beaucoup de commentaires):

interface=wg0

address=/mon-reseau.vpn/10.100.0.1

Très simple ici.

On indique via interface= le nom de l'interface sur laquelle agit dnsmasq. On peut ainsi faire cohabiter plusieurs résolveurs sur différentes interfaces.

address= c'est l'équivalent du /etc/hosts qui permet d'attribuer une IP à un nom de domaine.

On redémarre le service service dnsmasq restart puis on ajoute le port 53 à ufw sur l'interface wg0 (ufw allow in on wg0 to any port 53 && service ufw restart) afin que l'on puisse changer le DNS côté wireguard client, on aura ainsi un serveur DNS.

Côté client on re-change le DNS =

DNS = 10.100.0.1

On restart le tunnel côté client et on tente un nslookup sur "mon-reseau.vpn" (l'adresse enregistrée côté serveur).

On voit bien que le serveur DNS résout bien la conversion du nom de domaine en IP !

Alors ça n'a rien à voir avec un serveur VPN puisque là on parle de serveur DNS mais finalement c'est un package quand on cherche à faire nous-mêmes son VPN maison.

Lors d'un appel réseau, tu peux regarder le port 53 sur l'interface de ta machine également avec tcpdump pour vérifier : tcpdump -n -i wg0 port 53

(Si tu n'as rien, fais de même avec l'interface eth0 pour vérifier que les paquets ne passent pas).

Évidemment il faudrait brancher le nom de domaine à un service, et certains services nécessiteront un certificat HTTPS pour fonctionner (je pense notamment aux gestionnaires de mots de passe).

Pour ça tu auras trois possibilités :

• Un challenge HTTP
• Un challenge DNS
• Un certificat auto-signé

Le challenge HTTP c'est le challenge "classique" quand on veut un certificat délivré par let's encrypt.

C'est celui qu'on a vu aussi sur l'article lié à HTTPS. Pour ça il faut avoir un port 80 ouvert et accessible sur une interface publique (comme eth0 par exemple). Ici ce n'est pas notre cas.

Le challenge DNS c'est le petit frère du premier pour obtenir un certificat let's encrypt. Il fonctionne très bien pour le cas où le port 80 n'est pas accessible publiquement (ici c'est parfaitement notre cas). À l'aide d'API credentials de ton fournisseur de nom de domaine, certbot va pouvoir déposer un enregistrement TXT sur ton nom de domaine. Let's encrypt va ensuite vérifier cet enregistrement et confirme la possession. Facile à mettre en place.

Pour le certificat auto-signé, on se passe d'une autorité de certification car on n'a pas forcément un vrai nom de domaine. Je n'entrerai pas dans les explications car c'est technique (il faut générer ses propres clés de chiffrement, envoyer les certificats chez chaque client). C'est accessible, mais ce n'est pas le sujet de l'article ; retiens simplement qu'ainsi, on reste maître de toute la chaîne.

Et là maintenant qu'on a la possibilité d'avoir un DNS et un certificat HTTPS avec le challenge DNS, on peut faire des applications web complètement privées !

Comment ? Avec Nginx on peut lui faire écouter une interface spécifique dans le bloc server d'une conf.

J'ai installé nginx et fait une petite conf "static" :

server {
    listen 10.100.0.1:80;
    server_name _;

    location / {
        default_type text/plain;
        return 200 "Hello World\n";
    }
}

Concrètement, notre service n'écoute que sur l'ip privée du serveur et non plus sur l'ip publique.

Si on ouvre le port 80 alors je pourrai accéder directement au site privé.

On peut câbler le nom de domaine dans dnsmasq pour pointer le "mon-reseau.vpn" dessus et ça fonctionne également.

Si je fais ufw status numbered depuis le serveur, sur ce screen j'ai pris un peu d'avance sur l'intérêt du VPN sur les serveurs de travail :

La première règle ici c'est une protection de base, seulement l'IP (ici pixélisée) est autorisée sur l'interface publique (eth0) à se connecter en SSH.

C'est bien, mais à présent on pourrait carrément la retirer pour n'autoriser le SSH que depuis l'interface wg0 (comme ici sur les règles 4 et 7).

Tips : Si jamais le VPN plante je perds l'accès, mais avec les VPS on a accès à une console depuis l'interface de l'hébergeur, on peut aisément rajouter une règle d'accès pour contourner le problème.

Si on regarde bien, seulement le port du VPN est autorisé sur eth0 pour tous.

On a maintenant un VPS avec très peu de surface d'attaque sur l'interface publique (d'où l'intérêt de prendre un protocole VPN avec moins de lignes de code pour son core !)

De prime abord c'est certain que mettre en place un VPN n'est pas "simple" car il engendre beaucoup de concepts : VPN, DNS firewall, nginx etc … Mais si on veut construire une base solide, c'est un premier pilier.

On vit une période où c'est important (crucial même) de protéger nos données personnelles, celles de nos clients … et un VPN comme on vient de le voir permet d'assurer une certaine souveraineté dans la gestion de nos data. Pour vivre heureux, vivons cachés.