Forum Linux.général Entrelacement de réseaux et VPN

Posté par . Licence CC by-sa
3
20
juil.
2016

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 :

Schema

  • 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 ;)

  • # Réseau mesh

    Posté par (page perso) . É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

    • [^] # Re: Réseau mesh

      Posté par . É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 (page perso) . É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.

        • [^] # Re: Réseau mesh

          Posté par . É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 . É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 . É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 . É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 . Évalué à 1.

          Hélas non je ne peux pas c'est du Avaya donc du proprio..

          • [^] # Re: NAT

            Posté par . É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 . Évalué à 1. Dernière modification le 21/07/16 à 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 . Évalué à 1.

                Une petite explication par ici. Peut-être est-il possible de faire mieux :D

                • [^] # Re: NAT

                  Posté par . É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:

                  Titre de l'image

                  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 . É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 . É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 . É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 . Évalué à 1.

                      Titre de l'image

                      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 . Évalué à 1.

                        Il faut que tu routes tout le trafic de 10.64.0.10 vers 192.168.0.100.

  • # SSH ?

    Posté par . Évalué à 1.

    Peux-tu établir une connexion SSH d'un IPBX vers un autre équipement ?

    • [^] # Re: SSH ?

      Posté par . Évalué à 1. Dernière modification le 21/07/16 à 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 . É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 . Évalué à 1.

      j'imagine que les machines CLIENT-X sont des machines à toi, que tu met chez le client pour permettre la telemaintenance des equipements.

      Exactement.

      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)

      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 . Évalué à 3.

        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 ?

        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 :

        1. faire un SNAT en sortie de CLIENT-X pour masquer l'IP du demandeur (10.64.0.X) derriere l'IP locale de CLIENT-X (l'IPBX repondra alors à clientX, qui deferra le NAT et renverra à 10.64.0.1)
        2. faire une route static dans l'IPBX disant qu'il doit parler à CLIENT-1 pour joindre 10.64.0.1
        3. faire que l'IPBX cause par defaut à CLIENT-X, qui lui parlera avec ton reseau ou celui du client (mais c'est moche)
        • [^] # Re: regles de NAT sur les machines CLIENT-X

          Posté par . É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:

          ifconfig-push 10.64.0.100 255.255.255.0

          iroute 10.64.0.100
          iroute 10.64.0.200

          push "client-nat dnat 10.64.0.200 255.255.255.255 192.168.138.12"
          push "client-nat snat 10.64.0.1 255.255.255.255 192.168.138.16"
          push "client-nat snat 192.168.138.12 255.255.255.255 10.64.0.200"
          push "client-nat dnat 192.168.138.16 255.255.255.255 10.64.0.1"

          Avec cette configuration quand je lance un ping 10.64.0.200 depuis 10.64.0.1 (Server) :

          Server

          root@debian-supervisor:/etc/openvpn# ping 10.64.0.200
          PING 10.64.0.200 (10.64.0.200) 56(84) bytes of data.
          C
          --- 10.64.0.200 ping statistics ---
          4 packets transmitted, 0 received, 100% packet loss, time 3024ms

          CLIENT-1 (tcpdump)

          12:55:50.623757 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 2, length 64
          12:55:50.623904 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 2, length 64
          12:55:51.631236 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 3, length 64
          12:55:51.631406 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 3, length 64
          12:55:52.639972 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 4, length 64
          12:55:52.640122 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 4, length 64

          IPBX (tcpdump)

          12:55:43.350550 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 1, length 64
          12:55:43.350596 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 1, length 64
          12:55:44.359319 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 2, length 64
          12:55:44.359354 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 2, length 64
          12:55:45.366772 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 3, length 64
          12:55:45.366800 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 3, length 64
          12:55:46.375518 IP 192.168.138.16 > 192.168.138.12: ICMP echo request, id 4212, seq 4, length 64
          12:55:46.375549 IP 192.168.138.12 > 192.168.138.16: ICMP echo reply, id 4212, seq 4, length 64

          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 . É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 (page perso) . Évalué à 2.

    Cible NETMAP de iptables ?

    Système - Réseau - Sécurité Open Source

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.