Ce qu’un VPS doit autoriser avant d’héberger votre VPN

L’instance démarre, les installations de paquets réussissent et le service signale même un état actif, mais rien ne se connecte. Ce schéma est courant sur les serveurs privés virtuels, car un invité qui atteint confortablement internet peut malgré tout être incapable de créer l’interface que votre protocole exige. Cinq vérifications séparent un hôte capable de servir un tunnel d’un hôte qui semble seulement prêt, et la première vérification qui échoue explique généralement tout ce qui suit. Chacune est peu coûteuse à exécuter et se termine par une décision plutôt que par une note.

Confirmez l’interface dont le protocole a besoin

OpenVPN sur TUN a besoin du périphérique de caractères et du module noyau derrière lui ; WireGuard a besoin de son propre support noyau ou d’une implémentation en espace utilisateur avec des attentes cohérentes. Les conteneurs gérés peuvent partager un noyau hôte qui n’expose jamais le périphérique, et certaines plateformes interdisent purement et simplement la création d’interfaces de tunnel, quel que soit ce qui est installé.

Testez la capacité au lieu de lire une page d’assistance, car les étiquettes marketing changent plus vite que les limites sous-jacentes. Une liste de fonctionnalités écrite pour une offre peut ne pas décrire le noyau sur lequel l’invité s’exécute réellement. Deux commandes courtes répondent à la question pour les protocoles courants, et toutes deux nettoient derrière elles. Les commandes ci-dessous ne créent rien de permanent et sont supprimées immédiatement.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Un refus sur la première paire signifie que TUN n’est pas disponible et que le mode par défaut d’OpenVPN ne peut pas démarrer ; un refus sur la dernière ligne signifie que l’interface noyau de WireGuard manque. La documentation du noyau sur TUN/TAP décrit le périphérique que la première vérification exerce. Aucun des deux échecs n’est réparé en réinstallant le paquet VPN.

Rappelez-vous que le chemin entrant a deux propriétaires

Les règles réseau du fournisseur et le pare-feu de l’invité sont des systèmes distincts, et le trafic doit survivre aux deux. Un écouteur lié sur l’invité ne signifie rien si le groupe de sécurité du fournisseur rejette le port, et une règle ouverte du fournisseur ne fait rien si l’invité rejette le paquet. Vérifiez l’écouteur, puis les règles de l’invité, puis le panneau du fournisseur, dans cet ordre, et confirmez le protocole ainsi que le numéro de port. Sauter d’abord au panneau du fournisseur est la façon dont les gens finissent par ouvrir une plage dont ils n’avaient pas besoin.

UDP est la victime habituelle : de nombreuses plateformes autorisent TCP par défaut et traitent les règles UDP comme une entrée séparée. Si l’instance se trouve derrière le NAT du fournisseur au lieu de détenir une adresse publique, le transfert de ports côté fournisseur devient une troisième configuration à concilier.

Planifiez le chemin de retour, pas seulement la sortie

Le service en tunnel complet nécessite le transfert activé, un schéma de traduction ou de routage pour le trafic des clients et un chemin de retour qui atteint le pool de clients. Ouvrir un écouteur n’en fournit aucun. Un tunnel qui s’établit mais ne transporte aucun trafic utile échoue généralement ici plutôt qu’à l’authentification. Traitez une poignée de main réussie comme le début du diagnostic, non comme sa fin.

Écrivez le plan comme trois décisions concrètes : quelle plage source les clients reçoivent, comment leur trafic sort vers internet et comment les réponses retrouvent leur chemin. Confirmez ensuite que le noyau est d’accord avec le plan avant de tester un client, afin qu’un écart silencieux ne soit pas pris pour un défaut côté client.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Tranchez la question IPv6 explicitement

IPv6 arrive par plusieurs mécanismes qui se comportent différemment pour une passerelle : une adresse sur l’instance, un préfixe routé ou rien du tout. Seul un préfixe routé permet au serveur de remettre des adresses aux clients de la manière habituelle. Supposer qu’une adresse IPv6 fonctionnelle sur l’hôte implique un préfixe client utilisable est une erreur qui se manifeste plus tard sous forme de connectivité à moitié cassée. C’est le genre de défaut qui survit à tous les tests effectués uniquement en IPv4.

Si le fournisseur ne route aucun préfixe, décidez si le tunnel est uniquement IPv4 et si les clients doivent en être informés. Une absence documentée est plus sûre qu’une configuration partielle qui envoie silencieusement les destinations IPv6 dans un trou noir pour les utilisateurs connectés.

Prouvez-le depuis un client externe

L’état local du service décrit un processus sur un hôte. Le test utile est un client autorisé sur un autre réseau, qui se connecte avec le profil que vous comptez distribuer, atteint ensuite une application et résout un nom. Reconnectez-vous une fois également, car un tunnel qui ne fonctionne qu’à la première tentative échoue à l’exigence qui compte le plus en pratique.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Gardez les bases opérationnelles à côté du test : de la place pour les mises à jour, des journaux bornés, un accès administratif qui ne dépend pas du tunnel, une console de récupération et une note sur ce qui arrive aux profils clients lorsque l’instance est reconstruite et que son adresse publique change. Si une interface ou un modèle de transfert requis n’est tout simplement pas disponible, aucun changement côté client ne l’apportera, et la prochaine étape honnête est un autre type d’instance plutôt que davantage de configuration.