Configurer des serveurs VPN par agent (VPN direct)

Un VPN direct de centrale est un tunnel dédié entre le Mirox-Agent d'une seule centrale et le routeur de cette centrale — l'outil idéal lorsqu'une centrale exploite déjà son propre VPN, ou lorsque vous souhaitez que Mirox héberge un VPN auquel le routeur de la centrale se connecte. Contrairement au VPN personnel, qui fournit à chaque utilisateur un profil unique atteignant toutes ses centrales autorisées, un VPN direct est un tunnel d'infrastructure propre à une centrale que vous configurez une seule fois et sur lequel transite tout le trafic de l'équipe pour cette centrale.

Vous configurez les VPN directs depuis la page Réseau d'une centrale, sous l'onglet VPN du site. La page Réseau comporte cinq onglets : Vue d'ensemble (le pipeline de connexion), Équipements réseau, VPN du site (ce guide), Peers (affiché lorsqu'un VPN hébergé compte plus d'un site connecté) et Journal d'accès.

Ouvrir dans Mirox

Ouvrez l'onglet VPN du site de la centrale. Dans l'application, il s'agit de la page Réseau de la centrale, onglet VPN du site.

Quand utiliser un VPN direct

Optez pour un VPN direct lorsque la connectivité de la centrale ne correspond pas au modèle standard du VPN personnel :

Le routeur de la centrale héberge déjà son propre serveur VPN. Vous disposez d'un fichier de configuration (WireGuard .conf) ou d'un profil OpenVPN (.ovpn) et souhaitez que Mirox s'y connecte.
Le routeur de la centrale peut uniquement initier des connexions sortantes, pas en accepter d'entrantes. Mirox héberge le point d'accès VPN et le routeur s'y connecte.
Vous voulez un tunnel toujours actif pour toute la centrale plutôt que de voir chaque utilisateur porter un profil personnel.

Pour le travail technique quotidien sur plusieurs centrales — ouvrir les interfaces web des appareils, exécuter des outils de diagnostic — le VPN personnel et le proxy de navigateur sont généralement plus adaptés. Le tableau ci-dessous résume la distinction ; la comparaison complète se trouve sur la page de la fonctionnalité VPN.

Outil	De quoi il s'agit	Qui le configure
VPN personnel	Un profil personnel unique atteignant toutes les centrales pour lesquelles vous êtes autorisé	Chaque utilisateur, dans la limite de ses autorisations
VPN direct (ce guide)	Un tunnel par centrale entre l'agent de la centrale et son routeur	Un Modérateur ou un Admin de l'organisation propriétaire de la centrale
Proxy de navigateur	Ouvrir l'interface web d'un appareil depuis le navigateur, sans installation de client	L'exploitant de la centrale

Les deux directions

Un VPN direct peut fonctionner dans l'une de deux directions. L'assistant de configuration pose cette question en premier, sous Où le serveur VPN se trouve-t-il ?

Remarque : les lignes en pointillés indiquent le sens de la connexion — une seule direction s'applique par VPN direct.

Connexion sortante — Mirox se connecte au routeur de la centrale. Le routeur de la centrale exécute son propre serveur VPN ; le Mirox-Agent se connecte en sortie en tant que client. La carte affiche un badge Client. Choisissez cette option lorsque vous disposez déjà d'un fichier de configuration ou d'identifiants pour le VPN du routeur.
Hébergé ici — le routeur de la centrale se connecte à Mirox. Mirox exécute le serveur VPN ; la carte affiche un badge Serveur. Le point d'accès (une adresse et un port propres à la centrale), les clés et les certificats sont générés par Mirox et vous sont remis pour être chargés sur le routeur de la centrale. Choisissez cette option lorsque le routeur peut initier des connexions sortantes mais ne peut pas en accepter d'entrantes.

Les trois protocoles — OpenVPN, WireGuard et IPsec (IKEv2) — sont proposés dans les deux directions, mais le bon choix diffère selon la direction : voir Choisir le type de VPN ci-dessous. Une centrale peut héberger un serveur par variante de protocole à la fois — WireGuard, OpenVPN sur UDP, OpenVPN sur TCP et IPsec — et peut exécuter en parallèle un nombre quelconque de connexions sortantes.

Choisir le type de VPN

