콘텐츠로 건너뛰기

VPN site à site open source : quel protocole choisir en 2026

Choisissez un VPN site à site open source en 2026 : WireGuard pour liaisons simples, strongSwan pour compatibilité, SoftEther face au filtrage.

VPN site à site open source : quel protocole choisir en 2026

Passerelles réseau connectant deux réseaux locaux

Pour un VPN site à site open source fiable et performant, privilégiez WireGuard sur les liaisons simples entre deux à quelques sites, et strongSwan (IPsec) quand vous devez garantir la compatibilité avec des équipements réseau existants. SoftEther reste la meilleure carte à jouer face à un pare-feu restrictif ou pour du multi-protocole.

La suite explique comment configurer chacun, quels pièges éviter, et comment tester le résultat avant de le mettre en production.

En bref:

  • La configuration d’un VPN site à site repose sur la collecte précise des IP publiques, sous-réseaux, et la vérification de l’horloge NTP pour éviter les échecs de négociation.
  • WireGuard est conseillé pour des liaisons simples et performantes, tandis qu’IPsec avec strongSwan garantit une compatibilité maximale avec les équipements existants.
  • La règle NAT doit toujours précéder la masquerade pour que le tunnel se constitue correctement, et un test bidirectionnel s’impose avant toute mise en production.
  • Le choix d’architecture, entre hub VPS, appliance locale, ou passerelle cloud managée, dépend surtout des compétences internes et des contraintes de souveraineté.
  • En cas de problème, la plupart des échecs proviennent d’une règle NAT mal placée ou d’une incohérence sur les AllowedIPs ou la négociation IKE.
Yundera
Gardez vos données sous votre contrôle
Yundera propose des serveurs privés gérés en France, avec vos données conservées et plus de 100 applications open source.

Table des matières

Qu’est-ce qu’un VPN site à site et quand l’utiliser ?

Un VPN site à site relie deux réseaux locaux distants par un tunnel chiffré permanent, comme si les machines des deux côtés partageaient le même segment physique. C’est une connexion permanente et sécurisée entre deux réseaux locaux, à la différence d’un VPN d’accès distant qui connecte un seul poste au réseau de l’entreprise.

La distinction compte pour votre architecture. Un commercial en déplacement a besoin d’un accès distant classique. Une entreprise avec un siège et trois agences a besoin d’un tunnel réseau à réseau, où chaque poste d’un côté voit les serveurs et imprimantes de l’autre sans configuration individuelle.

Les cas d’usage les plus fréquents pour ce type de tunnel :

  • Relier un siège social à une ou plusieurs succursales pour partager des ressources internes (fichiers, ERP, impression réseau).
  • Connecter un datacenter local à une infrastructure cloud, par exemple pour répliquer des sauvegardes sans exposer les serveurs sur Internet.
  • Interconnecter plusieurs sites en topologie maillée pour des organisations réparties géographiquement.
  • Sécuriser les flux entre deux environnements de production appartenant à la même entité juridique.

Le VPN site à site n’est pas la seule réponse possible. Les organisations qui veulent limiter l’accès applicatif poste par poste, plutôt qu’ouvrir tout un sous-réseau, se tournent de plus en plus vers le ZTNA, une approche qui vérifie chaque connexion individuellement. Mais pour relier des réseaux entiers en confiance mutuelle, comme deux bureaux d’une même société, le tunnel site à site garde l’avantage : il est plus simple à administrer et ne demande pas de reconfigurer chaque application.

Comment configurer un VPN site à site : la checklist complète

Avant d’ouvrir un seul fichier de configuration, réunissez les informations qui vous évitent de recommencer trois fois. C’est la partie fastidieuse, mais elle conditionne tout le reste.

1. Réunir les prérequis réseau. Notez les IP publiques (ou noms DNS dynamiques) de chaque site, les plages de sous-réseaux LAN à interconnecter, la valeur MTU de vos liens Internet, et vérifiez que NTP est actif sur les deux passerelles. Une dérive d’horloge de quelques minutes suffit à faire échouer les négociations IKE en IPsec.

2. Choisir la topologie. Trois options s’affrontent : un hub VPS public (pratique quand un ou plusieurs sites sont derrière un routeur NAT sans IP fixe), une appliance matérielle type pfSense ou OPNsense sur chaque site, ou un maillage direct entre passerelles quand toutes ont une IP publique stable. Le hub VPS simplifie beaucoup les cas où au moins un site n’a pas d’adresse routable.

Comparaison de trois topologies VPN site-à-site

3. Configurer les pairs et les politiques. Sur WireGuard, cela consiste à générer une paire de clés par site, déclarer chaque pair avec son AllowedIPs correspondant à son sous-réseau LAN, et activer PersistentKeepalive côté site derrière NAT pour maintenir le tunnel ouvert. Sur IPsec avec strongSwan, vous définissez des conn avec les sous-réseaux locaux et distants, un proposal cohérent entre les deux extrémités, et une politique IKEv2 identique des deux côtés.

