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.
Réponses:
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:
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:
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:
Ainsi, s’il existe une solution, un certain nombre de problèmes doivent être résolus pour que cela fonctionne dans la pratique:
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:
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.
la source
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:
Ensuite, supprimez cette route statique avec la commande route delete.
la source
dev tun0ce dont vous avez besoin-interface tun0oui 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.
la source
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:
ifconfigdé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.74tapez:
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.
la source
192.168.1.79vient cet échange?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.
la source
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.
la source
La réponse de Aydin K. est pour linux. Si vous voulez la même fonctionnalité pour Windows, vous pouvez taper
ou
vous pouvez obtenir l'ID d'interface avec la commande:
la source
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 ...
la source