Mirox parle trois protocoles de tunnel — OpenVPN, WireGuard et IPsec (IKEv2) — et l'assistant les présente côte à côte avec ce qui plaide pour et contre chacun. Celui qui est recommandé dépend de la direction choisie, et le badge « Recommandé » se déplace en conséquence. Ce n'est pas une affaire de goût : les deux directions placent la partie fragile de la connexion de part et d'autre du tunnel.

La partie fragile, c'est qui résout l'adresse de l'autre extrémité, et à quelle fréquence. Mirox fonctionne dans plusieurs régions de centres de données, et le point d'accès VPN d'une centrale peut passer de l'une à l'autre lors d'un basculement. Un client qui résout à nouveau le nom DNS du serveur à chaque reconnexion suit ce déplacement tout seul ; un client qui l'a résolu une seule fois au démarrage continue d'appeler une adresse qui ne répond plus.

Quel protocole VPN choisir ?

En un coup d'œil — le détail par direction suit plus bas. L'option recommandée dépend de la direction que vous avez choisie, mais le caractère de chaque protocole est le même dans les deux cas :

Protocole	Usage typique	Fonctionne sur
WireGuard	L'option légère et moderne — la plus rapide à mettre en place, une paire de clés par côté et aucun certificat. Un bon choix pour un site nouvellement construit, ou partout où la gestion des certificats est l'obstacle.	IPv4, IPv6 ou les deux
OpenVPN	L'universel — pris en charge par pratiquement tous les routeurs, y compris des firmwares vieux de plusieurs années. Le choix sûr par défaut quand Mirox héberge le serveur.	IPv4, IPv6 ou les deux
IPsec (IKEv2)	Le standard industriel, et souvent le seul protocole qu'offre un routeur ou pare-feu industriel (Cisco, Lancom, Fortigate).	IPv4 ou IPv6

IPv4 ou IPv6 ? Un tunnel fonctionne aussi bien en IPv6 qu'en IPv4, et lorsque Mirox héberge le serveur, les deux sont publiés par défaut. Voir Version IP pour savoir quoi changer et quand. Pour une connexion sortante, il n'y a rien à choisir — le tunnel suit l'adresse du serveur sur site.

Version IP

Mirox publie l'adresse du tunnel dans le DNS. Pour un VPN hébergé, vous décidez quels enregistrements sont publiés :

Réglage	Ce qui est publié	Quand l'utiliser
IPv4 + IPv6 (par défaut)	Un enregistrement A et un enregistrement AAAA	Presque toujours. Le routeur utilise celui qu'il sait utiliser.
IPv4 uniquement	Un enregistrement A	Le site n'a pas d'IPv6 fonctionnel, ou son routeur refuse les tunnels IPv6.
IPv6 uniquement	Un enregistrement AAAA	Le site est joignable en IPv6 et l'IPv4 n'est pas souhaitée.

Garder les deux enregistrements en ligne offre la compatibilité la plus large, et c'est pourquoi IPv4 + IPv6 est présélectionné. Un routeur disposant d'un IPv6 fonctionnel prendra normalement l'enregistrement AAAA — c'est le comportement ordinaire d'une pile IP qui dispose des deux — et un routeur en IPv4 seule prendra l'enregistrement A. Dans les deux cas, rien n'est à configurer sur le site.

Publier les deux n'est pas un repli automatique pour WireGuard

Un client WireGuard résout l'adresse une seule fois, au démarrage du tunnel, et n'essaie pas l'autre famille si cette tentative échoue. Un routeur dont l'IPv6 existe mais est défaillant peut donc prendre l'enregistrement AAAA et rester hors service — publier les deux enregistrements ne le sauve pas. C'est précisément à cela que sert IPv4 uniquement. OpenVPN se comporte différemment : il parcourt les adresses qu'il a résolues et se rétablit tout seul.

IPsec (IKEv2) ne propose que IPv4 ou IPv6, jamais les deux : une connexion IKE utilise une seule famille d'adresses à la fois.

Où le trouver. Comme la valeur par défaut convient à presque tous les sites, le réglage ne fait pas partie du parcours initial de l'assistant pour WireGuard et OpenVPN — ouvrez Afficher les options avancées à l'étape de configuration. IPsec le demande directement, faute de « les deux » comme repli. Sur un VPN existant, il se trouve en haut de Modifier → Configuration. Le modifier plus tard ne perturbe pas les tunnels déjà établis.

