Hébergement web ou VPS : votre offre peut-elle faire tourner un serveur VPN ?

Un site qui fonctionne prouve qu’un fournisseur peut servir du HTTP, pas que vous contrôlez une machine. Entre une offre mutualisée, une application gérée et un serveur autogéré, il existe un large écart dans ce que le compte peut faire au réseau. Décidez de quel côté de cet écart votre conception VPN a besoin avant de payer une année de plus. Quatre capacités séparent les deux, et aucune n’apparaît sur une liste de prix.

Ce que chaque offre donne réellement

La comparaison utile n’est ni le prix ni la taille du disque, mais l’autorité. Demandez ce que le compte peut lancer, à quelles fonctions du noyau il accède, quels ports acceptent le trafic entrant et si le trafic admis peut ressortir ailleurs.

La plupart des produits d’hébergement se rangent en trois formes, et seule la dernière est un serveur à usage général :

Le compte shell est la source habituelle de confusion. Le transfert de fichiers ou l’accès à des tâches planifiées peut ressembler à de l’administration alors que le processus est confiné à un répertoire et à un petit ensemble d’opérations autorisées.

Quatre capacités qui décident de la réponse

Prenez-les dans l’ordre, car un échec à la première étape rend le reste sans objet.

D’abord, le logiciel doit tourner comme un processus de longue durée qui survit à la maintenance. Ensuite, l’implémentation doit pouvoir créer son interface virtuelle ; sous Linux, cela veut généralement dire ouvrir /dev/net/tun avec l’autorisation administrative pertinente, comme la documentation du noyau sur TUN/TAP le décrit, même si toute conception VPN n’utilise pas ce périphérique. Troisièmement, les clients doivent atteindre l’écouteur à l’adresse publique, le transport et le port que vous prévoyez, et un proxy inverse web qui accepte HTTPS ne dit rien d’un protocole sans rapport sur le même numéro. Quatrièmement, le trafic admis doit pouvoir continuer, avec des routes, du transfert et toute traduction réellement prise en charge.

Les conditions d’utilisation côtoient ces quatre points et ne sont pas techniques du tout. Les quotas de trafic illimité décrivent en général des requêtes web, pas un tunnel qui transporte les téléchargements d’autrui. Lisez la section sur l’usage acceptable avant de concevoir autour, et gardez l’accès de secours en tête pour le jour où le service ne démarrera pas.

Où un compte de site web s’arrête

Une offre de site web exécute généralement votre code dans un environnement d’exécution géré avec un point d’entrée fixe. Même lorsqu’un binaire de tunnel est présent, le processus peut manquer de l’autorisation d’ouvrir un nœud de périphérique, de lier un port privilégié ou de modifier la table de routage. Ces restrictions sont le produit, pas un oubli.

C’est pourquoi une extension qui promet un VPN se révèle souvent un proxy vers ailleurs. Si le compte actuel n’offre que des contrôles de site web, la démarche honnête est un serveur séparé, pas la recherche du module qui déverrouille l’autorité manquante.

Quand un seul hôte doit exécuter les deux

Le partage est possible et parfois judicieux, mais traitez-le comme une décision de sécurité et non comme une commodité. Une application web avec un formulaire d’envoi côtoie des identifiants de tunnel et une socket de contrôle, et une faille dans l’une atteint l’autre. Des comptes séparés, des unités de service séparées et des systèmes de fichiers séparés réduisent cette exposition sans acheter une seconde machine.

La concurrence pour les ressources compte tout autant. Une sauvegarde par le tunnel et un processus web occupé se disputent la même liaison montante et le même disque, et la panne ressemble à un site lent plutôt qu’à un tunnel saturé. Décidez quelle charge l’emporte avant l’incident, et plafonnez le tunnel pour que le site continue de répondre.

Aucune des deux dispositions n’est isolée du seul fait que les deux services tournent. La capacité à les héberger ensemble est le début de la conception, et le travail d’isolation est ce qui la rend défendable.

Tranchez sur un hôte d’essai avec quatre commandes

Avant de migrer, louez la plus petite instance du produit visé pendant une heure et testez les quatre capacités directement. Deviner à partir d’un tableau de fonctions gaspille moins d’argent qu’une année de la mauvaise offre, mais bien plus de temps.

Exécutez celles-ci sur l’hôte d’essai et lisez les échecs comme des réponses, non comme des obstacles :

ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head

Les deux premières lignes indiquent si un périphérique de tunnel peut exister. La troisième signale si l’hôte peut transmettre des paquets, et la quatrième montre ce qui écoute déjà pour qu’un conflit de port soit repéré tôt. Un fournisseur qui échoue à la deuxième ligne peut tout de même prendre en charge une implémentation en espace utilisateur : nommez le mécanisme dont vous avez besoin, pas la catégorie de produit, lorsque vous interrogez son support.