Routeur ou ordinateur séparé comme serveur VPN : comment choisir

Un routeur comme un petit ordinateur peuvent terminer un VPN, et la décision tient rarement au débit. Elle tient à qui applique la mise à jour à deux heures du matin, à ce qui s’arrête aussi quand cette boîte redémarre, et à la possibilité d’atteindre encore une console quand c’est le tunnel qui a lâché. Répondez à ces trois questions pour chaque candidat, et le choix se fait souvent de lui-même. La procédure ci-dessous transforme la comparaison en une courte liste de points à vérifier avant de vous engager.

Commencez par ce qui doit rester en marche quand le tunnel tombe

La panne pour laquelle il faut concevoir est celle où le processus VPN meurt et où vous devez malgré tout atteindre l’hôte. Sur un routeur, le tunnel et la passerelle internet partagent le même sort : un mauvais changement de configuration peut faire tomber les deux, et le chemin de reprise est souvent une réinitialisation physique. Sur un ordinateur séparé, la passerelle continue de fonctionner et l’hôte reste joignable sur le LAN. Lequel de ces résultats vous pouvez tolérer décide plus que n’importe quelle liste de fonctionnalités.

Écrivez la réponse sous forme de phrase : si l’hôte VPN redémarre, que perd le foyer ou le bureau ? Si la réponse inclut tout l’accès à internet, vous avez accepté un domaine de panne partagé et vous devriez le dire exprès plutôt que le découvrir plus tard.

Un second service sur le même appareil n’est pas une console de secours. Il partage l’alimentation, le micrologiciel et le compte administrateur.

Comptez les surfaces de maintenance que chaque hôte ajoute

Un routeur apporte un micrologiciel du constructeur avec son propre rythme de publication, et la fonction VPN est généralement un module au sein d’une image bien plus vaste. Un ordinateur apporte un système d’exploitation, un gestionnaire de paquets, un noyau et un ensemble de services qui vous appartiennent désormais. Les deux ont besoin de correctifs, et la vraie question est le rythme que vous tiendrez une fois la nouveauté retombée.

Sur un hôte Linux, rendez ce rythme visible au lieu d’espérer qu’il tienne. systemctl list-timers montre les tâches planifiées et apt list --upgradable montre ce qui attend. Notez quelles mises à jour exigent un redémarrage, car un hôte VPN qui redémarre est une panne de service, sauf si vous l’avez planifié. Un routeur sans chemin de mise à jour automatique a plutôt besoin d’une entrée d’agenda, ce qui est un contrôle plus faible mais honnête.

Comptez aussi les comptes. Chaque connexion administrateur supplémentaire sur l’hôte VPN est une identification de plus à faire tourner et un chemin de plus à révoquer.

Suivez le chemin du réseau privé, pas l’étiquette sur la boîte

Les clients se moquent de l’endroit où tourne le serveur ; ce qui les intéresse, c’est que les préfixes protégés soient joignables et qu’un chemin de retour existe. Placez le serveur là où le routage est le plus simple, ce qui veut généralement dire directement sur le segment qui porte les ressources. Un ordinateur derrière le routeur a toujours besoin d’une redirection de port, et les ressources de ce LAN ont toujours besoin d’une route de retour vers le sous-réseau du tunnel.

Vérifiez le transfert sur l’hôte avant d’accuser le client. sysctl net.ipv4.ip_forward devrait indiquer 1, et nft list ruleset ou iptables -S montre si l’interface du tunnel a le droit de transférer. Une règle masquerade manquante ressemble exactement, côté client, à un tunnel cassé.

Décidez aussi ce que le tunnel ne doit pas atteindre. Un serveur placé sur le routeur voit tous les sous-réseaux que ce routeur achemine, ce qui dépasse souvent l’intention de la politique d’accès. Sur un hôte séparé, la même isolation est à une règle de pare-feu, et le rayon de dégâts d’un client compromis est plus petit. La description de la passerelle IPsec du RFC 7296 traite cela comme une question de routage et de politique, pas de matériel, et aucune des deux formes n’est plus sûre par défaut tant que la politique n’est pas écrite.

Gardez une console de récupération qui ne dépend pas du tunnel

La console qui sert à réparer le VPN ne peut pas être le VPN. Gardez une adresse LAN, une console série ou une console du fournisseur qui fonctionne pendant que le tunnel est tombé, et utilisez-la au moins une fois avant d’en avoir besoin. Un chemin hors bande qui n’a jamais été exercé est un plan et non une capacité.

Sauvegardez la configuration là où l’hôte lui-même ne peut pas l’effacer. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn capture les clés et les définitions de service, et la copie doit quitter la machine. Incluez les règles de pare-feu et l’inventaire des clients, car restaurer des clés sans la liste des pairs produit un serveur que personne ne peut rejoindre. Stockez l’archive là où la console de récupération peut l’atteindre.

Écrivez l’étape de retour arrière dans la même note. Un changement de configuration sans retour arrière documenté est un changement permanent, quelle qu’ait été l’intention.

Vérifiez le choix par un redémarrage et une mise à jour

Testez l’installation telle qu’elle échouera, pas telle qu’elle fonctionne un bon jour. Redémarrez l’hôte, appliquez une mise à jour en attente et confirmez que le tunnel revient sans étapes manuelles.

Après le redémarrage, vérifiez les trois points qui cassent le plus souvent. systemctl is-active wg-quick@wg0 indique si l’interface est revenue, ss -lunp montre si quelque chose écoute sur le port, et wg show liste un pair avec une poignée de main terminée. Un service actif sans poignée de main signifie que le pare-feu ou la route est en cause, pas le démon.

Répétez la vérification depuis un client sur un autre réseau que celui depuis lequel vous avez configuré. Si le tunnel survit à un redémarrage, à une mise à jour et à un changement de réseau client, le choix de l’hôte est réglé pour l’instant. Sinon, la pièce manquante est généralement une étape documentée plutôt qu’une autre boîte.