IPv6 à l'intérieur du tunnel

Le réglage ci-dessus décide de la famille qui transporte le paquet chiffré jusqu'à la centrale. Ce que vous adressez à l'intérieur du tunnel — les équipements de la centrale — est aujourd'hui en IPv4. La plateforme y est également préparée pour IPv6 ; ce n'est simplement pas encore réalisé, faute de site l'ayant demandé jusqu'ici. Si les équipements de votre centrale sont adressés en IPv6, dites-le-nous et nous le mettrons en œuvre.

Hébergé ici (Mirox est le serveur) — OpenVPN est recommandé

Dans cette direction, le routeur de la centrale est le client : la re-résolution incombe donc à son firmware — du matériel que nous n'administrons pas et que nous ne pouvons pas réparer à distance.

Option	Ce qui plaide pour	Ce qui plaide contre
OpenVPN (recommandé)	Résout à nouveau l'adresse du serveur à chaque reconnexion : après un basculement Mirox, le tunnel revient de lui-même, quels que soient le fabricant et le firmware du routeur. Pris en charge par pratiquement tous les routeurs, y compris des firmwares vieux de plusieurs années.	Basé sur des certificats : il faut saisir sur le routeur une autorité de certification, un certificat et une clé, au lieu d'une seule paire de clés.
WireGuard	Se configure avec une poignée de valeurs — une paire de clés par côté, aucun jeu de certificats.	La plupart des routeurs ne résolvent l'adresse du serveur qu'une fois au démarrage ; après un basculement Mirox, le tunnel reste coupé jusqu'à ce que le routeur redémarre ou que Mirox rebascule sur son site d'origine. Les firmwares de routeur plus anciens ne proposent parfois pas WireGuard du tout.
IPsec (IKEv2)	La norme sur les routeurs industriels (Cisco, Lancom, Fortigate).	Clé pré-partagée et configuration manuelle du routeur — aucun fichier de configuration à importer. Plus lent : le chiffrement s'exécute en espace utilisateur, ce qui convient surtout à de la télémétrie à faible volume.

La question décisive n'est donc pas de savoir quel protocole est le plus moderne — c'est WireGuard — mais lequel survit à un basculement de région sur un matériel que nous ne contrôlons pas. OpenVPN le fait sur n'importe quel firmware, d'où sa présélection. Choisissez WireGuard lorsque la gestion des certificats constitue l'obstacle principal pour le routeur concerné, en acceptant qu'un basculement puisse exiger un redémarrage du routeur. Choisissez IPsec lorsque le routeur ne propose rien d'autre.

Les certificats n'expirent pas

L'autorité de certification, le certificat serveur et chaque certificat de pair émis par Mirox pour un serveur OpenVPN hébergé ont une durée de vie très longue. Il n'y a aucun renouvellement à prévoir et rien qui expire discrètement des années plus tard — le coût d'OpenVPN, c'est le travail d'importation unique sur le routeur, pas la maintenance.

Port de reconnexion WireGuard

WireGuard mémorise l'adresse à laquelle il s'est connecté la première fois et ne la résout jamais à nouveau. Ainsi, si le côté serveur Mirox d'un tunnel WireGuard hébergé est un jour déplacé — lors d'un basculement, ou pour maintenance —, un peer de site connecté peut rester déconnecté jusqu'à son redémarrage. OpenVPN et IPsec revérifient l'adresse eux-mêmes et n'ont besoin d'aucun réglage de ce type ; WireGuard, non.

Le Port de reconnexion supprime cette faiblesse. C'est le port d'écoute WireGuard du routeur distant (le peer de site). Renseignez-le à la création d'un VPN WireGuard hébergé, ou plus tard sur un peer existant sous Modifier → Peer distant, ou par peer sous Peers → Modifier. Une fois renseigné, Mirox peut rappeler le peer à sa propre adresse publique après le déplacement du côté serveur, de sorte que le tunnel se rétablit automatiquement et survit à un basculement. Laissé vide, le tunnel reste épinglé : le côté serveur n'est pas déplacé, et après un déplacement il resterait coupé jusqu'à ce que le routeur se reconnecte de lui-même. Pour supprimer à nouveau un port de reconnexion, effacez simplement le champ et enregistrez.

