Connexion à un serveur distant via un VPN lorsque l'adresse du sous-réseau du réseau local est en conflit avec un réseau distant


35

Il s'agit d'une question canonique sur la résolution des conflits de sous-réseau IPv4 entre le réseau local d'un client VPN et l'un des liens VPN qui le relie.

Une fois connectés à un emplacement distant via OpenVPN, les clients tentent d'accéder à un serveur d'un réseau existant sur un sous-réseau tel que 192.0.2.0/24. Cependant, le réseau du client a parfois la même adresse de sous-réseau: 192.0.2.0/24. Les clients ne peuvent pas se connecter au serveur distant en tapant son adresse IP à cause de ce conflit. Ils ne peuvent même pas accéder à Internet public tant qu’ils sont connectés au VPN.

Le problème est que ce sous-réseau 192.0.2.0/24 doit être routé par le VPN, mais également en tant que réseau local du client.

Est-ce que quelqu'un sait comment atténuer ce problème? J'ai accès au serveur OpenVPN.


3
Vous pouvez essayer de définir un itinéraire statique pour l'adresse / 32 de l'hôte que vous essayez d'atteindre et utiliser l'homologue VPN comme passerelle pour voir ce qui se passe.
SpacemanSpiff

si le concentrateur VPN respecte les itinéraires des clients, votre sécurité de périmètre peut avoir besoin d'aide. Je reçois un accès à la comptabilité LAN, j'ajoute une route à la gamme d'ingénierie et je peux alors me connecter sans problème. pare-feu de mauvaise qualité comme sonicwall le font
nandoP

@SpacemanSpiff: Bien que cela puisse résoudre le problème côté client, le serveur ne pourra toujours pas répondre car il verrait la connexion comme provenant de son propre réseau, et non d'un client VPN.
Massimo

Réponses:


18

Il est possible de résoudre ce problème en utilisant NAT; ce n'est pas très élégant.

Donc, en supposant que vous ne puissiez pas résoudre ce problème en ayant des réseaux internes qui ont des numéros de réseau si peu communs qu'ils ne risquent jamais d'entrer en conflit, voici le principe:

Comme les sous-réseaux local et distant ont des numéros de réseau identiques, le trafic de votre client ne réalisera jamais qu'il doit passer par la passerelle de tunnel pour atteindre sa destination. Et même si nous l’imaginions, la situation serait la même pour l’hôte distant et sur le point d’envoyer une réponse.

Restez donc avec moi et prétendez que, pour le moment, il n'y a pas de problèmes latéraux au moment où j'écris que pour une connectivité totale, vous auriez besoin de NAT aux deux extrémités du tunnel afin de différencier les hôtes et de permettre le routage.

Faire des filets ici:

  • Votre réseau de bureau utilise 192.0.2.0/24
  • Votre bureau distant utilise 192.0.2.0/24
  • La passerelle VPN de votre réseau de bureau cache 192.0.2.0/24 hôtes derrière le numéro de réseau en NAT 198.51.100.0/24
  • La passerelle VPN de votre réseau de bureau distant cache 192.0.2.0/24 hôtes derrière le numéro de réseau faisant l’objet d’un NAT 203.0.113.0/24.

Ainsi, dans le tunnel VPN, les hôtes de bureau sont désormais 198.51.100.x et les hôtes de bureau distant, 203.0.113.x. Supposons en outre que tous les hôtes sont mappés 1: 1 dans le NAT de leurs passerelles VPN respectives. Un exemple:

  • L’hôte réseau de votre bureau 192.0.2.5/24 est mappé de manière statique à 198.51.100.5/24 dans la passerelle vpn du bureau NAT
  • L'hôte réseau 192.0.2.5/24 de votre bureau distant est mappé de manière statique en tant que 203.0.113.5/24 dans la passerelle vpn du NAT du bureau distant.

Ainsi, lorsque l'hôte 192.0.2.5/24 du bureau distant souhaite se connecter à l'hôte avec la même adresse IP sur le réseau du bureau, il doit le faire en utilisant l'adresse 198.51.100.5/24 comme destination. Ce qui suit se produit:

  • Au bureau distant, l'hôte 198.51.100.5 est une destination distante accessible via le VPN et acheminée vers celui-ci.
  • Au bureau distant, l'hôte 192.0.2.5 est masqué en 203.0.113.5 lorsque le paquet passe la fonction NAT.
  • Au bureau, l'hôte 198.51.100.5 est traduit en 192.0.2.5 lorsque le paquet passe la fonction NAT.
  • Au bureau, le trafic de retour vers l’hôte 203.0.113.5 suit le même processus en sens inverse.

