VPN site à site entre bureaux + DHCP : comment éviter les conflits d’adresses IP et le chaos

Le modèle mental : ce qui casse réellement quand vous connectez des bureaux

Un VPN site-à-site n’est pas magique. C’est un tuyau. Les tuyaux ne négocient pas de sémantique ; ils déplacent des paquets. Le chaos commence
quand ces paquets portent des hypothèses qui allaient très bien isolément :

• Hypothèse n°1 : « 192.168.1.0/24 signifie mon bureau. » Après le VPN, ça peut signifier « les deux bureaux ». Ce n’est pas une signification ; c’est une collision.
• Hypothèse n°2 : DHCP est « local et inoffensif ». Ce n’est pas le cas. DHCP est un plan de contrôle pour l’identité (IP), le routage (passerelle par défaut) et la résolution de noms (DNS).
• Hypothèse n°3 : la découverte basée sur le broadcast fonctionnera entre bureaux. Ce ne sera pas le cas, sauf si vous faites un bridge délibéré, et le bridging importe tous les problèmes L2 dans votre réseau L3.
• Hypothèse n°4 : « Le VPN est lent » lorsque la route est incorrecte, que le DNS est en split‑brain, ou que le MTU grignote discrètement vos paquets.

Le VPN change le domaine de défaillance. Une faute de frappe dans un bureau échoue maintenant pour les deux. Un serveur DHCP malveillant dans un bureau
a un terrain de chasse plus large (selon le bridging/les relais). Et vos diagnostics deviennent plus difficiles car
les symptômes apparaissent loin de leurs causes.

Si vous voulez une phrase pour guider votre conception, utilisez ceci :
Maintenez chaque bureau comme un domaine L3 indépendant, connectez-les par routage, et centralisez uniquement ce que vous pouvez surveiller et contraindre.

Une citation à garder sur un post‑it pour le travail VPN et DHCP : « L’espoir n’est pas une stratégie. » — Gene Kranz.
Oui, ça vient du contrôle de mission, pas du réseau. Le point reste valable.

Blague n°1 : Un VPN site-à-site, c’est comme un mariage : il ne règle pas vos problèmes de communication, il les rend juste plus audibles.

Faits intéressants et contexte historique (parce que l’histoire se répète)

1. RFC 1918 (1996) nous a donné des plages IPv4 privées (10/8, 172.16/12, 192.168/16). Il a résolu la pénurie d’adresses et créé le sport moderne des sous‑réseaux qui se chevauchent.
2. DHCP est devenu une norme au début des années 1990 (évolution de BOOTP). Il a été conçu pour des LANs avec broadcast ; l’histoire « sur un WAN » est venue plus tard via les relais.
3. Les domaines de broadcast ont toujours été une limite de montée en charge. Les premiers réseaux de campus ont appris vite que l’expansion L2 transforme « une mauvaise machine » en « mystère à l’échelle de l’entreprise ».
4. IPsec (fin des années 1990) visait à sécuriser l’IP au niveau Layer 3. Beaucoup de déploiements construisent encore par accident un comportement Layer 2 au‑dessus, et le paient.
5. Le NAT n’était pas censé être éternel. C’était une bidouille pratique pour l’épuisement d’IPv4. Il est toujours là, et il casse encore les hypothèses bout en bout et complique le dépannage.
6. Le DNS fractionné existe parce que la réalité est désordonnée. L’idée d’avoir des réponses différentes selon d’où on interroge est plus ancienne que beaucoup d’équipes « cloud‑native ».
7. « Le VPN est lent » est devenu un trope parce que les problèmes de MTU sont silencieux. L’historique des trous noirs PMTUD est long et plein de pertes de paquets.
8. Les jeux d’options DHCP sont devenus un système de configuration de facto. Téléphones, démarrage PXE, imprimantes et contrôleurs Wi‑Fi attendent des options spécifiques, donc les erreurs DHCP provoquent des pannes étonnamment ciblées.
9. BGP sur IPsec est courant maintenant pour le routage dynamique entre sites, mais ça ne fonctionne bien que si votre plan d’adressage est sain dès le départ.

Stratégie d’adressage IP : la partie à décider dès le départ

Règle 1 : n’autorisez jamais de sous‑réseaux qui se chevauchent entre sites

Si le Bureau A et le Bureau B utilisent tous deux 192.168.1.0/24, vous n’avez pas un « problème de VPN ». Vous avez un problème d’identité.
La table de routage ne peut pas distinguer « 192.168.1.50 au Bureau A » de « 192.168.1.50 au Bureau B ». Vous verrez :
routage asymétrique, bizarreries ARP si vous faites du bridging, et connectivité intermittente si quelqu’un ajoute du NAT en pansement.

Prise de position : renumérotez un site sauf si vous avez une raison métier à court terme d’utiliser le NAT comme tactique d’atténuation.
Le NAT est parfois nécessaire, mais ce n’est jamais l’état final propre.

Règle 2 : allouez à partir d’un vrai plan, pas d’impressions

Choisissez une plage privée suffisamment grande pour la croissance, puis découpez-la par site et par fonction. Un schéma simple :