Ne le renseignez que lorsque ce port est réellement joignable

Renseigner un port de reconnexion est une promesse que Mirox peut y joindre le routeur — et c'est ce qui autorise le déplacement du tunnel lors d'un basculement. Ainsi, une fois qu'il est renseigné, un déplacement du côté serveur peut survenir, et ce déplacement coupe brièvement puis rétablit le tunnel. Pour qu'il se rétablisse au lieu de rester coupé, le routeur du site doit réellement être à l'écoute sur ce port WireGuard, joignable sur son adresse IPv4 ou IPv6 publique, avec le port ouvert dans le pare-feu du site. Si le port n'est pas joignable, un déplacement coupe le tunnel sans retour possible — ne le renseignez donc qu'une fois que le point d'accès WireGuard du site est à l'écoute et que le pare-feu l'autorise. En cas de doute, laissez-le vide ; le tunnel reste alors simplement là où il est.

Il est recommandé de renseigner un port de reconnexion pour chaque peer de site WireGuard partout où le port d'écoute du routeur est connu et joignable.

Sortant (Mirox est le client) — WireGuard est recommandé

Dans cette direction, le serveur existe déjà sur site et Mirox s'y connecte. Cela inverse les deux arguments ci-dessus :

La partie qui re-résout est désormais la nôtre. Mirox résout à nouveau l'adresse du serveur sur site et se reconnecte de lui-même, quel que soit le protocole — l'objection qui a tranché le cas hébergé disparaît donc complètement.
La question du firmware disparaît elle aussi. Rien n'a à être installé sur le routeur ; le protocole est simplement celui que parle le serveur existant, et Mirox reprend ses réglages de ce serveur.

Le serveur du site doit être joignable depuis Internet

Ce sens ne fonctionne que si Mirox peut s'y connecter : la ligne de la centrale a donc besoin d'une adresse à elle, joignable depuis l'Internet public. L'une ou l'autre famille suffit : une IPv4 publique ou une IPv6 publique. Une ligne sans IPv4 publique mais avec un IPv6 fonctionnel convient donc parfaitement.

Ce qui exclut ce sens, c'est uniquement un opérateur qui maintient la ligne à l'intérieur de son propre réseau partagé : le routeur ne possède alors, sur aucune des deux familles, d'adresse joignable de l'extérieur. C'est le cas habituel des forfaits mobiles et SIM à bas coût. Demandez à la centrale de consulter la page Internet de son routeur : une IPv4 signalée comme partagée avec d'autres clients et aucune IPv6 publique sur la connexion signifient que ce sens est impossible. Un nom DynDNS qui se résout ne prouve rien ici — il se résout tout aussi bien sur une ligne partagée.

Dans ce cas, hébergez plutôt le VPN ici (section ci-dessus) : le routeur se connecte alors vers l'extérieur, ce qui fonctionne sur n'importe quelle ligne. Choisissez-y OpenVPN — sur une telle ligne, un tunnel WireGuard hébergé ne pourrait pas non plus être réparé depuis notre côté, car un port de reconnexion suppose exactement la même joignabilité, et il resterait coupé après un basculement jusqu'à ce que le routeur se reconnecte de lui-même.

Reste ce qui doit être importé dans Mirox — et c'est là que les trois diffèrent vraiment :

Option	Ce qui plaide pour	Ce qui plaide contre
WireGuard (recommandé)	Une paire de clés et un point de terminaison suffisent à l'import — rien d'autre ne doit concorder entre les deux extrémités. Mirox résout à nouveau l'adresse du serveur sur site et se reconnecte de lui-même : un changement DynDNS ou une coupure de ligne se répare tout seul.	Le serveur sur site doit ajouter la clé publique Mirox comme pair — il ne peut pas se contenter de fournir un profil.
OpenVPN	Presque tous les serveurs VPN existants le proposent, et leur profil `.ovpn` peut être téléversé ici tel quel.	Le chiffrement, le HMAC et les réglages TLS doivent correspondre exactement au serveur — une divergence échoue en silence, c'est pourquoi l'assistant les passe en revue avec vous dans une étape dédiée. Le profil est un ensemble : CA, certificat, clé et clé tls-auth doivent tous provenir du site.
IPsec (IKEv2)	Souvent la seule option d'un pare-feu industriel (Cisco, Lancom, Fortigate).	La clé pré-partagée et les deux identités IKE doivent être convenues manuellement avec le site — aucun profil à importer. Plus lent : le chiffrement s'exécute en espace utilisateur, ce qui convient surtout à de la télémétrie à faible volume.