Ainsi, s’il existe une solution, un certain nombre de problèmes doivent être résolus pour que cela fonctionne dans la pratique:

  • L’adresse IP masquée doit être utilisée pour la connectivité à distance; Le DNS devient complexe. En effet, les ordinateurs d'extrémité doivent avoir une adresse IP unique, telle que vue depuis l'hôte se connectant.
  • Une fonction NAT doit être implémentée aux deux extrémités dans le cadre de la solution VPN.
  • Le mappage statique des hôtes est un impératif pour l’atteignabilité de l’autre extrémité.
  • Si le trafic est unidirectionnel, seule l'extrémité destinataire a besoin du mappage statique de tous les hôtes impliqués. le client peut s’en sortir en faisant un NAT dynamique si cela est souhaitable.
  • Si le trafic est bidirectionnel, les deux extrémités ont besoin d'un mappage statique de tous les hôtes impliqués.
  • La connectivité Internet ne doit pas être altérée, qu’il s’agisse d’un VPN fractionné ou non.
  • Si vous ne pouvez pas mapper 1 à 1, cela devient compliqué; Une comptabilité soignée est une nécessité.
  • Naturellement, on court le risque d'utiliser des adresses NAT qui se révèlent être également des doublons :-)

Donc, résoudre ce problème nécessite une conception minutieuse. Si votre bureau distant est réellement constitué de guerriers de la route, vous ajoutez une couche de problèmes en ce sens:

  • ils ne savent jamais à l'avance quand ils se retrouvent avec des identifiants de réseau qui se chevauchent.
  • la passerelle NAT du bureau distant devrait être mise en œuvre sur leurs ordinateurs portables.
  • la passerelle de bureau aurait besoin de deux VPN, un sans NAT et l'autre avec NAT, pour couvrir les deux scénarios. Sinon, si quelqu'un choisissait l'un des sous-réseaux choisis pour la méthode NAT, les choses ne fonctionneraient pas .

En fonction de votre client VPN, vous pourrez peut-être sélectionner automatiquement l'un des VPN en fonction de l'adresse réseau du segment local.

Notez que toute mention de NAT dans ce contexte dénote une fonction NAT qui se déroule pour ainsi dire dans la perspective du tunnel. Sur le plan des processus, le mappage NAT statique doit être effectué avant que le paquet "entre" dans le tunnel, c'est-à-dire avant qu'il ne soit encapsulé dans le paquet de transport qui doit le transférer sur Internet vers l'autre passerelle VPN.

Cela signifie qu'il ne faut pas confondre les adresses IP publiques des passerelles VPN (et qui peuvent en pratique être également NAT: ed, mais alors complètement en dehors de la perspective du transport vers le site distant via VPN) avec les adresses privées uniques utilisées comme masques. pour les adresses privées en double. Si cette abstraction est difficile à visualiser, voici une illustration de la façon dont le NAT peut être physiquement séparé de la passerelle VPN à cette fin:
Utilisation de NAT dans des réseaux en chevauchement .

Condenser la même image en une séparation logique au sein d'une même machine, capable d'exécuter à la fois la fonctionnalité de passerelle NAT et de passerelle VPN, va tout simplement dans le même exemple un peu plus loin, mais met davantage l'accent sur les capacités du logiciel actuel. Le piratage avec, par exemple, OpenVPN et iptables et la publication de la solution ici constitueraient un défi de taille.

Au niveau logiciel, c’est certainement possible:
PIX / ASA 7.x et versions ultérieures: Exemple de configuration d’un réseau VPN IPsec avec réseaux superposés de réseau à réseau
et:
Configuration d’un tunnel IPSec entre routeurs avec sous-réseaux LAN en double

La mise en œuvre dépend donc de nombreux facteurs, des systèmes d’exploitation impliqués, des logiciels associés et de ses possibilités. Mais c'est certainement faisable. Vous auriez besoin de réfléchir et d'expérimenter un peu.

J'ai appris cela de Cisco, comme l'indiquent les liens.


Le NAT pourrait-il également fonctionner avec de nombreuses connexions VPN et leurs traductions? Je n'ai pas complètement compris le cas ici. J'ai un fil ici unix.stackexchange.com/q/284696/16920 sur comment faire un VPN de site à site avec des sous-réseaux se chevauchant Unix-Way?
Léo Léopold Hertz

17

Si vous avez besoin d'une solution temporaire temporaire de nettoyage d'un ou de plusieurs ips de serveur connus, la solution la plus simple devrait être l'option de routage statique côté client.

Dans mon cas, j'ai ajouté le serveur de destination souhaité (192.168.1.100) à la table de routage de mon client Linux via:

route add 192.168.1.100 dev tun0

Ensuite, supprimez cette route statique avec la commande route delete.


2
C'est une solution parfaite et un timing parfait! :)
Yuval Un

