WireGuard, IPsec et SD-WAN ne se situent pas au même niveau. WireGuard et IPsec protègent le trafic dans des tunnels. SD-WAN décrit un service piloté d’interconnexion sur une ou plusieurs liaisons sous-jacentes ; le chiffrement peut reposer sur différentes technologies. Pour plusieurs sites, le choix commence donc par les applications, liaisons, responsabilités et scénarios de panne, avant le nom d’un produit.
Une entreprise fictive possède un siège et trois agences. ERP et téléphonie utilisent des services centraux, Microsoft 365 accède aussi directement que possible à internet et une société de maintenance ne dispose que d’un accès limité. Le billet DAXS sur la maintenance d’OPNsense traite de la mise à jour d’un pare-feu ; ici, il s’agit de la topologie des sites et du choix d’exploitation. Une seconde liaison internet par site est un sujet distinct que le seul nom SD-WAN ne résout pas.
Quatre vérifications avant de choisir un protocole
Relever d’abord, pour chaque site, applications, réseaux cibles, charge de pointe mesurée, exigences de latence, accessibilité publique et pannes de liaison. Des plages d’adresses privées qui se chevauchent compliquent routage et autorisations indépendamment du protocole de tunnel. Définir ensuite si les agences communiquent uniquement avec le siège ou aussi directement entre elles ; le modèle hub-and-spoke exige moins de relations de tunnel, mais peut faire du siège un goulot d’étranglement. Enfin, attribuer l’exploitation, la gestion des clés, la supervision et un chemin de reprise testé.
| Approche | Adaptée lorsque… | Vérifications et limites |
|---|---|---|
| WireGuard | Quelques pairs et réseaux clairement définis permettent une gestion maîtrisable des clés | Tester concrètement AllowedIPs, routes, règles de pare-feu, NAT et accessibilité de chaque pair ; le protocole ne fournit pas automatiquement une exploitation centralisée |
| IPsec avec IKEv2 | Les équipements ou pairs existants exigent des tunnels IPsec standardisés | Valider les profils interconstructeurs, certificats, renouvellements de clés, NAT-T et basculements sur la paire réelle d’équipements |
| Service SD-WAN | Plusieurs liaisons, de nombreux sites ou des chemins applicatifs doivent être pilotés et suivis centralement | Vérifier contractuellement et techniquement underlay, équipements edge, politique, points de mesure, accès d’administration, SLA et chemin en cas de panne |
Un petit réseau peut très bien fonctionner avec WireGuard ou IPsec si une personne est responsable de la configuration et des incidents. Une offre SD-WAN peut regrouper ce travail d’exploitation et piloter les chemins, mais crée ses propres coûts de plateforme, licence, support et dépendance. L’amélioration de la disponibilité dépend de l’indépendance réelle des liaisons et du basculement testé.
WireGuard : des pairs et des réseaux clairement définis
WireGuard associe des clés publiques à des plages IP autorisées. Dans une liaison intersites, ces plages doivent correspondre à la table de routage et aux règles de pare-feu ; un handshake réussi ne prouve pas encore que l’ERP ou la téléphonie est accessible. Un keepalive peut être nécessaire lorsqu’un pair est derrière un NAT. La documentation OPNsense présente des contrôles concrets de pairs, routes et pare-feu pour deux sites, ainsi que des problèmes possibles de MTU/MSS. Avec quatre sites, configuration et gestion des clés augmentent, surtout si des chemins directs entre agences sont souhaités. WireGuard seul n’ajoute ni gestion automatique des politiques, ni supervision du service, ni SLA.
IPsec/IKEv2 : la standardisation exige une validation
IPsec protège les paquets à la couche réseau ; IKEv2 négocie les associations de sécurité et les clés. Cela peut être pertinent avec des pare-feu hétérogènes ou des exigences existantes de partenaires. La compatibilité reste à valider : suites cryptographiques, certificats, sélecteurs réseau, renouvellements de clés et traversée NAT doivent correspondre des deux côtés. La RFC 7296 décrit notamment l’encapsulation UDP d’IPsec avec NAT. Le pilote vérifie donc l’établissement du tunnel, une durée prolongée, le changement des clés et la reprise après interruption de liaison. Un ping réussi ne vaut pas davantage une recette fonctionnelle.
SD-WAN : distinguer overlay, underlay et contrat
MEF 70.2 définit le SD-WAN comme un service aux attributs convenus et le distingue explicitement des services de connectivité sous-jacents. Dans l’exemple, des règles telles que « ERP sur le chemin A, bascule vers B en cas de panne mesurée » ou « téléphonie seulement avec une latence adaptée » pourraient être des exigences ; leur disponibilité réelle dépend du produit du fournisseur, des mesures et des prestations contractuelles. Si une agence n’a qu’un accès physique à internet, le pilotage central ne peut pas supprimer sa panne par configuration. De même, une seconde liaison aide peu si les deux partagent le même tracé, la même alimentation ou le même équipement edge.
L’offre doit donc être évaluée séparément pour le matériel edge, la localisation de la gestion, les liaisons, la politique centrale, les frontières de sécurité, la journalisation, la maintenance du firmware, les horaires de support, le trajet des données et le scénario de sortie. « Managé » n’est un avantage que si l’escalade, les données de mesure et la responsabilité en cas d’incident sont définies.
Un test de panne en dit plus qu’une fiche technique
Le siège et une agence testent ensemble quatre cas : perte du chemin principal, panne de l’équipement edge, clé ou certificat invalide, et application défaillante malgré un tunnel actif. Mesurer détection, basculement, reconnexion, effet applicatif et retour au chemin normal. ERP et téléphonie peuvent admettre des interruptions différentes. Le compte rendu indique les durées réelles plutôt qu’une promesse générale de haute disponibilité.
La décision économique comprend équipements et pièces de rechange, configuration des tunnels et politiques, tarifs des liaisons, redondance supplémentaire réelle, licences ou redevances, supervision et effort d’astreinte interne. Un tunnel WireGuard propre peut ne pas avoir de licence de protocole distincte, mais conserve des coûts d’exploitation et de liaison. Un tunnel IPsec sur des équipements existants peut sembler économique si maintenance et validation constructeur sont incluses. Un service SD-WAN peut réduire le travail sur de nombreux sites, mais doit être comparé à périmètre de service égal. Sans mesures ni devis, un classement en euros serait inventé.
DAXS peut traduire avec l’entreprise les quatre sites, applications et scénarios de panne en une topologie prête pour la recette, puis comparer les modes d’exploitation adaptés. Les points de départ d’un échange avec DAXS sont le plan réseau intersites, les contrats de liaison et l’historique des incidents.
Sources : WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
