Connexion à un serveur distant via un VPN lorsque l'adresse de sous-réseau du réseau local entre en conflit avec un réseau distant
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 celui sur la liaison VPN à partir de celui-ci.
Après s'être connecté à un emplacement distant via OpenVPN, les clients tentent d'accéder à un serveur sur un réseau qui existe sur un sous-réseau tel que 192.0.2.0/24. Cependant, parfois, le réseau sur le LAN du client a la même adresse de sous-réseau: 192.0.2.0/24. Les clients ne peuvent pas se connecter au serveur distant via la saisie de son adresse IP en raison de ce conflit. Ils ne peuvent même pas accéder à Internet public lorsqu'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 il doit également être routé en tant que LAN du client.
Quelqu'un sait-il comment atténuer ce problème? J'ai accès au serveur OpenVPN.
Il est possible de résoudre ce problème en utilisant NAT; ce n'est tout simplement pas très élégant.
Donc, sous l'hypothèse que vous ne pourriez pas résoudre ce problème en ayant des réseaux internes qui ont des numéros de réseau si rares qu'ils ne sont jamais réellement en conflit, voici le principe:
Comme le sous-réseau 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 du tunnel pour atteindre sa destination. Et même si nous l'imaginons, la situation serait la même pour l'hôte distant car il est sur le point d'envoyer une réponse.
Alors restez avec moi et prétendez que pour l'instant, il n'y a pas de problèmes secondaires car j'écris que pour une connectivité complète, vous devrez NAT les deux extrémités à l'intérieur du tunnel afin de différencier les hôtes et 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 les hôtes 192.0.2.0/24 derrière le numéro de réseau NAT 198.51.100.0/24
- Votre passerelle VPN de réseau de bureau distant cache 192.0.2.0/24 hôtes derrière le numéro de réseau NAT 203.0.113.0/24
Ainsi, à l'intérieur du tunnel VPN, les hôtes de bureau sont désormais 198.51.100.x et les hôtes de bureau distant sont 203.0.113.x. Imaginons en outre que tous les hôtes sont mappés 1: 1 dans le NAT de leurs passerelles VPN respectives. Un exemple:
- Votre hôte de réseau de bureau 192.0.2.5/24 est mappé statiquement en tant que 198.51.100.5/24 dans la passerelle VPN de bureau NAT
- Votre hôte de réseau de bureau distant 192.0.2.5/24 est mappé statiquement en tant que 203.0.113.5/24 dans la passerelle VPN de bureau distant NAT
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 dans le réseau du bureau, il doit le faire en utilisant l'adresse 198.51.100.5/24 comme destination. Les événements suivants se produisent:
- Au bureau distant, l'hôte 198.51.100.5 est une destination distante atteinte via le VPN et routée à cet endroit.
- Au bureau distant, l'hôte 192.0.2.5 est masqué comme 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 passe par le même processus dans le sens inverse.
Ainsi, bien qu'il existe une solution, il existe un certain nombre de problèmes qui doivent être résolus pour que cela fonctionne dans la pratique:
- L'IP masquée doit être utilisée pour la connectivité à distance; Le DNS devient complexe. En effet, les points de terminaison doivent avoir une adresse IP unique, telle que vue depuis l'hôte qui se connecte.
- 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 indispensable pour être accessible à l'autre extrémité.
- Si le trafic est unidirectionnel, seule l'extrémité réceptrice a besoin d'un mappage statique de tous les hôtes impliqués; le client peut s'en tirer avec un NAT dynamique si cela est souhaitable.
- Si le trafic est bidirectionnel, les deux extrémités nécessitent un mappage statique de tous les hôtes impliqués.
- La connectivité Internet ne doit pas être altérée, quel que soit le VPN partagé ou non.
- Si vous ne pouvez pas mapper 1 à 1, cela devient désordonné; une comptabilité rigoureuse est une nécessité.
- Naturellement, on court le risque d'utiliser NAT adresses qui se révèlent également être des doublons :-)
La résolution de ce problème nécessite donc une conception soignée. Si votre bureau distant se compose vraiment de road warriors, vous ajoutez une couche de problèmes en ce que:
- ils ne savent jamais à l'avance quand ils se retrouvent sur des identifiants de réseau qui se chevauchent.
- la passerelle de bureau distant NAT devrait être implémentée sur leurs ordinateurs portables.
- la passerelle de bureau aurait besoin de deux VPN, un sans NAT et un NAT, pour couvrir les deux scénarios. Sinon, dans le cas où quelqu'un choisirait l'un des sous-réseaux que vous avez choisis pour la méthode NAT, les choses ne fonctionneraient pas .
En fonction de votre client VPN, vous pourrez peut-être sélectionner automatiquement un VPN ou l'autre 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 pour ainsi dire se déroule dans la perspective du tunnel. Processwise, la statique NAT doit être effectué avant que le paquet "n'entre" dans le tunnel, c'est-à-dire avant qu'il ne soit encapsulé dans le paquet de transport qui doit le transporter sur Internet vers l'autre passerelle VPN.
Cela signifie qu'il ne faut pas confondre les adresses IP publiques des passerelles VPN (et qui en pratique peuvent également être NAT: ed, mais alors totalement en dehors de la perspective du transport vers le site distant via VPN) avec les adresses privées uniques utilisées comme mascarades pour les adresses privées en double. Si cette abstraction est difficile à imaginer, une illustration de la façon dont NAT peut être physiquement séparée de la passerelle VPN à cet effet est faite ici:
en utilisant NAT dans les réseaux qui se chevauchent .
Condenser la même image à une séparation logique à l'intérieur d'une machine, capable d'exécuter à la fois la fonctionnalité NAT et la passerelle VPN, prend simplement le même exemple un peu plus loin, mais met davantage l'accent sur les capacités du logiciel à portée de main. Le pirater avec, par exemple, OpenVPN et iptables et publier la solution ici serait un défi de taille.
Sur le plan logiciel, il est certainement possible:
PIX/ASA 7.x et versions ultérieures: VPN IPsec LAN à LAN avec exemple de configuration de réseaux superposés
et:
Configuration d'un tunnel IPSec entre des routeurs avec des sous-réseaux LAN en double
La mise en œuvre effective 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 le montrent les liens.
Si vous avez besoin d'une solution de contournement temporaire temporaire vers un ou plusieurs serveurs IPS connus, la solution la plus simple devrait être l'option de routage côté client statique.
Dans mon cas, j'ai ajouté le serveur de destination souhaité (192.168.1.100) à ma table de routage sur mon client Linux via:
route add 192.168.1.100 dev tun0
Ensuite, supprimez cette route statique avec la commande route delete.
ouais c'est le pire. pour moi, cela arrivait tout le temps depuis les chambres d'hôtel, avant que les administrateurs VPN ne se rendent compte qu'ils devraient utiliser des plages IP plus obscures. 10.0.0.0/24 et 10.1.1.1/24 sont les pires. si vous pouvez l'aider, ne jamais ip un réseau sans fil comme ça.
donc la réponse est "corriger" le wap pour utiliser un autre réseau interne (ie 10.255.255.0/24) et ensuite vous donner un bail différent (ie ip dans une plage qui peut rediriger vers corp vpn), ou si vous n'avez pas/cant get admin on wap, go to starbucks. ou 20 minutes de wardriving :)
si ce n'est que dans un laboratoire, utilisez simplement différentes plages.
Je suis sur un Mac exécutant El Capitan. Bien que les suggestions ci-dessus n'aient pas fonctionné pour moi, elles m'ont conduit à une solution de travail:
- avant de démarrer VPN, exécutez
ifconfig démarrez le VPN, faites
ifconfiget notez quelle est la nouvelle interface. Dans mon cas, c'était ppp avec une adresse IP de 192.168.42.74ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00tapez:
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.
Quand j'ai essayé d'utiliser dev ppp pour la fin de la commande route comme mentionné ci-dessus, il s'est plaint.
La réponse d'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'identifiant d'interface avec la commande:
route print
J'ai une solution simple que j'utilise dans un espace de co-working qui a une plage IP conflictuelle (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.
Si vous avez juste besoin de frapper quelques adresses IP, ajoutez une instruction route à votre fichier de configuration ovpn comme ceci:
ligne 192.168.1.10 255.255.255.255
ligne 192.168.1.11 255.255.255.255
Il ajoutera un itinéraire pour ces Ip uniquement lorsque vous connectez votre vpn et le supprimera lorsque le vpn sera déconnecté.
J'ai quand même travaillé pour Windows.
Pour rappel: tout ce problème est dû à des années de pénurie d'adresses IPv4 et à une utilisation intensive de plage IP privée derrière NAT pour contourner cette pénurie!
La solution idéale et définitive à ce problème est assez simple (bien que cela puisse prendre et prendra du temps pour être déployé à l'échelle mondiale): IPv6 ...
Dans un monde IPv6, il n'y a pas de pénurie IP publique (et il n'y en aura pas dans quelques décennies). Il n'y a donc aucune raison de ne pas avoir d'adresse IP publique sur chaque appareil de chaque réseau. Et si vous avez besoin d'une isolation réseau, continuez à filtrer avec un pare-feu, mais sans laid NAT ...