La maison et le bureau utilisent tous deux 192.168.1.x : que faire ?

Passez en revue quatre vérifications : vers quelle adresse le nom se résout, quel préfixe utilise le réseau local, quelle route le noyau choisit pour cette destination, et ce qui répond à l’autre extrémité. La connexion VPN n’en fait pas partie, car elle aboutit quel que soit le réseau qui gagne. Faites les vérifications dans l’ordre et le chevauchement deviendra visible à la deuxième étape plutôt qu’à la quatrième.

Une connexion réussie indique que le tunnel est actif ; elle ne dit rien sur la destination d’une adresse particulière.

Une adresse, deux machines

Un hôte choisit un chemin dans sa table de routage et ses règles de politique, en fonction de l’adresse de destination. Rien ne lui indique qu’une requête vers le saut 192.168.1.20 est destinée au serveur du bureau plutôt qu’à un appareil de la pièce voisine. Quand les deux réseaux sont dans la même plage privée, la route la plus spécifique l’emporte et tout le reste dépend de l’entrée qu’une reconnexion a installée par hasard. Rien dans l’adresse elle-même ne porte cette distinction.

ip route get 192.168.1.20

Cette recherche nomme l’interface et le saut suivant choisis par le noyau, ce qui est la deuxième vérification de la liste. Comparez les préfixes local et distant avant de faire quoi que ce soit d’autre. Si le réseau local est 192.168.1.0/24 et le site distant aussi 192.168.1.0/24, le chevauchement est le constat, et aucune option du client ne le répare.

Renumérotez le côté que vous contrôlez

Un routeur personnel est généralement le côté le plus facile à déplacer. Choisissez une plage qui n’entre pas en collision avec les réseaux distants que vous utilisez réellement, et notez que 10.x.x.x n’est pas libre automatiquement non plus, car beaucoup de sites l’utilisent. Planifiez le changement : les baux DHCP, les adresses réservées, les files d’impression et tout ce qui a une adresse codée en dur demandent de l’attention. Faites la renumérotation dans une fenêtre où vous pouvez récupérer le routeur sans le VPN.

Vérifiez la liste des préfixes distants d’abord, pas ensuite. Choisir une nouvelle plage qui entre en collision avec un autre site de bureau produit le même problème avec plus de travail investi.

Quand aucun des deux côtés ne peut changer

Si aucun des deux réseaux ne peut être renuméroté, les options restantes vivent sur le serveur. Une passerelle peut traduire un réseau distant en un autre sous-réseau pour les clients VPN, à l’aide de NAT basé sur des politiques ou d’une variante bidirectionnelle, afin que le client voie une adresse unique. C’est une conception de passerelle et non un commutateur que chaque client de bureau fournit, et elle change l’adresse que les utilisateurs saisissent et les noms qui doivent correspondre. Une route copiée d’un forum ne peut pas distinguer deux destinations identiques.

Les plages d’adresses privées restent privées ; le problème est la réutilisation, pas les plages elles-mêmes.

Prouvez quelle machine a répondu

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

Après chaque changement, testez la ressource du bureau et les appareils locaux ensemble. Si un appareil domestique familier répond là où devrait se trouver le serveur du bureau, ou si le certificat TLS nomme le mauvais hôte, arrêtez-vous et identifiez la destination avant de continuer. Obtenir une réponse depuis cette adresse ne prouve pas quelle machine l’a envoyée. Vérifier le sujet du certificat est l’un des rares signaux fiables disponibles à ce moment-là.

Ne remplacez pas les adresses privées du bureau par des adresses publiques arbitraires que vous ne contrôlez pas. Cela échange un chevauchement contre un problème de routage et de propriété, pire et plus difficile à expliquer.

Notez le préfixe local, le préfixe distant et le changement qui l’a résolu. Le prochain chevauchement sera différent mais suivra le même schéma.