Plusieurs tunnels WireGuard sur macOS : options, routage et DNS

Tu peux utiliser plusieurs tunnels WireGuard sur un Mac avec un client ou une configuration en ligne de commande qui le permet. Pour que les deux réseaux distants fonctionnent, le client doit garder les deux tunnels actifs, macOS doit envoyer chaque destination par la bonne interface, et le DNS doit résoudre chaque nom correctement.

Ce guide couvre les réseaux IPv4.

Deux indicateurs « Connecté » ne suffisent pas. Vérifie l’accès à un vrai service sur chaque réseau pendant que les deux tunnels sont actifs.

État de l’app officielle au 6 octobre 2026 : l’app WireGuard pour macOS publiée, identifiée lors de notre vérification en amont, est la version 1.0.16, avec une politique d’un seul tunnel actif. Des correctifs multi-tunnel ont été proposés, mais notre vérification n’a trouvé ni fusion en amont ni version publiée qui les contienne. C’est une limite de cette version de l’application, pas une règle « un seul tunnel » du protocole WireGuard. Voir le code source de l’app officielle et sa fiche sur l’App Store pour macOS.

Choisir comment atteindre les deux réseaux

Plusieurs sections [Peer] dans une même configuration WireGuard, ce n’est pas la même chose que deux interfaces de tunnel indépendantes. Fusionner des configurations n’est pas un raccourci : une interface a une seule clé privée, et chaque pair distant doit être configuré pour la reconnaître.

Pour la ligne de commande, commence par les instructions d’installation de WireGuard, le manuel de wg-quick et l’implémentation pour Darwin. L’option en ligne de commande est décrite d’après sa documentation et son code source en amont ; la configuration Paart validée n’établit pas le comportement d’une installation en ligne de commande séparée.

Préparer deux routes qui peuvent coexister

Ce que fait réellement AllowedIPs

Deux décisions se prennent quand tu envoies du trafic :

1. Le système d’exploitation choisit une route et une interface pour l’adresse de destination.
2. Sur une interface WireGuard, AllowedIPs détermine quel pair reçoit cette destination. Il limite aussi les adresses source acceptées de ce pair pour le trafic entrant.

Les clients installent couramment des routes système à partir d’AllowedIPs ; wg lui-même ne pose pas ces routes. La distinction compte quand tu compares des clients ou que tu utilises un routage personnalisé. Voir l’explication du routage par clé cryptographique de WireGuard.

Pour un tunnel partiel ordinaire, inclus les destinations distantes dont tu as besoin plutôt que toutes les adresses d’Internet. Garde la configuration cohérente avec la politique de l’administrateur distant.

Un exemple simple à deux sites

Ce sont des réseaux et des noms fictifs, pas une configuration complète :

Le pair concerné aurait, dans A, AllowedIPs = 10.20.0.0/24 ; dans B, AllowedIPs = 10.30.0.0/24. Les deux serveurs DNS se trouvent dans leurs plages routées respectives.

Vérifie aussi les adresses et masques propres aux interfaces. Par exemple, des adresses de tunnel attribuées distinctes comme 10.200.1.2/32 et 10.200.2.2/32 évitent d’introduire le même sous-réseau connecté par les deux interfaces. Utilise les adresses attribuées par chaque administrateur, plutôt que de les changer arbitrairement.

Chaque point de terminaison WireGuard public doit rester joignable par une connexion sous-jacente qui fonctionne. Une route qui renvoie le transport chiffré du point de terminaison lui-même dans un tunnel inadapté peut empêcher les handshakes.

Chevauchements et routes par défaut

Si les deux sites contiennent un serveur en 192.168.1.10, une recherche de route ordinaire, fondée sur la destination, ne peut pas savoir de quel site tu parles. Des noms DNS différents qui renvoient cette même adresse ne lèvent pas l’ambiguïté.

Vérifie aussi les conflits avec ton réseau local. Un 192.168.50.0/24 distant entre en conflit avec le réseau local de notre exemple. Des routes plus spécifiques peuvent orienter certaines destinations, mais elles ne donnent pas un accès ordinaire et simultané à deux machines différentes qui ont la même adresse. Renuméroter, traduire les adresses sur une passerelle ou isoler un environnement par site sont des options d’architecture.

0.0.0.0/0 couvre toutes les destinations IPv4. Deux tunnels complets se disputent cette couverture large. Ne suppose pas que le dernier tunnel activé l’emporte toujours : les routes installées, leur portée et les politiques du client influent sur le résultat. Une route plus spécifique l’emporte en général dans le contexte de routage applicable ; examine le chemin réel.

Faire fonctionner le DNS indépendamment du routage

Le tunnel partiel choisit le chemin d’une adresse IP. Le split DNS choisit le résolveur d’un nom. Il te faut souvent les deux.

Dans notre exemple, les noms sous a.example.com doivent utiliser 10.20.0.53, les noms sous b.example.com doivent utiliser 10.30.0.53, et les autres noms doivent garder le résolveur local ou public approprié. Les deux serveurs DNS distants doivent eux-mêmes être joignables.

Un domaine de recherche et un domaine de sélection du résolveur sont deux choses différentes. Un domaine de recherche peut compléter un nom court comme server en server.a.example.com ; il ne prouve pas, à lui seul, que les requêtes pour ce domaine partent vers le serveur DNS de A. Utilise des noms complets (FQDN) pour vérifier deux sites.

Le code actuel des réglages réseau de l’app officielle pose une correspondance DNS universelle dès que des serveurs DNS sont configurés. Le script wg-quick pour Darwin utilise networksetup pour modifier les réglages DNS du service réseau et restaure les réglages sauvegardés au nettoyage. Aucun de ces deux mécanismes ne doit être supposé créer un DNS indépendant par domaine pour deux tunnels au seul motif que chaque configuration a une ligne DNS. Deux instances qui modifient des réglages partagés peuvent aussi se gêner quand l’une s’arrête. Vérifie le comportement du client choisi et de la version installée.