En pratique, le choix est souvent déjà fait : ce doit être le protocole que parle le serveur existant. La recommandation s'applique lorsque le site en propose plusieurs — et lorsque le site est encore en cours de construction, il vaut la peine de demander WireGuard.

UDP ou TCP (OpenVPN uniquement)

OpenVPN fonctionne sur UDP ou TCP. UDP correspond au fonctionnement prévu — plus rapide et nettement plus stable sur une liaison mobile faible — et c'est la valeur par défaut. TCP est réservé au site dont le pare-feu ne laisse sortir aucun UDP, ou dont le routeur ne propose que TCP.

Hébergé ici : le choix se trouve à l'étape Configuration, derrière Afficher les options avancées, à côté des réglages de chiffrement. Ne le touchez pas sauf si vous savez que l'UDP est bloqué. Le transport fait partie de l'identité du serveur : une centrale peut donc héberger un serveur OpenVPN UDP et un TCP côte à côte.
Sortant : un fichier .ovpn téléversé l'indique déjà ; en saisie manuelle, vous choisissez UDP ou TCP avec les détails de connexion.

Paramètres de compatibilité OpenVPN

Ils se trouvent à l'étape Configuration de l'assistant. Sa vue par défaut ne comporte volontairement aucun réglage — un serveur hébergé non modifié applique le profil moderne, celui qui convient à tout routeur encore suivi par son fabricant. Les préréglages de compatibilité et les directives individuelles apparaissent derrière Afficher les options avancées.

Pour OpenVPN, vous pouvez reprendre les paramètres d'un routeur plus ancien afin que même un firmware ancien puisse se connecter : chiffrement, empreinte d'authentification, version TLS minimale, compression, mssfix, intervalle de renégociation et mode TLS auth. L'assistant valide la combinaison au fil de votre saisie et rejette les associations qu'aucun firmware de routeur pris en charge ne peut réellement négocier.

Un serveur OpenVPN hébergé offre en outre :

Algorithme de clé PKI — les nouveaux serveurs utilisent par défaut RSA-2048, l'algorithme accepté par les routeurs industriels courants ; ECDSA P-256 est disponible lorsque le routeur le prend en charge. L'algorithme est figé à la création ; le changer ultérieurement implique de faire pivoter toute la chaîne de certificats.
Faire pivoter la CA — réémet en une seule étape l'autorité de certification du serveur, le certificat du serveur et le certificat de chaque peer connecté. La nouvelle configuration de chaque peer est affichée une seule fois pour téléchargement ; les anciens certificats cessent de fonctionner dès que la rotation est appliquée.
Exiger l'authentification de l'utilisateur — les peers qui se connectent doivent présenter en plus un nom d'utilisateur et un mot de passe que vous définissez pour chaque peer.

Paramètres IPsec (IKEv2)

Pour IPsec, l'assistant demande ce dont un répondeur IKEv2 a besoin : la clé pré-partagée — laissez-la vide sur un serveur hébergé et Mirox en génère une robuste, affichée une seule fois après la création —, les identités IKE locale et distante (facultatives ; le FQDN du point de terminaison est utilisé par défaut), les propositions IKE et ESP, leurs durées de vie et le délai DPD qui détermine la rapidité de détection d'un pair mort. Les deux extrémités doivent s'accorder sur les propositions et il n'y a aucun profil à échanger : ces valeurs se saisissent à la main sur le routeur.

Avant de commencer

Qui peut configurer les VPN directs

L'onglet VPN du site est visible par les rôles Technical Manager ou supérieur sur la centrale (y compris Exploitant). Créer, modifier ou supprimer un VPN direct nécessite un rôle de Modérateur ou d'Admin de l'organisation propriétaire de la centrale. Les rôles inférieurs, et les utilisateurs accédant à la centrale via une coopération, voient les tunnels configurés mais ne peuvent pas les modifier. L'accès suit le système d'autorisations.

Préparez :

