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.