4. Ajouter les routes et corriger le NAT. Chaque passerelle a besoin d’une route statique pointant les sous-réseaux distants vers l’interface du tunnel. C’est aussi le moment d’ajouter une règle de contournement NAT (NAT bypass) placée avant toute règle de masquerade, faute de quoi le pare-feu réécrit les adresses source et casse le tunnel avant même qu’il ne se forme.

5. Tester et valider. Lancez un ping d’un LAN vers l’autre, vérifiez le chemin avec traceroute, consultez les logs du service (journalctl -u wg-quick@wg0 ou les logs strongSwan) et surveillez que le tunnel reste actif après plusieurs minutes d’inactivité, pas seulement au moment du test initial.

Un exemple de fragment de configuration WireGuard côté hub, pour un site distant derrière NAT :

[Peer]
PublicKey = <clé_publique_du_site_distant>
AllowedIPs = 192.168.20.0/24
PersistentKeepalive = 25

Conseil de pro : Testez toujours le tunnel dans les deux sens avant de le déclarer opérationnel. Un flux qui passe d’un site A vers B mais pas l’inverse indique presque toujours une route manquante ou une règle NAT mal ordonnée sur le site de retour.

WireGuard, strongSwan, SoftEther, OpenVPN : lequel retenir ?

Le choix du protocole dépend moins des chiffres de performance bruts que de votre parc matériel et de vos contraintes réseau.

  • WireGuard offre le meilleur rapport performance/simplicité : intégré au noyau Linux, il consomme peu de CPU et sa configuration se limite à quelques lignes par pair. C’est le choix par défaut pour des liaisons simples entre serveurs Linux ou routeurs récents. Notre guide de déploiement WireGuard détaille la mise en place complète sur serveur.
  • strongSwan (IPsec) reste la référence en entreprise pour l’interopérabilité : de nombreux environnements professionnels privilégient encore IPsec parce que la quasi-totalité des routeurs, firewalls et appliances du marché le prennent en charge nativement, y compris du matériel ancien qui ne recevra jamais de mise à jour pour WireGuard.
  • SoftEther se distingue sur la traversée de pare-feu stricts : ce serveur multi-protocole open source sait faire transiter du trafic VPN par le port 443, ce qui le rend précieux derrière des proxys d’entreprise ou des restrictions réseau agressives.
  • OpenVPN garde un atout similaire sur le port 443 et une base d’utilisateurs très large, mais il demande plus de ressources CPU que WireGuard pour un débit équivalent, ce qui pèse sur des liaisons à fort volume.

Pour la maintenance au quotidien, WireGuard gagne sur la simplicité de dépannage : peu de paramètres, peu de couches à inspecter. IPsec, en revanche, exige de synchroniser des proposals identiques des deux côtés, un point qui génère l’essentiel des tickets de support en environnement hétérogène.

Hub VPS, appliance locale ou passerelle cloud : quelle architecture choisir ?

Le hub VPS public résout un problème très concret : relier des sites qui n’ont pas d’adresse IP fixe. Un VPS d’entrée de gamme suffit largement pour faire transiter du trafic WireGuard entre plusieurs sites, à un coût mensuel proche de celui d’un abonnement téléphonique.

  • Hub VPS : idéal quand un ou plusieurs sites sont derrière un NAT sans IP publique fixe ; coût d’infrastructure minime, mais vous devenez responsable de la disponibilité du VPS lui-même.
  • Appliance locale (pfSense, OPNsense) : solutions open source solides pour du matériel dédié, avec un investissement initial en matériel et un temps de maintenance à prévoir, mais aucune dépendance à un tiers hébergeur.
  • Passerelle cloud managée : pertinente si vous multipliez les sites rapidement et que vous voulez déléguer la disponibilité, au prix d’un contrôle réduit sur la configuration fine du tunnel.

Le bon choix dépend surtout de vos compétences internes. Une équipe qui maîtrise déjà Linux ira naturellement vers un hub VPS avec WireGuard. Une organisation qui a des contraintes de souveraineté des données sur l’hébergement du hub devra vérifier où ce VPS est physiquement situé, pas seulement son prix.

Pourquoi votre tunnel ne fonctionne pas (et comment le corriger)

La majorité des tunnels qui échouent partagent les mêmes causes, presque toujours dans cet ordre de fréquence.

  • Règle NAT mal placée : la règle de contournement NAT doit toujours précéder la règle de masquerade. Sans elle, votre routeur réécrit les adresses source du trafic destiné au tunnel avant qu’il ne parte, ce qui casse la correspondance de politique côté distant.
  • AllowedIPs ou policies mal définis : un AllowedIPs trop large ou trop étroit sur WireGuard, ou des sous-réseaux qui se recouvrent entre deux sites, empêche le routage correct et crée des conflits d’adressage difficiles à diagnostiquer.
  • Incohérence de proposal ou d’IKE : des algorithmes ou versions IKE différents entre les deux extrémités IPsec font échouer la négociation silencieusement, sans message d’erreur explicite côté utilisateur.
  • Horloge désynchronisée : sans NTP actif sur les deux passerelles, les certificats et les associations de sécurité (SA) expirent de façon incohérente.