• 10.64.0.0/10 réservé pour les réseaux internes d’entreprise.
• Chaque bureau obtient un /16 : Bureau A = 10.64.0.0/16, Bureau B = 10.65.0.0/16, etc.
• Dans le /16, découpez des /24 : utilisateurs, serveurs, voix, imprimantes, Wi‑Fi, invité, management.

Pourquoi un /16 par site ? Parce que renuméroter coûte cher, et les gens sous‑estiment la croissance et les réseaux « temporaires ».
Cela rend aussi les routes simples et synthétisables.

Règle 3 : décidez où vit la passerelle par défaut pour chaque VLAN

Si vous avez un routeur/pare‑feu par site, gardez les passerelles par défaut locales. Une passerelle par défaut distante via le VPN transforme chaque
paquet en trafic WAN. Vos utilisateurs le remarqueront. Votre file d’incidents le remarquera davantage.

Règle 4 : documentez la source d’autorité

Vous avez besoin d’une approche IPAM minimale, même si c’est « un dépôt Git avec du YAML ». L’important est qu’il existe un seul endroit
où les sous‑réseaux, les scopes DHCP, les réservations et les adresses statiques clés sont enregistrés et revus.

Schémas DHCP sur VPN (et pourquoi la plupart sont mauvais)

Schéma A : DHCP reste local dans chaque bureau (recommandé)

Chaque site exécute son propre serveur DHCP (ou paire HA) pour ses sous‑réseaux locaux. Le VPN ne transporte que le trafic routé.
C’est le domaine de défaillance le plus simple : si le serveur DHCP du Site B tombe, le Site A s’en fiche.

Centralisez le DNS si vous le voulez. Centralisez l’authentification si nécessaire. Mais gardez le DHCP proche des clients sauf
si vous avez de fortes raisons opérationnelles.

Schéma B : serveur DHCP central avec relais DHCP sur chaque site (fonctionne, mais demande de la discipline)

Cela peut fonctionner si vous voulez une gestion centralisée des scopes et des options cohérentes. L’essentiel est que les relais soient
correctement configurés et que le VPN soit fiable. Rappelez‑vous : les baux expirent même si votre WAN est tombé.

Si vous choisissez cela, mettez des durées de bail plus longues pour les sites distants, et assurez‑vous que les informations d’agent relais (Option 82)
sont soit utilisées intentionnellement, soit désactivées de manière cohérente. Un désalignement d’option peut rendre le dépannage hanté.

Schéma C : bridge L2 sur le VPN (ne le faites pas, sauf si vous aimez la douleur)

Le bridging signifie que les broadcasts DHCP traversent le VPN, l’ARP traverse le VPN, et chaque « qui a » devient une conversation inter‑site.
Cela aggrave la sécurité et la stabilité. Cela peut se justifier pour des cas de niche (protocoles legacy,
très petits réseaux, migrations de courte durée), mais cela doit être accompagné d’un plan de sortie explicite.

Schéma D : NAT pour masquer le chevauchement (acceptable en solution temporaire)

Quand des sous‑réseaux se chevauchent et que vous ne pouvez pas renuméroter immédiatement, vous pouvez NATer un côté afin que l’autre voie une plage traduite.
Ça « fonctionne » au sens où les paquets passent. Ça échoue au sens où l’identité devient bizarre : les logs mentent, les ACL deviennent
maladroites, et tout ce qui intègre des IPs (certains VoIP, certains systèmes de licensing, des bizarreries SMB anciennes) peut casser.

Blague n°2 : Le NAT, c’est comme balayer la poussière sous le tapis — impressionnant jusqu’à ce que vous trébuchiez sur le tapis.

Conception des scopes DHCP : évitez les pièges subtils

• Réservez des plages pour les statiques (équipements réseau, serveurs, hyperviseurs). Ne « choisissez pas quelque chose en dehors de la plage » sans le documenter.
• Utilisez des réservations DHCP pour imprimantes et points d’extrémité spéciaux. Les IPs d’imprimante aléatoires sont la clé de l’immortalité des tickets.
• Standardisez les jeux d’options (serveurs DNS, domaines de recherche, NTP). Si vous avez plusieurs serveurs DHCP, maintenez les options cohérentes via la gestion de configuration.
• Gardez des durées de bail sensées : 8–24 heures pour les réseaux utilisateurs, plus longues pour les dispositifs stables. Les baux ultra‑courts créent du churn lors d’instabilités WAN.

Routage, NAT, et pourquoi « juste NATer » est un piège

Routes statiques vs routage dynamique

Pour deux bureaux avec quelques sous‑réseaux, les routes statiques suffisent. Ajoutez un troisième site, ou plusieurs VLANs par site,
et les routes statiques deviennent une taxe de gestion des changements. C’est là que vous considérez :

• OSPF pour le routage interne si vous contrôlez les deux bouts et voulez une convergence rapide.
• BGP si vous voulez un contrôle explicite des routes et une synthèse propre à travers les tunnels.

Le routage dynamique n’est pas du « théâtre d’entreprise ». C’est la façon d’arrêter d’oublier une route pendant une migration stressante.

Tunneling fractionné vs maille complète

N’envoyez pas tout le trafic Internet via le VPN « pour la sécurité ». C’est un choix politique avec une facture de performance.
Si vous le faites, faites‑le en connaissance de cause : dimensionnez les liens, ajustez le MTU, surveillez, et acceptez que la voix/vidéo se plaigne en premier.

