Peut-on utiliser deux VPN sur le même serveur domestique sans conflits de routage ?

Oui, deux VPN peuvent partager un serveur domestique lorsque leurs adresses, routes, paramètres par défaut, règles de pare-feu et chemins de retour sont explicitement séparés.

Les problèmes commencent lorsque les deux tunnels revendiquent le même sous-réseau privé, installent des routes par défaut concurrentes, utilisent des identifiants d’interface ou de table en double, réécrivent le DNS globalement ou envoient les réponses par un tunnel différent de celui de la requête. Une conception sûre attribue d’abord à chaque VPN un but distinct — comme l’accès à distance et la sortie commerciale — puis teste un tunnel seul, l’autre seul, et les deux ensemble tout en enregistrant la route active pour chaque charge de travail.

Définir la fonction de chaque VPN avant de démarrer les deux

Notez quels clients, destinations, protocoles et applications appartiennent au VPN A et au VPN B. Les conceptions courantes incluent un serveur WireGuard entrant pour l’accès distant au NAS et un VPN commercial sortant pour certains conteneurs.

La communauté OpenVPN indique que plusieurs tunnels peuvent fonctionner simultanément, mais chaque instance nécessite un adaptateur virtuel séparé, un port et un sous-réseau unique non chevauchant.

Si les deux tunnels sont destinés à transporter tout le trafic du serveur, décidez lequel est principal et lequel est de secours ou imbriqué. Deux politiques indépendantes « tout envoyer » ne peuvent pas contrôler les mêmes paquets sans un ordre explicite.

Maintenir des sous-réseaux uniques pour les tunnels et les LAN distants

Comparez les pools d’adresses des deux tunnels, chaque LAN distant annoncé, le LAN domestique, les réseaux de conteneurs et les réseaux clients distants courants. Aucune destination ne doit référer à deux endroits différents dans le même contexte de routage.

Le HOWTO d’OpenVPN explique que les réseaux privés qui se chevauchent créent une ambiguïté de routage car le système ne peut pas savoir quel site une adresse dupliquée représente. Des préfixes distincts éliminent l’ambiguïté des adresses chevauchantes avant que les métriques de route ne soient prises en compte.

Renumérotez un tunnel ou un LAN si possible. Si le chevauchement est inévitable, utilisez une traduction NAT contrôlée, des espaces de noms réseau séparés, des VRF ou des tables de politique plutôt que de compter sur le tunnel qui démarre en dernier.

Empêcher que les deux VPN remplacent la route par défaut

Inspectez la table de routage sans VPN, avec seulement VPN A, seulement VPN B, et avec les deux actifs. Enregistrez les routes par défaut, les routes par défaut fractionnées telles que 0.0.0.0/1 et 128.0.0.0/1, les métriques et les routes hôtes vers les deux serveurs VPN.

Un ticket OpenVPN note que rediriger la passerelle par défaut via plusieurs VPN simultanés n’est pas utile à moins que l’administrateur ne décide de routes par défaut concurrentes.

Désactivez l’installation automatique de la route par défaut sur le tunnel qui doit servir uniquement certains sous-réseaux sélectionnés. Conservez une route vers chaque point de terminaison du fournisseur VPN via le WAN sous-jacent afin que la mise en place du second tunnel n’envoie pas sa connexion de contrôle dans le premier.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utiliser le routage par politique pour le trafic spécifique à la source ou à l’application

Créez des tables de routage séparées pour le trafic qui doit sortir par chaque VPN, puis sélectionnez-les par sous-réseau source, adresse de conteneur, marque de pare-feu, utilisateur ou interface. Gardez la table principale pour le trafic ordinaire du serveur domestique.

Un exemple Unix et Linux de connexions VPN multiples recommande des règles pour que le trafic de chaque interface utilise sa propre table de routage et revienne par le modem ou tunnel correct.

Ajoutez les règles dans un ordre documenté et testez la recherche de route pour des paires source-destination représentatives. Une table de politique sans le LAN connecté et les routes de retour peut isoler l’application sélectionnée du reste du réseau domestique.

Aligner NAT, pare-feu, DNS et chemins de retour

Pour chaque VPN, documentez quelle interface transmet le trafic, quelles adresses source sont masquées, quels sous-réseaux entrants sont autorisés et quel résolveur DNS les clients reçoivent. Appliquez le NAT uniquement là où le côté distant n’a pas de route de retour.

Un cas Server Fault routant des clients WireGuard via une connexion OpenVPN explique que le trafic peut nécessiter un masquage car le VPN distant ne connaît que l’adresse du client OpenVPN, pas le sous-réseau client WireGuard distant.

Vérifiez que les réponses sortent par le tunnel qui a reçu ou initié la session. Des réponses asymétriques peuvent faire paraître un VPN connecté alors que le trafic TCP, DNS ou SMB échoue silencieusement.

Tester les pannes et l’ordre de redémarrage avant la mise en production

Démarrez VPN A, puis B ; inversez l’ordre ; redémarrez chaque service indépendamment ; et redémarrez le serveur. Enregistrez les routes, règles, DNS, état du pare-feu et si l’accès à la gestion à distance existante survit.

Le guide ZimaSpace pour réparer une route VPN manquante fournit la séquence de récupération lorsqu’un tunnel capture accidentellement le trafic de l’autre.

La configuration est sûre uniquement lorsque les deux tunnels se reconnectent dans n’importe quel ordre supporté, que chaque charge de travail suit son chemin prévu, que le DNS reste prévisible et que la désactivation d’un VPN ne bloque pas le trafic de gestion. Gardez une console locale ou un chemin de récupération non VPN avant d’automatiser les deux services au démarrage.