Bonjour à tous,
cela fait maintenant un bon moment que je suis à la recherche d'une solution pour contourner un problème d'entrelacement de réseaux (overlapping).
Présentation
Un schéma vaut mieux qu'un long discours :
- Server est un serveur OpenVPN connecté en VPN (vert) à CLIENT 1, CLIENT 2, CLIENT 3.
- CLIENT 1, CLIENT 2, CLIENT 3 sont des équipements Linux (Debian) qui possèdent 2 interfaces: eth0 relié au réseau du client (bleu); tun0 connecté au serveur VPN sur Server (vert).
- IPBX 1, IPBX 2, IPBX 3 sont des équipements chez le client (il peut y en avoir plusieurs mais pour l'exemple je n'en ai mis qu'un).
Objectif
L'objectif est de se connecter avec un client VPN depuis un PC vers Server pour avoir accès à tous les clients en même temps. Donc l'objectif est aussi de pouvoir pinguer les équipements IPBX 1, IPBX 2, IPBX 3 depuis Server.
Problème
Comme on peut le voir sur le schéma certain clients ont le même plan d'adressage voir la même adresse d'IPBX. Ceci pose donc des problèmes de routage pour Server (les réseaux s'entrelacent).
Pistes
J'ai pu lire à plusieurs reprises qu'avec de la NAT il est possible de résoudre ce problème cependant je commence à me mélanger les pinceaux entre iptables et les différentes NAT possibles.
Dans l'idéal il faudrait translater tout le réseau 192.168.0.0/24 du client 1 (par exemple) à partir de l'équipement CLIENT 1 en 10.1.0.0/24 (par exemple). On pourrait donc pinguer le 192.168.0.100 depuis Server avec son adressage translaté 10.1.0.100.
PS: il n'est pas possible de changer les adressages réseau.
Merci d'avance ;)
Edit:
Au final j'ai créé une app avec du flask et la lib pyroutes2 : https://github.com/tux-00/routemanager
L'app permet d'activer des routes à la demande et stocke tout dans une base de données Sqlite. Alors certes il n'est pas possible d'avoir deux clients aillant le même sous réseau en même temps mais il est facilement possible de switcher entre les clients en activant/désactivant les routes.
J'ai codé ça assez vite mais je me suis dit que ça pouvait servir à certains donc j'ai posé ça sur Github.
# Réseau mesh
Posté par GG (site web personnel) . Évalué à 2.
Bonjour,
il me semble que le protocol Babel (et d'autres du même principe) peut résoudre ton problème.
https://fr.wikipedia.org/wiki/Babel_%28protocole%29
https://www.irif.univ-paris-diderot.fr/~jch//software/babel/
Il existe aussi BATMAN, similaire.
https://fr.wikipedia.org/wiki/BATMAN_%28protocole%29
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Réseau mesh
Posté par tofu . Évalué à 1.
Intéressant, je ne connaissais pas, par contre je ne pense pas que ce soit très adapté à mon cas. De ce que j'ai lu c'est plus pour les clients qui se connectent et déconnectent régulièrement comme des clients wifi ou des téléphones mobiles.
[^] # Re: Réseau mesh
Posté par GG (site web personnel) . Évalué à 2.
Bonjour,
Si tes différentes machines ne se déconnectent pas, cela fonctionnera aussi bien.
Babel ne fait qu'ajouter des routes (grosso modo), et c'est parfaitement adapté à ta situation, simple à mettre en place, extensible etc.
Tu peux essayer Babel, voir si ça marche, voir ce qu'à fait babel, et virer Babel ensuite et ajouter les mêmes règles manuellement.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Réseau mesh
Posté par tofu . Évalué à 1.
Ok je vais essayer de creuser un peu plus. Si j'ai bien compris il n'y a rien à installer coté IPBX dans mon cas ?
# NAT
Posté par ptit_poulet . Évalué à 2.
Bonjour,
Effectivement le NAT sera le plus adapté dans ton cas.
Donc par rapport à ton schéma, si tu veux accéder à un site web hébergé sur IPBX1 par exemple, tu devras y accéder via l'adresse 10.64.0.11:80 à condition que le client soit aussi dans le réseau 10.64.0.0/24 lui même.
Par contre concernant la partie VPN, regarde bien dans ta configuration que les différents clients connectés sur ton serveur VPN ne sont pas isolés les uns des autres sinon forcément ça ne marchera pas ;)
[^] # Re: NAT
Posté par tofu . Évalué à 1.
Pour la partie VPN effectivement les clients ne sont pas isolés! Par contre j'ai pu lire qu'il était possible de translater une plage d'adresse entière. Par exemple 192.168.100.0/24 -> 10.64.100.0/24. J'avais réussi à faire un bout de configuration iptables qui fonctionnait. Les paquets étaient bien envoyés à l'IPBX mais ils n'étaient pas retournées vers l'équipement CLIENTX. Peut etre qu'il manquait un bout de conf sur CLIENTX..
Car je ne pas utiliser la NAT avec des ports due au fait que les équipements IPBXX ne sont pas simple à configurer et des outils spécifiques sont utilisés. Autant dire que l'on ne peut presque pas toucher la configuration des IPBX.
[^] # Re: NAT
Posté par ptit_poulet . Évalué à 1.
Et tu ne peux pas connecté ton IPBX directement au VPN ? C'est quelle version/OS que tu utilises ? Asterisk ?
[^] # Re: NAT
Posté par tofu . Évalué à 1.
Hélas non je ne peux pas c'est du Avaya donc du proprio..
[^] # Re: NAT
Posté par ptit_poulet . Évalué à 1.
OK. Dans ce cas pourquoi ne pas modifier le client qui se connecte au VPN pour qu'il fasse office de pont réseau. Comme ça tout ce qui arrive sur lui part directement sur l'IPBX.
[^] # Re: NAT
Posté par tofu . Évalué à 1. Dernière modification le 21 juillet 2016 à 14:05.
Effectivement ce serrait une idée si il n'y avait qu'un seul équipement. Parfois il peut y avoir plusieurs équipement de nature différente derrière un équipement CLIENTX. Ou peut-etre n'ais-je pas tout compris de ce que tu voulais dire par pont réseau..
[^] # Re: NAT
Posté par ptit_poulet . Évalué à 1.
Une petite explication par ici. Peut-être est-il possible de faire mieux :D
[^] # Re: NAT
Posté par tofu . Évalué à 1.
Je venais de lire ce lien mais effectivement on peut faire mieux :P J'ai fini par comprendre que c'était tout simplement un bridge..
Le schéma plus complet est le suivant:
PS: FW est le firewall du client.
L'équipement CLIENTX n'est donc pas directement connecté à l'IPBX. Ce qui, sauf si je dis une bétise, ne fonctionne pas.
[^] # Re: NAT
Posté par ptit_poulet . Évalué à 1.
Tu veux faire quoi exactement sur tous les IPBX depuis le client connecté sur le VPN ? Car il y a peut être des solutions adaptées pour l'usage que tu veux en faire.
[^] # Re: NAT
Posté par tofu . Évalué à 1.
Je veux avoir une connexion sur les équipements de nos clients. Donc il y a du SSH, du telnet, des protocoles proprios Avaya pour les configurations et du debug, du tftp, du SNMP etc.. Donc c'est pour ça que la redirection par port est trop complexe dans ce cas.
[^] # Re: NAT
Posté par ptit_poulet . Évalué à 1.
Peux-tu refaire un schéma comme celui juste au-dessus mais avec l'ensemble des autres IPBX, car j'ai un peu de mal à voir comment c'est foutu par rapport au 1er schéma ;)
[^] # Re: NAT
Posté par tofu . Évalué à 1.
Donc le but est de se connecter à Server pour avoir accès à tous nos équipements chez le client grâce à l'équipement Linux qui sert de point d'entrée.
On peut imaginer Server dans un VPS chez un hébergeur type DigitalOcean.
Ici je n'ai représenté qu'un seul client pour ne pas compliquer le schéma mais c'est grossièrement la même chose chez les autres clients.
Donc on peut avoir différent type d'équipements.
[^] # Re: NAT
Posté par ptit_poulet . Évalué à 1.
Il faut que tu routes tout le trafic de 10.64.0.10 vers 192.168.0.100.
# SSH ?
Posté par ptit_poulet . Évalué à 1.
Peux-tu établir une connexion SSH d'un IPBX vers un autre équipement ?
[^] # Re: SSH ?
Posté par tofu . Évalué à 1. Dernière modification le 21 juillet 2016 à 15:11.
Non plus ! Ou peut etre pour les versions serveur mais ce n'est pas le cas ici.
# regles de NAT sur les machines CLIENT-X
Posté par NeoX . Évalué à 2.
j'imagine que les machines CLIENT-X sont des machines à toi, que tu met chez le client pour permettre la telemaintenance des equipements.
donc sur l'equipement CLIENT-1, tu met un NAT qui convertit
10.1.0.y en 192.168.0.y (en entrée des flux qui arrivent sur le VPN : DNAT)
et 192.168.0.y en 10.1.0.y (en sortie des flux qui sortent sur le VPN : SNAT)
chez toi, tu regles tes routes pour que 10.1.0.0/24 soit routé vers la machine client-1
10.2.0.0/24 routé vers client-2
etc
[^] # Re: regles de NAT sur les machines CLIENT-X
Posté par tofu . Évalué à 1.
Exactement.
J'avais réussi avec quelques lignes d'iptables sur CLIENT-X à convertir 10.1.0.y en 192.168.0.y, les paquets allaient jusqu'à l'IPBX mais ne revenaient pas.
Je ne sais pas s'il est possible de faire une translation sans toucher à la configuration de l'IPBX ?
[^] # Re: regles de NAT sur les machines CLIENT-X
Posté par NeoX . Évalué à 3.
ca c'est parce que la route par defaut de ton IPBX ne passe pas pas ta machine CLIENT-1
le paquet par donc ailleurs sur le reseau.
trois possibilités :
[^] # Re: regles de NAT sur les machines CLIENT-X
Posté par tofu . Évalué à 1.
J'ai donc testé la solution 1 qui me parait être la plus simple.
Pour les tests j'ai remplacé l'IPBX par un Debian et j'ai donc ces adresses :
- Server {tun0=10.64.0.1}
- CLIENT-1 {tun0=10.64.0.100; eth0=192.168.138.16}
- IPBX {eth0=192.168.138.12}
L'IP 192.168.138.12 (IPBX) est translatée en 10.64.0.200.
J'ai utilisé l'option client-nat d'OpenVPN pour pousser sur CLIENT-X la conf de NAT ci-dessous:
Avec cette configuration quand je lance un ping 10.64.0.200 depuis 10.64.0.1 (Server) :
Server
CLIENT-1 (tcpdump)
IPBX (tcpdump)
Donc en résumé on dirait qu'il manque quelque chose sur CLIENT-1 au niveau de la NAT pour translater 192.168.138.16 en 10.64.0.1 ?
J'ai un peu du mal avec la NAT ^
[^] # Re: regles de NAT sur les machines CLIENT-X
Posté par NeoX . Évalué à 2.
faire un schema pour determiner quelles sont les regles de NAT necessaire
Flux reel :
Serveur (10.64.0.1) <-> (10.64.0.100) ClientX (192.168.138.12) <-> (192.168.138.16) IPBX
Flux avec NAT
Serveur (10.64.0.1) <-> (10.64.0.200) ======= NAT sur CLIENTX <-> (192.168.138.16) IPBX
donc je suis OK avec le DNAT qui change 10.64.0.200 en 192.168.138.16 (pour que le flux aille sur l'IPBX
je suis OK avec le SNAT qui change la source 10.64.0.1 en 192.168.138.12 afin que l'IPBX repondent à CLIENTX plutot que sa passerelle par defaut
par contre je ne comprend pas pourquoi tu veux refaire un DNAT 192.168.138.12 -> 10.64.0.1 et un SNAT 192.168.138.16 -> 10.64.0.200
en effet si le flux est toujours initié depuis le serveur, iptables est assez intelligent pour remonter le fil et faire les NAT retour.
quand au TCPDUMP, il faut preciser si tu le fait sur l'interface tun0 ou eth0 de clientX
note que si tu le fais sur 'any' tu devrais voir les flux arrivant et ressortant des interfaces (et donc les NAT)
dans ton cas, vu que tu fais du ping :
tcpdump -vnni any proto ICMP# Netmap
Posté par nono14 (site web personnel) . Évalué à 2.
Cible NETMAP de iptables ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.