MTU : le saboteur silencieux

IPsec ajoute de l’overhead. GRE ajoute de l’overhead. WireGuard ajoute de l’overhead. Si vous n’ajustez pas le MTU ou ne clampiez pas le MSS, vous obtenez
fragmentation et problèmes PMTUD. Le symptôme classique : les petits pings fonctionnent, les gros transferts s’arrêtent, et HTTPS parfois
expire de manière aléatoire.

Frontières de sécurité

Un VPN n’est pas un modèle d’autorisations. Vous avez toujours besoin d’une politique de pare‑feu : quels sous‑réseaux peuvent communiquer, quels ports sont autorisés,
où vivent les interfaces d’administration, et comment vous journalisez les refus. « On les met sur un VPN pour qu’ils accèdent à tout » est la façon
de transformer un PC compromis en un incident multi‑site.

Trois mini-histoires issues de la vie en entreprise

Mini‑histoire 1 : un incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a acquis une société plus petite et s’est empressée de « connecter les bureaux » pour que la finance puisse accéder à l’ERP.
Les diagrammes réseau semblaient propres. Le VPN s’est établi du premier coup. Tout le monde a félicité l’équipe et est retourné à ses calendriers.

En quelques heures, le helpdesk reçu des tickets : les imprimantes du bureau acquis étaient « hors ligne », puis « en ligne », puis « hors ligne »
à nouveau. Les téléphones VoIP redémarraient de façon aléatoire. Quelques portables atteignaient les systèmes internes ; d’autres non. Le VPN a été blâmé.

La mauvaise hypothèse était simple : les deux côtés utilisaient 192.168.0.0/24 pour le LAN principal, parce que bien sûr ils le faisaient.
Les tables de routage des deux pare‑feux avaient des réseaux connectés identiques. Donc chaque côté croyait que 192.168.0.50 était local.
Les paquets n’ont même jamais franchi le tunnel. Les gens ont essayé d’ajouter des routes statiques (ce qui n’a pas aidé) et de bricoler les durées IPsec
(ce qui n’a pas aidé non plus).

La correction n’était pas glamour : renuméroter le bureau acquis vers un sous‑réseau unique, puis mettre à jour les scopes DHCP, les configurations d’imprimantes,
et une poignée d’appareils statiques. Pendant la transition, ils ont utilisé un NAT temporaire pour permettre à quelques systèmes critiques de communiquer.
Une fois la renumérotation terminée, l’« instabilité du VPN » a disparu du jour au lendemain.

La leçon : le tunnel n’est pas votre couche d’identité. L’adressage IP l’est. Traitez‑le comme tel.

Mini‑histoire 2 : une optimisation qui s’est retournée contre eux

Une autre organisation voulait « simplifier la gestion » en centralisant le DHCP dans le datacenter principal. Le bureau distant exécuterait juste un relais.
Cela semblait propre : une configuration de scope, un endroit pour auditer les options, un seul processus de changement.

Puis un fournisseur WAN a eu une mauvaise semaine. Courtes coupures — 30 secondes ici, deux minutes là. Rien d’assez long pour déclarer une panne totale.
Assez longues pour être exaspérantes.

Ce qui a échoué n’étaient pas les clients existants ; c’était le churn. Les téléphones redémarraient après des micro‑coupures de courant, les portables changeaient de SSID,
et les clients Wi‑Fi essayaient de renouveler. Les relais ne pouvaient pas atteindre le serveur DHCP central pendant les drops. Les clients tombaient en APIPA
ou conservaient des baux périmés qui ne correspondaient plus au DNS. Ça ressemblait à un « Wi‑Fi instable », car c’est ainsi que ça ressortait pour les utilisateurs.

Ils ont « optimisé » davantage en diminuant les durées de bail pour rendre la réutilisation d’IP plus efficace. Cela a augmenté la fréquence des renouvellements,
ce qui a accru la dépendance au WAN instable. L’équipe a construit une machine à échecs à haute fréquence puis s’est demandé pourquoi elle était bruyante.

La correction : remettre le DHCP sur site (ou ajouter un partenaire de basculement local), augmenter les durées de bail, et considérer la centralisation comme
un outil — qui a des exigences de fiabilité. Centralisez quand le lien est aussi ennuyeux que l’électricité. Sinon, gardez‑le local.

Mini‑histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise réglementée avait une politique qui semblait bureaucratique : chaque allocation de sous‑réseau était consignée dans une feuille IPAM soutenue par
un dépôt Git, et revue par deux personnes. Les changements de scope DHCP nécessitaient un petit ticket de changement et une check‑list de validation avant/après.
Personne n’aimait ça. Tout le monde s’y conformait parce que les audits étaient réels.

Lors d’un déménagement de bureau précipité, un entrepreneur a installé un routeur « temporaire » avec DHCP activé sur une table de labo. Dans beaucoup d’endroits,
c’est là que l’histoire devient une panne de deux jours. Ici, ça a été un désagrément de 20 minutes.