Combien de temps cela persiste-t-il? Jusqu'à ce que vous vous déconnectiez? Jusqu'au redémarrage?
carbocation le

1
Sur mon système Linux (xfce avec Ubuntu / Mint), les paramètres sont "perdus" après une déconnexion de vpn et, oui, après un redémarrage. Vous pouvez vérifier si le paramètre est actif avec la commande route (il y aura une entrée ayant généralement l'adresse IP et le périphérique tun0 en bas)
Aydin K.

La version de route de OSX prend l’interface différemment, donc au lieu de dev tun0ce dont vous avez besoin-interface tun0
Sirens

5

oui c'est le pire. pour moi, cela se passait tout le temps depuis les chambres d'hôtel, avant que les administrateurs VPN ne se rendent compte qu'ils devraient utiliser des plages d'adresses IP plus obscures. 10.0.0.0/24 et 10.1.1.1/24 sont les pires. si vous pouvez l’aider, n’utilisez jamais un réseau sans fil comme celui-ci.

la solution est donc de "réparer" le wap pour utiliser un réseau interne différent (c'est-à-dire 10.255.255.0/24), puis vous donner un bail diff (c'est-à-dire une adresse IP pouvant être redirigé vers corp vpn) Je ne peux pas obtenir admin sur wap, allez juste à starbucks. ou 20 minutes de garde :)

s'il s'agit simplement d'un laboratoire, utilisez simplement des plages différentes.


Dang vraiment? Il n'y a pas de meilleure option?
John Russell

1
pas que je sache .... cela a toujours été un problème ... on dirait que ma réponse a été votée à la baisse, mais je n'ai en fait pas suggéré de solution .... ah, tuez le messager!
NandoP

3

Je suis sur un mac sous El Capitan. Bien que les suggestions ci-dessus n'aient pas fonctionné pour moi, elles m'ont conduit à une solution de travail:

  1. avant de commencer le VPN, exécutez ifconfig
  2. démarrez le VPN, ifconfignotez et notez quelle est la nouvelle interface. Dans mon cas, c’était ppp0 avec une adresse IP de 192.168.42.74

    ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
    
  3. tapez:

    sudo route add 192.168.1.79  192.168.42.74
    

J'ai d'abord testé avec un ping, puis j'ai prouvé que cela fonctionnait en accédant au serveur git.

Lorsque j'ai essayé d'utiliser dev ppp0 pour la fin de la commande route, comme mentionné ci-dessus, il s'est plaint.


2
D'où 192.168.1.79vient cet échange?
carbocation le

Le serveur de destination auquel vous vous connectez. Ce serveur réside sur le même réseau que votre VPN, pas votre connexion locale.
Carlo del Mundo

1

J'ai une solution simple que j'utilise dans un espace de travail collaboratif ayant une plage d'adresses IP en conflit (10.x)

Je me suis connecté au réseau avec mon téléphone portable, puis j'ai partagé la connexion réseau via Bluetooth avec mon ordinateur portable. Je peux maintenant utiliser le VPN pour mon employeur distant.

Je suis sûr que cela fonctionnera de la même manière via USB si vous avez besoin d’une connexion plus rapide.


1
Hé, c'est en fait une solution assez intelligente.
Nathan Osman

1

Si vous avez juste besoin de frapper quelques adresses IP, ajoutez une instruction route à votre fichier de configuration ovpn comme ceci:

route 192.168.1.10 255.255.255.255

route 192.168.1.11 255.255.255.255

Il ajoutera une route pour ces IP uniquement lorsque vous connecterez votre vpn et le retirerez lorsque le vpn sera déconnecté.

J'ai quand même travaillé pour Windows.


1

La réponse de Aydin K. est pour linux. Si vous voulez la même fonctionnalité pour Windows, vous pouvez taper

route ADD 192.168.1.10 <IP of tunnel adapter>

ou

route ADD 192.168.1.10 IF <interface id>

vous pouvez obtenir l'ID d'interface avec la commande:

route print

0

Pour rappel, toute cette question est due aux années de pénurie d'adresses IPv4 et à l'utilisation intensive de la plage IP privée derrière NAT pour pallier cette pénurie!

La solution idéale et définitive à ce problème est assez simple (bien qu’elle puisse prendre et mettra un certain temps à se déployer à l’échelle mondiale): IPv6 ...

Dans un monde IPv6, il n’ya pas de pénurie d’IP publique (et il n’y en aura pas d’événement dans quelques décennies). Il n’ya donc aucune raison de ne pas avoir d’adresse IP publique sur chaque appareil de chaque réseau. Et si vous avez besoin d'isolement du réseau, continuez à filtrer avec un pare-feu, mais sans NAT laid ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.