La direction dont vous avez besoin (sortante ou hébergée), selon ce que le routeur de la centrale prend en charge.
Pour la direction sortante : le fichier de configuration VPN du routeur (.conf ou .ovpn), ou l'adresse du point d'accès et les clés à saisir manuellement.
En direction sortante, le protocole est imposé par le serveur qui tourne déjà sur site. En direction hébergée, le choix vous appartient — voir Choisir le type de VPN.
Le ou les sous-réseaux de la centrale derrière le routeur que vous souhaitez atteindre — les plages de réseau local (CIDR) où se trouvent les onduleurs, les loggers et les autres appareils.

Ajouter un VPN direct

Ouvrir dans Mirox : ouvrez l'onglet VPN du site de la centrale — la page Réseau de la centrale, onglet VPN du site.
Cliquez sur Ajouter une connexion VPN. Un court assistant s'ouvre.
Choisissez la direction — Mirox se connecte au routeur du parc (sortant) ou Le routeur du parc se connecte à Mirox (hébergé).
Type de VPN — choisissez OpenVPN, WireGuard ou IPsec (IKEv2). L'assistant marque l'option recommandée pour la direction choisie et la présélectionne ; chaque carte indique ce qui plaide pour et contre. Voir Choisir le type de VPN.
Configuration — (hébergé uniquement) le profil de compatibilité pour le routeur de la centrale. La valeur par défaut convient à tout routeur des dernières années ; Afficher les options avancées dévoile le transport (UDP/TCP), les directives de chiffrement individuelles, l'authentification facultative par nom d'utilisateur et mot de passe, la clé pré-partagée WireGuard ou les réglages du répondeur IPsec.
Détails de connexion — (direction sortante uniquement) téléversez le fichier .conf/.ovpn du routeur, ou passez à la saisie manuelle et entrez le point d'accès et les clés. Pour OpenVPN, une étape de revue de compatibilité suit : l'assistant y montre ce qu'il a lu dans le profil afin que vous puissiez le corriger.
Sous-réseau de la centrale — ajoutez la ou les plages de réseau local accessibles derrière le routeur. La plateforme valide chaque plage et bloque tout ce qui entrerait en conflit avec la plage de tunnel réservée, une route VPN d'organisation ou un autre VPN direct sur la même centrale.
Vérifier et appliquer — confirmez le récapitulatif, puis cliquez sur Appliquer.

Le tunnel se nomme lui-même

Il n'y a pas de nom à saisir. Mirox nomme le tunnel d'après la centrale et le protocole choisi — par exemple Centrale Nord OpenVPN-UDP — et ajoute un numéro si ce nom est déjà pris, afin qu'il soit unique sur la centrale. Vous pouvez le renommer ou ajouter une description à tout moment sous Modifier → Général.

Enregistrez immédiatement les identifiants du VPN hébergé

Lorsque vous créez un VPN hébergé, Mirox génère la configuration dont le routeur de la centrale a besoin pour se connecter — y compris sa clé privée ou son certificat — et ne l'affiche qu'une seule fois. Téléchargez-la et chargez-la sur le routeur avant de fermer la fenêtre ; elle ne peut pas être récupérée ultérieurement. Si elle est perdue, faites pivoter le peer (WireGuard) ou les certificats (OpenVPN) pour en obtenir une nouvelle.

Une fois le tunnel établi, les appareils des sous-réseaux de centrale configurés deviennent accessibles, et toute découverte d'appareils réseau que vous lancez sur la centrale s'effectue à travers lui.

La route par défaut n'est jamais autorisée

Un VPN direct ne transporte jamais de route « tout envoyer » 0.0.0.0/0. Indiquez toujours les sous-réseaux de centrale explicites que vous souhaitez atteindre. Si vous téléversez une configuration contenant une route par défaut, la plateforme la supprime et vous demande d'ajouter les plages spécifiques.

Gérer un VPN direct existant

Chaque VPN direct apparaît sous forme de carte dans l'onglet VPN du site, marquée Serveur (hébergé) ou Client (sortant), avec une barre de connexion en direct et un indicateur de trafic. Pour un VPN hébergé comptant plusieurs sites connectés, la barre reflète le pire peer connecté — un seul site coupé colore toute la carte. Ouvrez le menu ... de la carte pour :