L’ingénieur d’astreinte a suivi la check‑list : vérifier les offres DHCP, identifier l’IP du serveur, trouver le port de switch via la table MAC,
couper le port, puis valider le renouvellement sur un client de test. Les enregistrements IPAM ont rendu évident quels scopes étaient légitimes et lesquels ne l’étaient pas.
L’historique du ticket de changement montrait une mise à jour de scope planifiée qui n’avait pas encore été appliquée, évitant une deuxième erreur.

La revue d’incident a été presque ennuyeuse. C’est le but. La « taxe de processus » a été payée à l’avance, donc la facture de la panne a été petite.

Mode opératoire de diagnostic rapide

Quand « VPN + DHCP » déraille, vous pouvez perdre des heures à deviner. Ne le faites pas. Trier rapidement.
Votre objectif est de trouver rapidement la classe de goulot d’étranglement : chevauchement d’adressage, routage, autorité DHCP, DNS, ou MTU.

Première étape : confirmez si vous avez des réseaux qui se chevauchent

• Comparez le(s) LAN local(s) avec le(s) LAN distant(s). Si chevauchement, arrêtez‑vous et planifiez une remédiation ou du NAT.
• Vérifiez les routes : si le même préfixe existe comme « connecté » des deux côtés, vous avez un conflit de conception.

Deuxième étape : confirmez la symétrie du routage et la politique de pare‑feu

• Le Site A peut‑il atteindre l’interface du routeur du Site B ? Le Site B peut‑il atteindre celle du Site A ?
• Les routes de retour existent‑elles ? La politique autorise‑t‑elle le trafic dans les deux sens ?
• Vérifiez les règles NAT asymétriques qui réécrivent dans un seul sens.

Troisième étape : déterminez si c’est DHCP, DNS ou MTU

• Problème DHCP si les clients reçoivent une passerelle/DNS incorrects, des avertissements d’IP dupliquée, ou des adresses APIPA.
• Problème DNS si le ping par IP fonctionne mais les noms échouent, ou les noms internes résolvent vers des cibles publiques/incorrectes.
• Problème MTU si les petits pings fonctionnent, les gros paquets échouent, et HTTPS/SMB sont instables.

Quatrième étape : capturez les paquets au bon endroit

Capturer depuis le client est bien. Capturer sur l’interface du routeur côté LAN est mieux.
Capturer sur l’interface du tunnel est optimal lorsque vous prouvez ce qui a traversé le VPN.

Tâches pratiques avec commandes (quoi lancer, ce que ça signifie, décisions à prendre)

Ces tâches supposent des routeurs/serveurs basés sur Linux pour les exemples. Les idées se traduisent directement vers pfSense/OPNsense, DHCP Windows,
et pare‑feux managés ; l’essentiel est ce que vous vérifiez et pourquoi.

Tâche 1 : lister les interfaces locales et les sous‑réseaux (repérer les chevauchements évidents)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.64.10.2/24
eth1             UP             10.64.20.1/24

Ce que ça signifie : cet hôte est connecté directement à 10.64.10.0/24 et 10.64.20.0/24.
Décision : comparez ces préfixes avec les préfixes du bureau distant. S’il y a chevauchement, vous êtes en mode remédiation, pas optimisation.

Tâche 2 : inspecter la table de routage (prouver où ira le trafic)

cr0x@server:~$ ip route
default via 10.64.10.1 dev eth0
10.64.10.0/24 dev eth0 proto kernel scope link src 10.64.10.2
10.64.20.0/24 dev eth1 proto kernel scope link src 10.64.20.1
10.65.0.0/16 via 10.64.10.254 dev eth0

Ce que ça signifie : le trafic vers 10.65.0.0/16 (bureau distant) passe via 10.64.10.254 (probablement le routeur VPN).
Décision : si les réseaux distants ne sont pas présents ici, ajoutez des routes (statiques ou dynamiques). Si vous voyez une route plus spécifique pointant ailleurs, corrigez ce conflit d’abord.

Tâche 3 : vérifier l’état du tunnel (ne dépannez pas DHCP via un tunnel down)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2lQf...redacted...
  listening port: 51820

peer: 3mHf...redacted...
  endpoint: 203.0.113.10:51820
  allowed ips: 10.65.0.0/16
  latest handshake: 42 seconds ago
  transfer: 1.23 GiB received, 980 MiB sent

Ce que ça signifie : WireGuard est opérationnel et échange du trafic récemment.
Décision : si les handshakes sont obsolètes, réparez d’abord le tunnel (clés, pare‑feu, NAT, atteignabilité). Aucune logique DHCP ne compte tant que les paquets ne circulent pas.

Tâche 4 : tester l’accessibilité et le chemin (confirmer routage et ACL)

cr0x@server:~$ ping -c 3 10.65.10.1
PING 10.65.10.1 (10.65.10.1) 56(84) bytes of data.
64 bytes from 10.65.10.1: icmp_seq=1 ttl=63 time=22.1 ms
64 bytes from 10.65.10.1: icmp_seq=2 ttl=63 time=21.7 ms
64 bytes from 10.65.10.1: icmp_seq=3 ttl=63 time=22.4 ms

--- 10.65.10.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Ce que ça signifie : la connectivité L3 existe au moins jusqu’à la passerelle distante.
Décision : si le ping échoue, vérifiez routes et pare‑feu. Si le ping fonctionne mais que les applications échouent, vous avez probablement affaire au DNS, au MTU, ou à un filtrage au niveau des ports.