Conseil de pro : Face à un tunnel qui « monte » mais ne laisse passer aucun trafic, lancez tcpdump sur l’interface physique (pas l’interface du tunnel) des deux côtés simultanément. Si les paquets sortent d’un site mais n’arrivent jamais sur l’autre, le problème est presque toujours une règle NAT ou un pare-feu intermédiaire, pas le VPN lui-même.

Sécuriser un VPN site à site sur la durée

La sécurité d’un tunnel ne se joue pas seulement au moment de la configuration initiale, mais dans la routine d’exploitation qui suit.

  • Privilégiez des algorithmes modernes (ChaCha20-Poly1305 pour WireGuard, AES-GCM pour IPsec) et planifiez une rotation régulière des clés et certificats, pas seulement en cas d’incident.
  • Appliquez des règles ACL entre les sous-réseaux interconnectés : un tunnel ouvert ne doit pas donner un accès total à tout le LAN distant si seuls certains serveurs en ont besoin.
  • Mettez en place une supervision active (alerte si le tunnel tombe, test périodique de connectivité) plutôt qu’une vérification manuelle occasionnelle.
  • Sauvegardez les fichiers de configuration hors du serveur lui-même et documentez la procédure de révocation d’une clé compromise avant d’en avoir besoin en urgence.

Faut-il déléguer la gestion de votre VPN à un service managé ?

Monter et maintenir un tunnel site à site open source demande une vraie rigueur opérationnelle : rotation des clés, supervision, gestion des mises à jour de sécurité sur chaque passerelle. Pour une équipe qui a le temps et les compétences réseau en interne, WireGuard ou strongSwan restent d’excellents choix, gratuits et sous votre contrôle total.

Pour une structure sans administrateur réseau dédié, la charge récurrente pèse davantage que le coût logiciel lui-même : c’est du temps humain, pas de la licence. Un serveur cloud privé géré peut alors couvrir la connectivité sécurisée sans transférer cette charge à une équipe déjà occupée ailleurs. Le compromis reste réel : vous acceptez un abonnement récurrent contre l’assurance que quelqu’un d’autre gère les correctifs et la disponibilité.

Faut-il déléguer la gestion de votre VPN à un service managé ? — overview diagram

Une offre managée pour ceux qui veulent garder la main sans gérer l’infrastructure

Certaines solutions alternatives permettent de bénéficier de la sécurité d’un VPN site à site sans assumer la charge d’exploitation qu’implique une maintenance manuelle du tunnel VPN.

Yundera

Un serveur privé hébergé en France, entièrement géré, peut donner accès à de nombreuses applications open source préinstallées, sans compétences techniques requises pour une administration quotidienne. Les données demeurent la propriété de l’utilisateur, sans collecte ni revente, avec une option d’export à tout moment. C’est une option pertinente quand votre équipe n’a pas de temps à consacrer à la rotation de clés ou à la supervision d’un tunnel IPsec, mais que la souveraineté des données reste une exigence non négociable.

Si votre organisation cherche à sécuriser ses échanges entre sites sans recruter un administrateur réseau supplémentaire, la page consacrée au serveur privé Yundera détaille les fonctionnalités disponibles et la manière de démarrer. Les petites structures qui veulent réduire leurs coûts d’infrastructure IT trouveront aussi des repères concrets sur la page dédiée aux startups et PME.

Documentation officielle pour aller plus loin

Pour approfondir la configuration, la documentation strongSwan couvre en détail les scénarios IPsec en entreprise, tandis que le site du projet SoftEther documente son fonctionnement multi-protocole. Le guide VPN IPsec site à site sur MikroTik reste une référence pratique pour les configurations pas à pas sur routeur.

Sources

Questions fréquentes

C’est quoi un VPN site à site ?

C’est un tunnel chiffré permanent qui relie deux réseaux locaux distants via Internet, permettant aux machines de chaque côté de communiquer comme si elles étaient sur le même réseau physique.

Comment configurer un VPN site à site open source ?

Réunissez les IP publiques et sous-réseaux de chaque site, choisissez WireGuard ou strongSwan selon votre matériel, configurez les pairs avec leurs routes et AllowedIPs, ajoutez une règle de contournement NAT avant la masquerade, puis validez avec des tests de ping et de traceroute dans les deux sens.

Quel protocole open source choisir pour un VPN site à site simple ?

WireGuard convient à la majorité des cas grâce à sa simplicité de configuration et sa faible consommation CPU ; strongSwan reste préférable si vous devez interconnecter des équipements réseau anciens ou hétérogènes.

Oui, l’usage d’un VPN, y compris site à site, est parfaitement légal en France pour un usage professionnel ou personnel ; seule l’utilisation qui en est faite peut poser problème si elle sert à commettre une infraction.

Que faire si le tunnel VPN site à site ne laisse passer aucun trafic ?

Vérifiez en priorité l’ordre des règles NAT sur chaque passerelle et la cohérence des AllowedIPs ou des politiques IPsec entre les deux extrémités, puis inspectez les logs et un tcpdump sur l’interface physique pour localiser où les paquets se perdent.

Recommandations

분류 Français
로그인 의견을 남기기