Il est possible de résoudre ce problème en utilisant la NAT, mais ce n'est pas très élégant.
En partant du principe qu'il n'est pas possible de résoudre ce problème en ayant des réseaux internes dont les numéros sont si peu communs qu'ils n'entrent jamais en conflit, voici le principe :
Comme le sous-réseau local et le sous-réseau distant ont des numéros de réseau identiques, le trafic de votre client ne se rendra jamais compte qu'il doit passer par la passerelle du tunnel pour atteindre sa destination. Et même si nous imaginons que c'est le cas, la situation serait la même pour l'hôte distant qui s'apprête à envoyer une réponse.
Restez donc avec moi et faites comme si, pour l'instant, il n'y avait pas de problèmes secondaires, alors que j'écris que pour une connectivité complète, vous devrez faire du NAT aux deux extrémités du tunnel afin de différencier les hôtes et de permettre le routage.
Nous fabriquons des filets ici :
- Le réseau de votre 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 réseau NAT 198.51.100.0/24.
- La passerelle VPN de votre réseau de bureaux distants cache les hôtes 192.0.2.0/24 derrière le numéro de réseau NAT 203.0.113.0/24
Ainsi, à l'intérieur du tunnel VPN, les hôtes du bureau sont maintenant 198.51.100.x et les hôtes du bureau distant sont 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. Voici un exemple :
- L'hôte 192.0.2.5/24 du réseau de votre bureau est statiquement mappé en tant que 198.51.100.5/24 dans la passerelle NAT vpn du bureau.
- L'hôte 192.0.2.5/24 du réseau de votre bureau distant est statiquement mappé en tant que 203.0.113.5/24 dans la passerelle NAT du bureau distant.
Ainsi, lorsque l'hôte 192.0.2.5/24 du bureau distant veut se connecter à l'hôte ayant 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. Il se passe alors ce qui suit :
- Au bureau distant, l'hôte 198.51.100.5 est une destination distante accessible via le VPN et acheminée à cet endroit.
- Au bureau distant, l'hôte 192.0.2.5 se fait passer pour 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 dans le sens inverse.
Il existe donc une solution, mais un certain nombre de questions doivent être abordées pour qu'elle puisse fonctionner dans la pratique :
- L'IP masquée doit être utilisée pour la connectivité à distance ; le DNS devient complexe. En effet, les points d'extrémité doivent avoir une adresse IP unique, vue de l'hôte qui se connecte.
- Une fonction NAT doit être mise en œuvre aux deux extrémités dans le cadre de la solution VPN.
- Le mappage statique des hôtes est indispensable pour que l'on puisse les joindre depuis l'autre extrémité.
- Si le trafic est unidirectionnel, seule la partie réceptrice a besoin d'un mappage statique de tous les hôtes concernés ; le client peut s'en tirer avec un NAT dynamique s'il le souhaite.
- Si le trafic est bidirectionnel, les deux extrémités ont besoin d'un mappage statique de tous les hôtes concernés.
- La connectivité Internet ne doit pas être entravée, qu'il s'agisse d'un réseau privé virtuel divisé ou non divisé.
- Si vous ne pouvez pas établir de correspondance 1 à 1, c'est le désordre qui s'installe ; une comptabilité rigoureuse est nécessaire.
- Naturellement, on court le risque d'utiliser des adresses NAT qui s'avèrent être des doublons :-)
La résolution de ce problème nécessite donc une conception minutieuse. Si votre bureau à distance se compose en réalité de "guerriers de la route", vous ajoutez une couche de problèmes :
- ils ne savent jamais à l'avance s'ils se retrouvent sur des identifiants de réseau qui se chevauchent.
- la passerelle du bureau distant NAT devrait être implémentée sur leurs ordinateurs portables.
- la passerelle du bureau aurait besoin de deux VPN, l'un sans NAT et l'autre avec NAT, pour couvrir les deux scénarios. Dans le cas contraire, dans le cas où quelqu'un choisirait l'un des sous-réseaux que vous avez sélectionnés pour la méthode NAT, les choses ne fonctionneraient pas .
Selon votre client VPN, vous pouvez être en mesure de sélectionner automatiquement un VPN ou l'autre en fonction de l'adresse réseau du segment local.
Il convient de noter que toute mention de NAT dans ce contexte désigne une fonction NAT qui se déroule pour ainsi dire dans la perspective du tunnel. Du point de vue du processus, le mappage NAT statique 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 l'emmener à travers l'internet jusqu'à l'autre passerelle VPN.
Cela signifie qu'il ne faut pas confondre les adresses IP publiques des passerelles VPN (qui, dans la pratique, peuvent également être NAT:ed, mais en dehors de la perspective du transport vers le site distant via le VPN) avec les adresses privées uniques utilisées comme masques pour les adresses privées dupliquées. Si cette abstraction est difficile à imaginer, une illustration de la façon dont le NAT peut être physiquement séparé de la passerelle VPN à cette fin est donnée ici :
Utilisation de la NAT dans des 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 les fonctions de NAT et de passerelle VPN, c'est simplement pousser le même exemple un peu plus loin, mais cela met davantage l'accent sur les capacités du logiciel en question. Le piratage avec, par exemple, OpenVPN et iptables et l'affichage de la solution ici serait un défi digne d'intérêt.
Du point de vue logiciel, c'est certainement possible :
PIX/ASA 7.x et versions ultérieures : Exemple de configuration d'un VPN IPsec LAN-to-LAN avec des réseaux qui se chevauchent
et :
Configuration d'un tunnel IPSec entre des routeurs dont les sous-réseaux LAN sont dupliqués
La mise en œuvre effective dépend donc de nombreux facteurs, notamment des systèmes d'exploitation concernés, des logiciels associés et de leurs possibilités. Mais c'est certainement faisable. Il faut réfléchir et expérimenter un peu.
J'ai appris cela de Cisco, comme le montrent les liens.