Tâche 5 : tester le MTU avec des pings « ne pas fragmenter » (trouver le trou noir)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.65.10.1
PING 10.65.10.1 (10.65.10.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420

--- 10.65.10.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Ce que ça signifie : votre MTU effectif sur le chemin est inférieur à 1500 ; 1420 est courant pour WireGuard.
Décision : clampiez le MSS TCP sur le tunnel ou définissez le MTU approprié sur les interfaces. Si vous l’ignorez, vous continuerez à « déboguer » des SMB/HTTPS instables pour toujours.

Tâche 6 : afficher les baux DHCP sur un serveur Linux (valider le comportement des scopes)

cr0x@server:~$ sudo tail -n 8 /var/lib/dhcp/dhcpd.leases
lease 10.64.10.101 {
  starts 5 2025/12/27 10:22:10;
  ends 5 2025/12/27 22:22:10;
  cltt 5 2025/12/27 10:22:10;
  binding state active;
  hardware ethernet 3c:52:82:aa:bb:cc;
  client-hostname "laptop-hr";
}

Ce que ça signifie : le serveur distribue des adresses dans le sous‑réseau attendu à un MAC connu.
Décision : si les baux montrent des adresses d’un scope incorrect ou des sous‑réseaux inattendus, vous avez mal configuré les scopes ou les relais (ou un serveur DHCP rogue existe ailleurs).

Tâche 7 : renifler les offres DHCP (attraper un DHCP rogue ou un mauvais relais)

cr0x@server:~$ sudo tcpdump -ni eth0 -vvv 'port 67 or port 68' -c 6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:31:00.102345 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:52:82:aa:bb:cc, length 300
10:31:00.105210 IP 10.64.10.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, yiaddr 10.64.10.101, Server-ID 10.64.10.5
10:31:00.106901 IP 10.64.10.250.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, yiaddr 10.64.10.199, Server-ID 10.64.10.250

Ce que ça signifie : deux serveurs DHCP différents proposent des baux (10.64.10.5 et 10.64.10.250).
Décision : trouvez et désactivez le serveur rogue ou isolez‑le. Dans un scénario VPN multi‑site, confirmez que vous n’avez pas accidentellement fait du bridging L2 ou relayed le DHCP là où il ne fallait pas.

Tâche 8 : vérifier si un relais DHCP est configuré (et où il forwarde)

cr0x@server:~$ ps aux | grep -E 'dhcrelay|isc-dhcrelay' | grep -v grep
root      1123  0.0  0.1  18720  4120 ?        Ss   10:01   0:00 /usr/sbin/dhcrelay -4 -i eth1 10.64.10.5

Ce que ça signifie : cette machine relaie les requêtes DHCP de l’interface eth1 vers le serveur DHCP 10.64.10.5.
Décision : si ce serveur est à travers le VPN, assurez‑vous que le relais a un routage stable, que le pare‑feu permet UDP 67/68, et que les durées de bail sont appropriées à la dépendance WAN.

Tâche 9 : valider la résolution DNS depuis un site distant (séparer DNS et routage)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.64.20.10
       DNS Servers: 10.64.20.10 10.64.20.11
        DNS Domain: corp.example

Link 2 (eth0)
Current Scopes: DNS

Ce que ça signifie : le système utilise des serveurs DNS internes (10.64.20.10/.11).
Décision : si un client du bureau distant pointe vers un serveur DNS qu’il ne peut pas atteindre (à cause de routes manquantes ou de pare‑feu), le DHCP « fonctionne » mais fournit une configuration inutilisable. Corrigez les options DHCP ou le routage.

Tâche 10 : prouver résolution de nom vs connectivité (arrêtez de blâmer le VPN pour le DNS)

cr0x@server:~$ getent hosts fileserver.corp.example
10.65.20.20     fileserver.corp.example

Ce que ça signifie : le DNS (ou NSS) résout le nom vers une IP distante.
Décision : si la résolution échoue mais que le ping IP fonctionne, vous devez corriger le DNS (forwarders, split‑horizon, domaines de recherche, ou option DHCP 15/6). Si la résolution fonctionne mais que la connexion échoue, c’est routage/pare‑feu/MTU.

Tâche 11 : tracer la route (repérer des sauts asymétriques ou inattendus)

cr0x@server:~$ tracepath 10.65.20.20
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.64.10.254                                          1.012ms
 2:  10.65.0.1                                            22.104ms
 3:  10.65.20.20                                          23.001ms reached
     Resume: pmtu 1420 hops 3 back 3

Ce que ça signifie : le trafic traverse le routeur VPN et atteint la destination ; le PMTU est 1420.
Décision : si la liste des sauts montre un hairpinning Internet ou un routeur inattendu, corrigez vos routes. Si le PMTU est bas et que les applications cassent, clampiez le MSS.

Tâche 12 : vérifier les compteurs du pare‑feu pour le trafic droppé (prouver des problèmes de politique)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "eth1" ip saddr 10.65.0.0/16 ip daddr 10.64.20.0/24 accept
    counter packets 0 bytes 0 drop
  }
}