Sur macOS, scutil --dns affiche les résolveurs configurés, y compris les entrées délimitées (scoped) et supplémentaires. Lis leurs domaines, leurs serveurs et leur portée d’interface ; le premier résolveur listé n’est pas forcément celui utilisé pour chaque requête. Les applications qui utilisent leur propre mécanisme DNS peuvent se comporter autrement que le résolveur système.

Vérifier que les deux accès fonctionnent vraiment

Utilise un service dont tu sais qu’il est disponible sur chaque site. Les commandes ci-dessous illustrent les vérifications pour l’exemple fictif ; remplace les adresses, les noms et les ports par les tiens. Elles examinent le routage et tentent des connexions ; elles n’activent ni ne reconfigurent aucun VPN.

1. Établir une référence avec chaque tunnel seul

Avec A actif seul, vérifie sa route et un service connu :

route -n get 10.20.0.20
nc -vz -G 5 10.20.0.20 443

Recommence avec B seul :

route -n get 10.30.0.20
nc -vz -G 5 10.30.0.20 443

Lis l’interface dans chaque résultat de route et identifie à quel tunnel elle appartient. Une interface nommée utun peut appartenir à un autre VPN ; son nom seul n’est pas une preuve.

Une connexion TCP réussie établit que le port est joignable, pas que l’application est en bon état. Ouvre aussi le service réel. Le ping est facultatif : un hôte peut bloquer l’ICMP alors que son service fonctionne.

2. Recommencer avec A et B actifs ensemble

Relance les vérifications de route et de service sans couper aucun des deux tunnels. Garde une vraie session ouverte vers chaque site et confirme que les deux restent utilisables.

Vérifie, pour chaque pair, un handshake récent et du trafic reçu à l’aide des diagnostics du client. Génère du trafic avant d’interpréter un handshake ancien : un tunnel inactif n’a pas besoin d’échanger des paquets en permanence. Lorsque des interfaces WireGuard en ligne de commande sont visibles par wg, ces requêtes peuvent aider :

sudo wg show all latest-handshakes
sudo wg show all transfer

Ce n’est pas un moyen universel d’examiner les tunnels Network Extension gérés par une app. Une interface absente de wg ne prouve pas qu’une telle app est déconnectée.

3. Vérifier les noms via macOS et l’application

scutil --dns
dscacheutil -q host -a name server.a.example.com
dscacheutil -q host -a name server.b.example.com

Compare les adresses renvoyées avec les sites prévus. Ouvre ensuite chaque service par son nom d’hôte complet. Cela vérifie aussi le chemin de résolution réel de l’application et, pour HTTPS, la validation du certificat. Un DNS correct ne répare pas un certificat invalide.

dig @10.20.0.53 server.a.example.com peut tester directement le serveur DNS de A. Cela ne prouve pas que macOS ou ton navigateur a choisi ce résolveur. Des réponses en cache peuvent aussi masquer un problème de résolveur ; confirme le comportement avec des enregistrements connus et les applications que tu utilises vraiment.

4. Vérifier l’accès local, l’accès à Internet et l’arrêt d’un tunnel

Note les résultats attendus et observés plutôt que le seul « connecté ». Utilise les adresses IPv4 et les noms configurés pour cette installation.

Si la deuxième connexion casse quelque chose

Pour un tunnel qui n’établit jamais de handshake, voir Quand le tunnel ne se connecte pas. Pour le lien entre DNS et routes, voir DNS, routage et tunnel partiel.

Utiliser Paart pour cette configuration

Paart Client est une option graphique parmi d’autres pour garder des connexions WireGuard séparées actives sur un Mac quand leurs routes peuvent coexister. Les connexions simultanées sont disponibles en Gratuit comme en Pro. Le réseau avancé est disponible sur une connexion gratuite que tu choisis, et sur chaque connexion avec Pro.

Pour les noms propres à chaque site, son guide Split DNS explique comment choisir les noms internes et leur résolveur. Ce sont des instructions propres à Paart.

Il y a des limites opérationnelles. La simultanéité repose sur un comportement observé de macOS, pas sur une garantie d’Apple. Paart signale les chevauchements qu’il observe ; il ne décide pas quelle route en conflit doit l’emporter. Dans la configuration Paart validée sur Mac, l’arrêt d’une connexion a interrompu les autres, qui ont ensuite repris d’elles-mêmes. Prévois cette interruption dans ta façon de travailler.

Sur iPhone et iPad, Paart gère une seule connexion active à la fois. N’extrapole pas la configuration Mac à ces appareils.

Sources techniques

• WireGuard : interfaces et routage par clé cryptographique — protocole et choix du pair.
• Référence de wg — AllowedIPs et requêtes à l’exécution.
• Référence de wg-quick et source pour Darwin — mise en place des routes et gestion du DNS sur macOS. La source pour Darwin est la référence propre à la plateforme.
• Réglages réseau de wireguard-apple — routes et réglages DNS dans le client officiel.
• Historique de wireguard-apple et proposition de correctif multi-tunnel — distinguer une proposition, une fusion en amont et une app publiée.

Revue des sources : 6 octobre 2026. Plusieurs tunnels actifs, la coexistence des routes, le DNS et le comportement à l’arrêt et à la reprise ont été validés lors des tests de recette Paart sur Mac qui ont précédé. L’option en ligne de commande est documentée d’après les sources en amont, et non présentée comme faisant partie de ces tests.