Créer son propre serveur VPN pour chiffrer vos activités en ligne gratuitement : c’est l’une des larges possibilités qu’offre le Raspberry Pi et que nous vous proposons de découvrir ici. Un projet abordable et facile à réaliser, qui vient compléter notre top 10 des meilleurs projets pour débuter avec un Raspberry Pi.
Merci pour ce petit tuto bien documenté de l’installation d’openvpn sans grosses lignes de commandes, il devrait être apprécié des néophytes.
J’ajouterai que écouter sur le port 443 plutôt que 1194 permettra de se connecter à son VPN maison plus facilement. Certains réseaux wifi publics ou en entreprise appliquent un filtrage des connexions, en particulier sur ces ports de VPN. Se faire passer un simple flux HTTPS se révèlera parfois bien utile.
1 « J'aime »
Suis pas sur d’avoir compris en terme de connexion. Le raspberry se connecte en USB sur la box et ensuite ? Le wifi est intégré c’est ça ?
Non.
Le Raspberry pi est connecté à la box de manière classique, en Ethernet ou Wifi.
Et il permet de se connecter depuis l’extérieur, dans le but de par exemple accéder à son réseau domestique depuis une connexion à distance (exemple : se connecter à son PC resté à la maison avec un ordi portable depuis une chambre d’hôtel avec un wifi partagé dans l’hôtel).
Le gros avantage c’est que la connexion établie par le VPN (ici OpenVPN) est chiffrée et ne peut pas être espionnée.
1 « J'aime »
« pour des raisons de sécurité il est préférable de conserver le protocole UDP, moins rapide mais beaucoup plus fiable. »
Il est recommandé d’exploiter UDP pour ne pas perdre de temps justement, aucun problème de sécurité par ailleurs, on garde TCP uniuement lorsqu’il est impossible d’exploiter UDP, par exemple avec un nat au conntracking mal fonctionnel.
Autre point, à matériel égal wireguard offrira facilement 20% de débit supplémentaire (test perso sur un pi3b), voir les nombreux benchs wireguard VS openVPN.
Il de plus intégré au noyau Linux.
2 « J'aime »
Le projet est très bien et c’est un début de sécurisation. J’adore ce genre de projets et je m’amuserais surement à le faire. Le seul point noir que je vois, mais c’est relatif aux besoins / exigences : notre adresse IP publique n’est pas « masquée ». PiVPN ou pas, l’adresse de connexion sera toujours celle de la box (comme mentionné dans l’intro)
2 « J'aime »
Ha ok merci Juju. Je n’avais effectivement pas tout compris 
Il me semble que UDP ne fait pas de contrôle (pas d’acquittement de réception)alors que TCP oui (attente et réémission des packets) et donc UDP est plus rapide que TCP.
Oui, mais en local, cela ne servira pas à grand chose :
En IPV4, c’est l’adresse de la box qui sera visible sur Internet, passage par le Raspi ou non.
En IPV6, par contre, je ne sais pas, ne m’étant pas encore suffisamment penché sur ce protocole.
Bonjour,
Merci pour votre article.
Je possède un abonnement Cyberghost et j’essaie de faire un serveur VPN « maison »…
Y’a-t-il un moyen de combiner les 2 ou est-ce l’un ou l’autre ?
Merci.
Oui, l’intérêt de cette solution c’est justement de te connecter à Internet (ou à ton réseau local) comme si tu était chez toi quand tu n’es pas chez toi (par exemple, comme indiqué dans l’article, quand tu utilises un réseau Wi-Fi public, qui n’est pas forcément très sécurisé). Donc l’IP publique visible, ça sera celle de ta box. Ça n’a aucun intérêt d’utiliser ça quand tu es chez toi, dans ce cas ça ne fait qu’ajouter une couche inutile entre toi et ta box.
Exactement, pas d’ack. Et si le protocole client au dessus (à l’intérieur) a besoin de « fiabilité » il fonctionnera lui même sur un mode connecté.
QUIC | http/3 lâche par exemple ce mode connecté TCP.
En IPv4 le serveur va nater, sauf si tu le configures pour disposer d’un subnet routable. Mais il faut alors que ta box dispose de la route, et là c’est rarement possible… Par exemple certains y arrivent sur livebox via la librairie sysbus.
En IPv6 à mort le NAT ! Logiquement on utilise DHCPv6-Prefix-Delegation pour demander un /64 à la box, qui va l’attribuer et créer automatiquement la route associée. Pas belle la vie ? Encore faut-il que les box implémentent cette fonction, la RFC sur les CPE est en cours de mise à jour pour couvrir ce genre de chose.
Se faire son propre serveur VPN à domicile, c’est envisageable quand on a la fibre ou une connexion avec un très haut débit montant.
Si on n’a que l’ADSL comme moi 
avec 1 Mbit/s de débit montant, ça ne vaut pas le coup, la lenteur de la connexion VPN sera exaspérante.
Tout depend ce que tu fais, pour plein d’utilisations ca suffit Pour de la vidéo c’est moyen, mais on y arrivait bien avant
Aucun soucis pour masquer l’adresse IP Publique de ton VPN propre, en utilisant l’IP publique d’un serveur VPN Windscribe par exemple et en routant un port particulier 
C’est ce que je fais via une instance PFSense, mais ce n’est pas a la portée de tout le monde…
@Matthieu Legouge
Je pense qu’il y a une erreur :
« il est préférable de conserver le protocole UDP, moins rapide mais beaucoup plus fiable. »
Le protocole UDP est plus rapide et moins fiable que TCP.
Par contre il est effectivement recommandé.
1 « J'aime »
Merci, j’avais effectivement inversé les deux
Donc l’IP publique visible, ça sera celle de ta box. Ok mais à ce moment là quel est l’intérêt ?
Les sites web visités seront tout de même masqués ? Par exemple on saura que je suis connecté à internet avec mon IP mais pourra t’on voir ce que je fais et quels sites je visite ?
L’intérêt d’un VPN n’est pas juste de masquer l’adresse IP aux sites que l’on visite.
Personnellement, j’ai un VPN sur mon Raspberry Pi, VPN qui me permet surtout :
- D’accéder à mon réseau perso depuis n’importe où tant que j’ai une connexion Internet, pour par exemple utiliser le partage de fichiers Windows ou d’utiliser RDP, sans avoir à exposer ce service au niveau d’internet.
- De me servir du VPN comme une passerelle pour chiffrer la connexion entre mon point d’accès (PC portable relié à un wifi public par exemple) et chez moi, ce qui permet de rendre inexploitables (car chiffrées) d’éventuelles données qui pourraient être interceptées (dans la très grande majorité des cas, wifi public = données non chiffrées au niveau du wifi).