Ce que ça signifie : la politique forward par défaut est drop ; seul un flux wg0→eth1 spécifique est autorisé. Le compteur drop existe et peut augmenter ailleurs.
Décision : si les compteurs montrent des drops pour des flux attendus, ajustez la politique volontairement. Si vous « autorisez temporairement tout » pour tester, pensez à revenir en arrière ; les règles temporaires ont tendance à devenir une architecture permanente.

Tâche 13 : détecter des IP dupliquées depuis un endpoint (l’ARP vous trahit)

cr0x@server:~$ ip neigh show dev eth0 | grep '10.64.10.101'
10.64.10.101 lladdr 3c:52:82:aa:bb:cc REACHABLE

Ce que ça signifie : l’IP mappe actuellement à un seul MAC.
Décision : si ce MAC change fréquemment sans que le dispositif ne bouge, vous pouvez avoir des conflits IP ou un serveur DHCP rogue. Corrélez avec les logs DHCP et les tables MAC des switches.

Tâche 14 : identifier le port de switch pour un MAC suspect (trouver la machine rogue)

cr0x@server:~$ ssh admin@switch-a01 "show mac address-table address 3c:52:82:aa:bb:cc"
Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    3c:52:82:aa:bb:cc DYNAMIC     Gi1/0/24

Ce que ça signifie : le MAC est appris sur le port Gi1/0/24 en VLAN 10.
Décision : si ce port mène à un switch non‑managé ou un routeur « temporaire », coupez‑le ou déplacez‑le vers un VLAN isolé. Puis retestez les offres DHCP.

Tâche 15 : valider l’identité du serveur DHCP depuis un client Windows (commun dans les bureaux)

cr0x@server:~$ ssh user@winclient "ipconfig /all | findstr /I \"DHCP Server IPv4 Address\""
   DHCP Server . . . . . . . . . . . : 10.64.10.5
   IPv4 Address. . . . . . . . . . . : 10.64.10.101

Ce que ça signifie : le client obtient un bail de 10.64.10.5.
Décision : si le serveur DHCP change entre renouvellements, vous avez plusieurs répondants DHCP. C’est un problème de confinement, pas un « réglage de VPN ».

Tâche 16 : confirmer les options DHCP livrées (les erreurs de passerelle/DNS ressemblent à des pannes VPN)

cr0x@server:~$ sudo dhclient -v -1 eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 10.64.10.120 from 10.64.10.5
DHCPREQUEST for 10.64.10.120 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.64.10.120 from 10.64.10.5
bound to 10.64.10.120 -- renewal in 36000 seconds.

Ce que ça signifie : la négociation DHCP a réussi.
Décision : inspectez la route appliquée et resolv.conf après cela. Si la passerelle pointe par accident vers un site distant via le VPN, corrigez les options de scope ; ne blâmez pas le tunnel pour avoir fait ce que vous lui avez demandé.

Erreurs courantes : symptôme → cause racine → correction

1) « Certains utilisateurs peuvent atteindre le bureau distant, d’autres non »

• Symptôme : accès intermittent ; un bureau fonctionne, un autre pas ; un reboot « règle » brièvement.
• Cause racine : sous‑réseaux qui se chevauchent, ou plusieurs serveurs DHCP assignant des passerelles/DNS différents.
• Correction : éliminez le chevauchement en renumérotant ; reniflez les offres DHCP ; coupez le DHCP rogue ; standardisez les options de scope.

2) « Le VPN est up mais rien ne route »

• Symptôme : le tunnel montre connecté/handshake OK, mais les sous‑réseaux distants sont injoignables.
• Cause racine : routes manquantes (ou allowed IPs manquantes dans WireGuard), ou politique forward du pare‑feu bloquante.
• Correction : ajoutez des routes explicites des deux côtés ; vérifiez forward/NAT ; confirmez la symétrie du chemin de retour avec tracepath.

3) « Le DNS marche localement, échoue depuis l’autre bureau »

• Symptôme : ping par IP fonctionne ; les noms expirent ; ou résolvent vers de mauvaises cibles.
• Cause racine : le DHCP fournit des serveurs DNS inaccessibles ; split DNS mal configuré ; pare‑feu bloque TCP/UDP 53 sur le VPN.
• Correction : assurez‑vous que les sites distants peuvent joindre les serveurs DNS ; ajoutez des résolveurs de cache locaux si nécessaire ; autorisez le DNS sur le VPN ; validez avec getent/dig.

4) « SMB/HTTPS est instable, mais le ping fonctionne »

• Symptôme : copies de fichiers qui s’arrêtent ; applications web qui se chargent partiellement ; RDP qui gèle parfois.
• Cause racine : MTU/PMTUD black hole ; absence de clamp MSS.
• Correction : clampiez le MSS TCP sur le tunnel ; réglez le MTU des interfaces ; retestez avec ping -M do et tracepath PMTU.

5) « Après la connexion du VPN, les imprimantes ont commencé à dupliquer ou changer d’IP »

