Je souhaite connecter plusieurs réseaux locaux situés sur des bâtiments éloignés.
Le site "central" possède un ordinateur Linux exécutant OpenVPN. Chaque site distant exécute également OpenVPN.
- le site central a un LAN numéroté 192.168.0.0/24
- plusieurs sites distants sont également numérotés 192.168.0.0/24
- Je ne peux pas / ne veux pas / ne souhaite pas modifier la numérotation LAN
- Je n'ai aucun contrôle sur la plupart des OpenVPN distants
Je dois ensuite:
1. définir des LAN virtuels
2. configurer un NAT 1: 1 pour chaque site
3. le NAT 1: 1 doit être configuré sur le routeur central
.
Ainsi, chaque site est considéré comme ayant un LAN 10.10.x.0 / 24.
Quand un ordinateur veut atteindre, disons, 192.168.0.44 sur le site 12, il suffit d'envoyer un paquet au 10.10.12.44
L'exploitation d'un VPN n'est pas un problème pour moi. Je connecte actuellement plus de 60 sites. Mais je ne trouve pas un moyen simple de faire ce NAT 1: 1.
Voici un exemple d'un paquet envoyé depuis le site central vers un site distant et son paquet de réponse:
J'ai fait quelques tests avec iptables NETMAP mais je n'arrive pas à le faire fonctionner car je ne trouve pas un moyen de modifier la source + destination après la décision de routage.
Je préfère éviter la nouvelle fonctionnalité d' --client-nat
OpenVPN.
Peut-être que je dois forcer le routage avec ip route
? Ou pour boucler deux fois dans la pile réseau avec veth
?
Remarque: je ne veux pas utiliser la mascarade. Seulement 1/1 NAT.
EDIT:
Ce n'est pas possible avec une configuration openVPN régulière. Parce qu'un paquet provenant d'un site distant ne se distingue pas d'un paquet provenant d'un autre site: les deux ont des adresses source et de destination similaires, et tous deux proviennent de la même interface tun (ou tap). Il n'est donc pas possible de le NAT source.
Solution 1: faites le NAT sur les sites distants. Pas possible dans mon cas. Je dois le faire uniquement sur le site central.
Solution 2: configurez un VPN pour chaque site distant. Je vais donc avoir un tun pour chacun. Je pense que cela peut être ok. Pas très efficace en mémoire mais ok.
Solution 3: configurez un tunnel (non chiffré) à l'intérieur du VPN pour chaque site. Cela donnera une interface pour chacun. Les tunnels simples ne sont pas multi-plateformes (à mon sens). Par exemple, GRE ou ipip ou sit sont ok pour Linux, mais certains sites distants exécutent un seul ordinateur Windows, donc openVPN y est installé. Il est donc impossible de configurer un tunnel simple. Une autre option consiste à utiliser un tunnel plus compliqué (qui?), Mais la surcharge sur le système et sur l'administrateur système peut être plus importante que d'avoir plusieurs VPN
Solution 4: compilez le dernier openVPN, car il inclut une fonction NAT 1: 1. Je teste cette semaine.
Réponses:
Une solution très basique est la suivante:
1. utiliser OpenVPN 2.3 ou plus (actuellement, la dernière est la version 2.3-alpha) pour le serveur + les clients
2. utiliser l'option de configuration OpenVPN ci-dessous
3. ne rien utiliser d'autre (pas de filtre ip, pas de trucs)
Côté serveur, vous devez distribuer manuellement les adresses VPN (donc pas d'
server
option, vous devez utiliserifconfig
ouifconfig-push
):Les lignes
route
etpush route
etclient-nat
sont nécessaires si vous souhaitez communiquer directement entre les routeurs (àping 10.99.99.1
partir d'un site distant via le VPN). Sinon, vous pouvez les jeter..
.
Vous devez maintenant choisir une adresse de réseau virtuel. J'ai gardé le même que vous avez utilisé dans votre exemple: 10.10.0.0/16
Vous autorisez le routage pour cela:
.
.
Vous devez maintenant demander au client d'utiliser le NAT 1: 1:
La première ligne définit l'adresse du routeur distant. Méfiez-vous des pilotes Windows nécessitant des adresses spéciales.
Les deuxième et dernière lignes permettent au routeur distant de communiquer à partir de son interface 10.99.99.x.
Les troisième et quatrième lignes font la source et la destination 1: 1 NAT
La cinquième ligne indique à OpenVPN quoi faire avec les paquets correspondants.
Cette méthode permet de connecter des sites avec des adresses LAN identiques (ou non), sans hôte masqué.
la source
J'ai fait quelque chose de similaire avec de vraies interfaces, mais je ne vois pas pourquoi cela ne fonctionnerait pas avec les interfaces VPN.
L'idée est que, comme vous avez le même sous-réseau disponible à différentes interfaces sur ce routeur, cela complique le routage. Fondamentalement, lorsqu'un paquet pour 10.10.13.123 entre dans le routeur, il est DNATé avant le routage vers 192.168.0.123, vous devez donc être en mesure de dire au routage qu'il était destiné au 192.168.0.123 sur l'interface VPN13 .
Cela peut être fait en utilisant des marques de pare-feu et des règles de routage qui utilisent ces marques. SNAT et DNAT doivent être effectués avec la cible de pare-feu NETMAP. Pour SNAT, c'est le même problème, en POSTROUTING, vous avez perdu l'information que le paquet provenait de telle ou telle interface et ils ont tous l'adresse source 192.168.0.x. Vous avez donc également besoin d'une marque pour transporter ces informations de mangle-PREROUTING à nat-POSTROUTING. Vous pouvez utiliser la même marque, mais cela signifierait que ces paquets utiliseraient cette table de routage alternative, vous devez donc dupliquer la table de routage globale sur tous.
Pour chaque réseau, vous feriez:
Ci-dessus, nous utilisons les 4 premiers bits de la marque , pour permettre à 7 réseaux d'être routés de cette façon.
la source