Modifier — changer le nom, la description, les sous-réseaux, les paramètres de connexion ou les clés. La fenêtre de modification comporte les onglets Général, Sous-réseaux, Config (paramètres du protocole) et Peer distant (la clé ou le certificat du côté qui se connecte, leur rotation et l'ajout de peers supplémentaires).
Redémarrer le VPN — relancer le tunnel sans modifier sa configuration ; utile après un changement de paramètres ou une coupure passagère.
État en direct — ouvrir la fenêtre d'inspection (voir ci-dessous) avec l'état en direct par peer, les journaux, le diagnostic et les outils de débogage.
Diagnostiquer — (affiché lorsque le tunnel est actuellement déconnecté) accéder directement au diagnostic automatique.
Gérer les peers — (VPN hébergés comptant plus d'un site connecté) accéder à l'onglet Peers.
Supprimer — retirer le tunnel. Vous devez saisir le nom du tunnel pour confirmer ; la fenêtre liste les appareils réseau qui perdraient leur route.

La fenêtre d'inspection : état en direct, journaux, diagnostic, débogage

État en direct sur une carte ouvre une fenêtre avec quatre onglets et un badge de connexion en direct :

État en direct — une carte par peer, actualisée environ une fois par seconde, directement depuis la centrale : état de connexion, IP de tunnel, point d'accès, trafic reçu/envoyé avec débits en direct et — selon le protocole — l'âge du dernier handshake (WireGuard ; au-delà d'environ 3 minutes, le tunnel n'est pas établi actuellement) ou la durée de la session (OpenVPN). Les peers disposant d'une adresse de tunnel affichent en ligne un graphique de latence alimenté par une vérification d'accessibilité continue.
Diagnostic — le diagnostic automatique en un clic : un assistant IA lit les journaux récents et l'état en direct du tunnel, explique en langage clair ce qu'il constate et — pour les incompatibilités de paramètres OpenVPN — peut proposer un correctif de configuration sûr que vous appliquez d'un seul clic. Voir aussi la page Assistant IA.
Journaux — le journal de connexion en direct du tunnel, avec coloration par niveau et remontée dans l'historique.
Débogage — des outils en lecture seule exécutés au niveau de la centrale : la table de routage du tunnel, un ping libre à travers le tunnel et une capture ICMP qui montre si les requêtes partent réellement et si quelque chose répond — la méthode classique pour distinguer « tunnel actif mais le site ne répond pas » de « tunnel coupé ».

Reconnecter un pair WireGuard hébergé

WireGuard résout l'autre extrémité une seule fois, au démarrage du tunnel : un pair sur site ne retrouve donc plus ce serveur si l'adresse de celui-ci change. Lorsque le tunnel d'un tel pair est coupé, sa carte dans État en direct propose un bouton Reconnecter, avec la dernière adresse et le dernier port connus déjà renseignés — un seul handshake envoyé de notre côté suffit : le pair résout de nouveau l'adresse et assure ensuite la connexion tout seul. Ajustez les champs si le site a changé.

Ce bouton n'apparaît que pour un VPN WireGuard hébergé, uniquement tant que ce pair est déconnecté, et il ne modifie rien de ce qui est enregistré — aucune configuration n'est écrite et l'agent de la centrale n'est pas redémarré. Rien de ce que vous saisissez ici ne peut aggraver la situation : si le pair se connecte plus tard depuis une autre adresse, WireGuard adopte simplement l'adresse d'où le paquet est réellement venu.

« Pas de données — possiblement obsolète »

Le badge en direct passe au rouge lorsqu'aucune lecture fraîche n'arrive. Cela signifie que la lecture est indisponible — l'affichage n'indique délibérément jamais « tunnel coupé », car une lecture manquante n'est pas la preuve d'une panne.

Gérer les sous-réseaux de la centrale

Les sous-réseaux qu'un VPN direct achemine sont ce qui rend les appareils de la centrale accessibles. Ajoutez ou retirez des plages depuis la vue Modifier du VPN à tout moment. Retirer un sous-réseau derrière lequel se trouvent encore des appareils réseau laisse ces appareils sans route — la fenêtre de suppression vous avertit et liste les appareils concernés, afin que vous puissiez d'abord les réaffecter à un autre tunnel.

VPN hébergé : les peers connectés

Un VPN hébergé accepte deux types de peers connectés :

Peers de site — le routeur de la centrale lui-même (ou un autre site fixe) qui se connecte et annonce ses sous-réseaux. Le premier peer de site est créé pour vous lorsque vous configurez un VPN hébergé ; sa clé ou son certificat se trouve dans l'onglet Peer distant de la fenêtre de modification. Un VPN hébergé peut servir plusieurs peers de site — une centrale répartie sur plusieurs routeurs, chacun annonçant ses propres plages.
Peers utilisateur — des personnes individuelles se connectant au même serveur hébergé avec un profil personnel. Un peer utilisateur déconnecté est normal (les personnes se connectent à la demande) et n'est jamais compté comme une panne de site.

Avec plus d'un peer de site, la page Réseau de la centrale affiche l'onglet Peers : un tableau de tous les peers connectés avec IP de tunnel, identité (clé publique WireGuard ou nom de certificat OpenVPN), trafic, historique de connexion et modification par peer (sous-réseaux, rotation de clé ou de certificat, suppression). Avec un seul peer de site, les mêmes réglages se trouvent directement dans la fenêtre de modification et l'onglet Peers reste masqué.

Supprimer un serveur hébergé est destructeur

Supprimer un VPN hébergé retire le serveur ainsi que chaque peer connecté — sites comme utilisateurs. Leurs configurations cessent immédiatement de fonctionner et ne peuvent pas être réémises ; recréer le serveur plus tard implique d'émettre de nouvelles configurations pour chaque peer.

Si le tunnel ne se connecte pas

L'onglet Diagnostic automatise l'essentiel de ce qui suit ; les schémas ci-dessous sont ce qu'il recherche (tout comme l'assistant IA) :

Symptôme	Cause la plus probable	Où regarder
VPN hébergé, un peer ne s'est jamais connecté	La configuration générée n'a jamais été installée sur le routeur, ou elle vise la mauvaise adresse ou le mauvais port	Chargez la configuration du peer sur le routeur ; vérifiez le point d'accès sur la carte
Le peer était connecté, désormais coupé, les journaux montrent « sent … received 0 »	Le routeur distant a cessé de répondre — souvent après un redémarrage du routeur ou du modem	Redémarrez électriquement le routeur/modem distant ; vérifiez sa liaison Internet
Tunnel connecté mais appareils injoignables	Le routeur du site bloque ou ne route pas le trafic (sur plusieurs marques de routeurs, les interfaces VPN sont placées par défaut dans une zone de type WAN qui n'autorise que le trafic sortant)	Onglet Débogage : ping + capture ICMP — « le trafic part mais rien ne répond » le confirme ; ajoutez une route ou une règle de pare-feu sur le routeur
L'OpenVPN sortant ne se connecte jamais	Paramètres incompatibles avec le serveur distant (chiffrement, version TLS, compression…)	Lancez Diagnostiquer — il peut proposer les paramètres correspondants comme correctif en un clic
Le WireGuard sortant tombe juste après un changement de clé/PSK	Le tunnel n'a pas encore rechargé les nouvelles clés	Redémarrer le VPN sur la carte
La connexion oscille (montées et coupures répétées)	Liaison montante instable sur le site distant, ou une même configuration de peer utilisée par deux appareils	L'historique de connexion sur la carte ; émettez un peer distinct par appareil
Tout est coupé d'un coup sur la centrale	Panne d'Internet ou d'alimentation du site — pas un problème de VPN	Le pipeline de connexion de l'onglet Vue d'ensemble

Fonctionnalités associées

Utiliser le VPN — le profil VPN personnel par utilisateur qui atteint toutes vos centrales autorisées
Utiliser le proxy — ouvrir l'interface web d'un appareil dans le navigateur sans client VPN
Gérer les appareils réseau — découvrir et superviser les appareils accessibles via un tunnel
VPN (fonctionnalité) — en quoi les variantes de VPN diffèrent et comment fonctionnent le routage et l'audit
Services VPN d'organisation — une passerelle partagée desservant plusieurs centrales
Inspecteur de réseau local — vérifications d'accessibilité du réseau de la centrale côté plateforme
Journalisation d'audit des accès — la piste d'audit couvrant tous les accès distants
Volume de données par centrale — le volume transféré par la centrale, et si une liaison lente est un problème de capacité