• Symptôme : IP d’imprimante qui changent ; files d’impression cassées ; avertissements d’IP dupliquée.
• Cause racine : imprimante en DHCP avec config statique mémorisée ; deux sites utilisent le même subnet d’imprimantes ; ou réservations DHCP non utilisées.
• Correction : réservez les MAC d’imprimante ; gardez les imprimantes dans un VLAN dédié par site ; évitez les sous‑réseaux d’imprimantes qui se chevauchent ; documentez les statiques dans l’IPAM.

6) « Le Wi‑Fi invité peut voir des ressources corporate après le projet VPN »

• Symptôme : des clients invités atteignent des IP ou services internes.
• Cause racine : domaines de chiffrement VPN/allowed IPs trop larges ; règles pare‑feu non segmentées ; routes fuitées entre VRF/VLAN.
• Correction : restreignez les sélecteurs VPN/allowed IPs aux sous‑réseaux requis ; appliquez la politique inter‑VLAN ; bloquez explicitement guest→corp via le tunnel.

7) « Tout casse lors des coupures WAN, puis récupère lentement »

• Symptôme : après de brèves coupures, beaucoup d’endpoints perdent la connectivité ; la récupération prend des heures.
• Cause racine : DHCP centralisé dépendant du WAN ; durées de bail courtes ; dépendance DNS distante sans cache local.
• Correction : gardez le DHCP local ou ajoutez un basculement local ; allongez les baux ; déployez des résolveurs de cache locaux ; traitez le WAN comme peu fiable jusqu’à preuve du contraire.

8) « Nous avons résolu le chevauchement avec du NAT, maintenant les logs et ACL sont bizarres »

• Symptôme : les outils de sécurité montrent la passerelle NAT comme source ; les règles par hôte ne fonctionnent plus proprement ; le dépannage est plus difficile.
• Cause racine : le NAT masque les adresses réelles par définition ; vous avez troqué la clarté du routage contre la complexité de la traduction.
• Correction : n’utilisez le NAT que comme outil de migration limité dans le temps ; implémentez la renumérotation ; mettez à jour les ACL pour correspondre à l’adressage réel ; améliorez les logs avec des traces de traduction NAT pendant la transition.

Listes de contrôle / plan pas à pas

Pas à pas : concevoir un nouveau VPN bureau‑à‑bureau sans regret futur

1. Inventoriez les sous‑réseaux sur les deux sites. Listez chaque VLAN/sous‑réseau, y compris le Wi‑Fi invité, la voix, les imprimantes, le management, et les réseaux « temporaires » de labo.
2. Choisissez un plan d’adressage cohérent. Allouez au moins un /16 par site si possible. Consignez‑le dans votre source d’autorité.
3. Définissez ce qui doit être joignable. Matrice sous‑réseau‑vers‑sous‑réseau : qui doit parler à qui, sur quels ports. Refuser par défaut, puis autoriser délibérément.
4. Choisissez le modèle DHCP. Préférez le DHCP local par site. Si vous centralisez, engagez‑vous sur la configuration des relais, la surveillance, et des durées de bail plus longues.
5. Décidez de l’architecture DNS. Les résolveurs centraux vont bien s’ils sont joignables ; sinon utilisez des caches locaux qui forwardent vers le central. Planifiez le split DNS pour les zones internes.
6. Choisissez la stratégie de routage. Routes statiques pour petit et stable. Routage dynamique quand la croissance ou la fréquence de changement est élevée.
7. Ingéniez le MTU dès le départ. Définissez le MTU/MSS du tunnel tôt. Validez avec des tests « ne pas fragmenter ».
8. Verrouillez les sélecteurs/allowed IPs du VPN. N’annoncez que les préfixes internes que vous voulez réellement router. Pas de « 0.0.0.0/0 parce que ça marche ».
9. Surveillance et logs. Tunnel up/down, latence, perte de paquets, santé des serveurs DHCP, latence DNS, refus pare‑feu. Si vous ne pouvez pas le voir, vous ne pouvez pas l’exploiter.
10. Exécutez un plan de test pré‑cutover. Bail DHCP, résolution DNS, accessibilité aux services clés, et un test de transfert de fichier (SMB/HTTPS) pour détecter le MTU.

Pas à pas : quand vous avez déjà des sous‑réseaux qui se chevauchent

1. Confirmez le chevauchement et identifiez le rayon minimal d’impact. Quels préfixes se chevauchent ? Quels systèmes doivent communiquer maintenant ?
2. Choisissez une voie de remédiation :
   • Meilleur : renumérotez un site (ou au moins les sous‑réseaux qui ont besoin de connectivité inter‑site).
   • Temporaire : NATez un côté vers une plage de traduction qui ne chevauche pas.
   • À éviter : bridger pour « en faire un seul LAN ». C’est une fusion de domaines de broadcast, pas une solution.
3. Si renumérotation : créez de nouveaux scopes DHCP, mettez à jour passerelles, DNS et réservations ; migrez VLAN par VLAN ; gardez un plan de rollback.
4. Si vous utilisez NAT : consignez les traductions, documentez le mapping, et fixez une date d’expiration. Vérifiez les applications dépendantes de l’IP source.
5. Après remédiation : supprimez le NAT/règles temporaires, resserrez le pare‑feu, et mettez à jour l’IPAM/source d’autorité.

Checklist opérationnelle : prévenir le chaos DHCP

