Comment fonctionne VpnHood
L'application VpnHood achemine le trafic de l'appareil dans un tunnel chiffré vers votre serveur, qui le transmet à Internet. Suivez ce parcours étape par étape.
Sur l'appareil
L'application capture le trafic de l'appareil via la carte réseau virtuelle fournie par le système aux VPN. Elle achemine trois types de trafic : TCP, UDP et ping. Tout autre paquet est ignoré.
Le Split tunneling est également géré sur l'appareil. Le trafic exclu par l'utilisateur (par application, pays, domaine ou adresse) va directement sur Internet sans passer par votre serveur. En savoir plus sur le Split tunneling.
L'application configure aussi le DNS de l'appareil : selon les serveurs choisis par l'utilisateur ou ceux de votre serveur (les DNS publics de Google par défaut). Les requêtes restent dans le tunnel, même si le Split tunneling contourne le site concerné.
Le tunnel
Par défaut, l'application se connecte au port TCP de votre serveur (443 sauf modification) via TLS, le chiffrement utilisé par HTTPS. Elle communique avec lui via des messages WebSocket, comme une application web. L'intégralité du tunnel est chiffrée par TLS, du tout premier au tout dernier octet.
Avant d'envoyer la moindre donnée, l'application vérifie le certificat de votre serveur. Elle valide soit un certificat émis par une autorité de certification pour le nom figurant dans la clé d'accès, soit l'empreinte exacte enregistrée dans la clé. C'est pourquoi un serveur peut débuter avec un certificat auto-signé, et que les clés restent valides lors du renouvellement d'un certificat approuvé.
Dans les paramètres de protocole de l'application, l'utilisateur peut choisir UDP ou QUIC à la place de TCP. UDP envoie les paquets de l'appareil vers le port UDP de votre serveur sous forme de datagrammes chiffrés en AES-GCM. QUIC achemine les mêmes messages que TCP via QUIC, en intégrant son propre chiffrement TLS. Votre serveur indique à chaque application les options disponibles ; si le protocole choisi n'est pas pris en charge (par exemple derrière un proxy inverse), l'application bascule automatiquement sur TCP. Toutefois, si un réseau bloque le port UDP, une application configurée sur UDP ne recevra plus aucun trafic tant que l'utilisateur ne repasse pas sur TCP.
Toute requête adressée à votre serveur qui ne provient pas d'une application VpnHood renvoie simplement une erreur HTTP, exactement comme un site web nécessitant une connexion.
TCP : sous forme de paquets ou d'une requête par connexion
Par défaut, l'application achemine le trafic TCP sous forme de paquets à travers le tunnel, et votre serveur les transmet via sa propre interface réseau, à la manière d'un routeur. C'est la méthode la plus rapide et la plus économe en batterie.
En Cloak Mode, l'application termine chaque connexion directement sur l'appareil et demande à votre serveur d'en ouvrir une nouvelle via une requête dédiée. Votre serveur se connecte lui-même au site web et relaie les données dans les deux sens. Pour le réseau, ce trafic ne ressemble plus à un long tunnel continu, mais à des requêtes indépendantes issues d'un navigateur. Cela utilise un peu plus de batterie et de bande passante, et l'application réutilise chaque connexion terminée pour la requête suivante.
L'application fonctionne également ainsi sans le Cloak Mode : lorsque votre serveur ne dispose pas de sa propre interface réseau (comme sous Docker) ou lorsqu'un utilisateur applique le split tunneling par domaine.
UDP et ping
Le trafic UDP circule sous forme de paquets à travers le tunnel, quel que soit le protocole utilisé par l'application. Il en va de même pour le ping, à l'exclusion de tout autre trafic similaire : l'application relaie les requêtes d'écho et ignore les autres paquets ICMP. Votre serveur les achemine via son interface réseau ou, s'il n'en a pas, via ses propres sockets en exécutant lui-même le ping pour le compte de l'appareil.
Côté serveur
Installé sur Linux, VpnHood! SERVER dispose de sa propre interface réseau et achemine les paquets vers Internet via NAT, comme un routeur. Un conteneur Docker ne disposant pas d'une telle interface, le serveur y fonctionne alors comme un proxy : les applications envoient le trafic TCP à raison d'une requête par connexion, et le serveur ouvre lui-même chaque connexion, socket UDP et ping. Les applications s'y adaptent automatiquement.
Dans les deux cas, il ne transmet pas le trafic vers ses propres adresses ni vers les réseaux locaux auxquels il est connecté.
Il nécessite l'ouverture de son port TCP, ainsi que du port UDP défini lors de son premier lancement pour les applications configurées sur UDP. QUIC est désactivé par défaut. Consultez Configurer les adresses IP de votre serveur pour savoir comment retrouver le port UDP.
Un serveur géré communique avec VpnHood! MANAGER via HTTPS sur access.vpnhood.com pour valider chaque clé lors de la connexion d'une application et enregistrer l'utilisation de chacune. MANAGER ne se connecte jamais directement au serveur, et les applications ne communiquent jamais avec MANAGER. MANAGER peut également rediriger une application vers un autre serveur du groupe. Un serveur autonome valide quant à lui les clés directement à partir de ses propres fichiers.
Contenu d'une clé d'accès
Une clé d'accès contient tout ce dont l'application a besoin pour identifier votre serveur et s'y connecter en toute sécurité : son nom de domaine et ses adresses, son port, le nom ou l'empreinte de son certificat, ainsi que le secret de la clé elle-même. Elle est encodée, mais non chiffrée : quiconque dispose d'une clé peut y lire les adresses de votre serveur et s'y connecter. Ne partagez vos clés qu'avec vos utilisateurs de confiance, et consultez Empêcher le blocage de l'adresse IP de votre serveur pour comprendre les risques liés à l'exposition d'une adresse.
