VPN et réseau domestique sur le même sous-réseau : suivez d'abord la route
Les deux adaptateurs revendiquent 192.168.1.0/24 et une seule route l'emporte. Suivez la liste des adaptateurs, la route gagnante et le chemin de retour avant de renuméroter ou d'accuser le DNS.
Vous vous connectez au VPN du bureau, l'icône de la barre des tâches passe au vert, l'intranet se charge et l'imprimante à deux mètres cesse de répondre. Le partage qui fonctionnait ce matin expire sur la même machine, et aucun journal ne mentionne d'imprimante. Le réflexe est le DNS, parce qu'un nom qui ne se résout pas ressemble à un nom qui n'existe pas, mais le problème est l'adresse : deux adaptateurs revendiquent désormais 192.168.1.0/24 et une seule route peut gagner ce préfixe. Suivez-la dans cet ordre et vous verrez quel adaptateur l'a prise avant de changer quoi que ce soit.
Commencez par le symptôme, pas par le tunnel
L'indice, c'est la portée. Si l'intranet fonctionne et que chaque appareil local échoue, le tunnel est sain et le chemin local ne l'est pas. Si les appareils locaux fonctionnent et que l'intranet échoue, l'inverse. Si tout fonctionne sauf un hôte, vous êtes devant une seule adresse présente des deux côtés.
Notez une adresse locale et une adresse distante avant de toucher à un réglage. « L'imprimante » n'est pas testable ; 192.168.1.40 l'est. Cette seule étape évite l'heure perdue la plus courante sur ce problème, qui est de réécrire les réglages DNS pour une décision de routage.
Étape 1 : voyez les deux adaptateurs revendiquer le préfixe
Ouvrez Connexions réseau (ncpa.cpl) et lisez les deux adaptateurs côte à côte. L'adaptateur Ethernet affiche 192.168.1.50/24 avec la passerelle 192.168.1.1. L'adaptateur VPN affiche 192.168.1.201/24, poussé par le serveur. Les deux sont légitimes, les deux croient que le préfixe est on-link, et la pile n'en gardera qu'une seule route.
Get-NetIPAddress -AddressFamily IPv4 liste les adresses, et Get-NetIPInterface | Sort-Object InterfaceMetric montre l'ordre dans lequel la pile les utilisera. Cette colonne de métrique est la décision que vous êtes sur le point de lire, alors notez les nombres plutôt que de les retenir.
Réfutez la théorie du DNS à moindres frais : Resolve-DnsName printer.office.lan renvoie la même adresse qu'hier. Le nom s'est résolu ; le paquet est ensuite sorti par le mauvais adaptateur. Deux minutes ici épargnent un après-midi dans les réglages du résolveur.
Étape 2 : lisez la route qui a réellement gagné
Find-NetRoute -RemoteIPAddress 192.168.1.40 affiche l'interface, le saut suivant et la source que la pile utiliserait pour cette adresse. Traitez cette sortie comme la réponse, pas comme un indice. route print -4 donne toute la table quand vous voulez voir quelle entrée a perdu et de combien.
La spécificité l'emporte sur l'intention. Un 192.168.0.0/25 poussé bat un 192.168.0.0/24 local parce que le préfixe est plus long, donc 192.168.0.0 à 192.168.0.127 sortent par le tunnel tandis que la moitié haute reste locale. Qu'un demi-réseau disparaisse sans message d'erreur est le comportement correct de cette table.
tracert -d 192.168.1.40 le confirme depuis l'extérieur de la table : si le premier saut est une adresse de tunnel plutôt que votre propre routeur, la route est toute l'histoire. Sous Linux la même question est ip route get 192.168.1.40, qui affiche l'adresse source et le périphérique sur une ligne. Quand la réponse nomme tun0, cessez de regarder le navigateur.
Étape 3 : vérifiez le retour avant d'accuser le client
Une route aller correcte échoue quand même si le côté distant ne peut pas répondre. Quand un réseau client est atteint par le tunnel, la passerelle de ce réseau doit savoir où vit le pool du tunnel : ip route add 10.8.0.0/24 via 192.168.1.12 sur ce routeur, et push « route 192.168.1.0 255.255.255.0 » depuis le serveur pour que les clients connaissent le retour.
Sans la première entrée, la réponse quitte la cible vers sa passerelle par défaut, qui transmet une adresse privée au fournisseur et la jette. Le symptôme est unidirectionnel et facile à mal lire : les requêtes apparaissent sur tun0, les réponses jamais.
Une règle masquerade sur l'hôte VPN supprime le besoin de cette route statique : iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Elle masque aussi les vraies adresses source, ce qui rend chaque question ultérieure sur les journaux plus difficile. Un hôte cible avec la mauvaise passerelle par défaut produit le même silence, avec une redirection ICMP au mieux et un trou noir en général, et c'est pourquoi la capture revient aux deux extrémités.
Étape 4 : choisissez une réparation vivable
Cinq réparations servent à cela, et elles ne sont pas interchangeables. Choisissez selon ce qui doit rester joignable en même temps, pas selon la commande la plus courte.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Les métriques sont l'option bon marché et celle vers laquelle on se tourne d'abord. Le changement porte sur l'interface, il fonctionne donc tant que le tunnel est monté, et il a sa place dans un script à côté du client plutôt que dans un shell que vous oublierez. Il ne peut pas donner un accès simultané à la même adresse sur deux réseaux, et c'est la limite qui renvoie tous les autres au reste de la table.
Renuméroter le réseau domestique en 10.10.0.0/24 est la solution propre : un renouvellement de bail DHCP plus les réservations, les files d'impression et les adresses codées en dur qui mentionnent l'ancienne plage. Renuméroter le côté bureau n'est généralement pas votre décision. IPv6 supprime entièrement le conflit quand les deux réseaux le portent, avec un préfixe local unique issu de fd00::/8 plutôt que quelque chose de mémorisable, mais testez l'application en TCP, pas au ping, car ICMP peut fonctionner alors que le service non.
L'option de traduction propre à OpenVPN est le dernier recours, poussée depuis le serveur dans une entrée de répertoire propre au client. Elle prend quatre paramètres après le nom de l'option — direction, réseau, masque et alias — et l'alias n'est pas facultatif : push "route 192.168.2.0 255.255.255.0" et push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Le réseau et le masque sont la plage que le client voit (192.168.2.0/24), l'alias est la vraie plage du bureau côté serveur (192.168.1.0/24), et la route poussée est ce qui rend cette plage visible joignable. Le bureau apparaît alors à ce client sous 192.168.2.x. Documentez le mappage dans le profil, sinon la personne suivante le déboguerà comme une panne de routage.
Publier un seul service est la version étroite de la traduction, et elle n'a pas besoin de l'option d'OpenVPN. Une règle DNAT sur l'hôte VPN republie un seul port, donc le réseau garde ses adresses et atteint le service à l'adresse d'hôte qu'il connaît déjà. Le coût est le coût habituel : le service voit l'hôte VPN comme source, donc les journaux par client et les recherches inverses cessent de signifier quoi que ce soit. Cela couvre une file d'impression ou une page d'administration, pas des hôtes des deux côtés qui s'atteignent.
Ce qui ne fonctionnera toujours pas, et ce qu'il faut consigner
La diffusion ne traverse pas un tunnel routé. DLNA, UPnP, la navigation NetBIOS et Wake-on-LAN dépendent de diffusion ou de multicast qu'un périphérique tun ne transporte pas, donc aucune route ne répare la découverte. Le pontage avec dev tap étend le segment, et avec lui les diffusions DHCP, ARP et tout autre paquet de découverte ; préférez une route d'hôte unicast comme route 192.168.2.1 255.255.255.255 pour l'adresse côté réseau d'un routeur distant.
Deux routeurs qui utilisent tous deux 192.168.1.1 sur le même chemin relèvent de la même famille de problème : l'adresse locale gagne toujours, donc la page du routeur distant reste injoignable jusqu'à ce qu'un réseau bouge. Ajouter un second adaptateur ne change rien dans l'un ou l'autre cas.
Consignez les preuves avant de modifier quoi que ce soit : ip route get ou Find-NetRoute, ping -c 3 vers l'adresse en question, un traceroute, et tcpdump -ni tun0 icmp sur le client, puis la table de routage et les compteurs NAT sur le serveur. Un ping qui fonctionne dans un sens et meurt dans l'autre pointe le chemin de retour, pas le tunnel, et cette seule distinction décide laquelle des réparations ci-dessus vous avez réellement besoin.