• Activez le DHCP snooping sur les commutateurs d’accès lorsque disponible, et trustez seulement les uplinks vers vos vrais serveurs/relays DHCP.
• Gardez les serveurs DHCP autoritatifs pour leurs scopes ; évitez les définitions de scope dupliquées sauf en vrai mode failover.
• Standardisez les jeux d’options DHCP et versionnez‑les.
• Utilisez des réservations pour les dispositifs « semi‑statiques » (imprimantes, téléphones, lecteurs de badges).
• Auditez la présence de DHCP rogue trimestriellement (ou après des déménagements).
• Surveillez l’épuisement des pools et alertez avant que la plage ne soit saturée.

FAQ

1) Puis‑je exécuter un seul serveur DHCP pour les deux bureaux via un VPN ?

Oui, via un relais DHCP. Mais vous déplacez une dépendance critique du plan de contrôle sur votre WAN. Si le WAN n’est pas extrêmement stable,
gardez le DHCP local ou déployez un basculement local.

2) Pourquoi le DHCP ne peut‑il pas simplement « traverser le VPN » naturellement ?

Le DHCP utilise le broadcast pour la découverte sur un LAN. Les VPN routés ne transportent pas les broadcasts. Vous avez besoin d’un relais, ou de
faire du bridage L2, et le bridage est généralement le mauvais compromis.

3) Quelle est la correction la plus propre pour des sous‑réseaux qui se chevauchent ?

Renumérotez un côté vers un préfixe unique. C’est du travail, mais cela vous apporte la correction. Le NAT est acceptable comme tactique de migration
limitée dans le temps, pas comme personnalité permanente.

4) Si nous devons NATer, à quoi devons‑nous faire attention ?

La journalisation et le contrôle d’accès deviennent moins granulaires, certaines applications incorporent des IPs, et le dépannage devient plus difficile car
les captures montrent des identités traduites. Documentez le mapping et planifiez son retrait.

5) Pourquoi de petits pings fonctionnent mais les transferts de fichiers échouent via le VPN ?

Problème classique MTU/PMTUD. L’encapsulation réduit le MTU effectif. Sans clamp MSS ou réglage approprié du MTU, les paquets plus grands sont perdus,
et TCP se fige d’une façon qui ressemble à de la lenteur aléatoire.

6) Comment détecter rapidement un serveur DHCP rogue ?

Lancez une capture de paquets pour les offres DHCP sur le VLAN affecté et recherchez plusieurs adresses Server‑ID. Puis localisez le MAC dans la table MAC du switch
et coupez/isolez ce port.

7) Les deux bureaux doivent‑ils partager les mêmes serveurs DNS ?

Ils le peuvent, mais assurez‑vous de la joignabilité et d’une faible latence. Un bon schéma est d’avoir des résolveurs de cache locaux dans chaque bureau qui forwardent vers
les serveurs centraux autoritatifs. Cela réduit la dépendance VPN pour chaque requête DNS.

8) Routes statiques ou routage dynamique pour une petite entreprise ?

Deux sites, quelques sous‑réseaux : les routes statiques conviennent. Plus de sites, changements fréquents, ou beaucoup de VLANs : utilisez OSPF ou BGP pour arrêter d’oublier
des routes lors d’opérations urgentes.

9) Quelle durée de bail devrions‑nous utiliser pour les clients d’un site distant ?

Si le DHCP est local, des durées standard (8–24 heures pour les réseaux utilisateurs) vont bien. Si le DHCP est centralisé via le VPN, utilisez des baux plus longs
pour que de brèves interruptions WAN ne déclenchent pas des renouvellements massifs et du churn.

10) Le bridging est‑il jamais acceptable sur un VPN site‑à‑site ?

Rarement, et généralement temporairement : besoins legacy de niche, migrations courtes, ou environnements très petits où vous acceptez les risques sciemment.
Si vous faites du bridging, documentez le plan de sortie dès le jour un.

Conclusion : prochaines étapes qui réduisent vraiment le risque

Les projets de VPN bureau‑à‑bureau échouent de manières prévisibles. Pas parce que les tunnels sont mystérieux, mais parce que l’adressage, le DHCP,
le DNS et le routage sont des problèmes de gouvernance qui se déguisent en problèmes de connectivité.

Faites ceci ensuite, dans l’ordre :

1. Consignez chaque sous‑réseau sur chaque site et éliminez le chevauchement. Si vous ne pouvez pas l’éliminer immédiatement, utilisez le NAT avec un plan d’abandon explicite.
2. Choisissez votre modèle DHCP délibérément : local par site par défaut ; relais vers le central seulement quand le WAN et la maturité opérationnelle le justifient.
3. Verrouillez le routage et la politique de pare‑feu sur exactement ce dont vous avez besoin, puis surveillez les drops et la santé du tunnel.
4. Validez MTU/MSS tôt pour ne pas passer une semaine à accuser « le VPN » d’un problème de mathématique de taille de paquet.
5. Rendez‑le ennuyeux : une petite source d’autorité IPAM, des check‑lists répétables, et la compétence en capture de paquets battent les exploits héroïques à chaque fois.

Si vous faites cela correctement, le VPN redevient ce qu’il a toujours dû être : un transport sans histoire. Vos utilisateurs ne le remarqueront pas.
C’est le succès.