Forum Linux.général iptables et réseaux non routables

Posté par  .
Étiquettes :
1
4
déc.
2009
Bonjour à tous,

Je m'arrache les cheveux depuis la fin de l'après midi. Alors je demande ici :)

Je suis sur un réseau en 10.1.1.0/24
Je veux atteindre un réseau distant en 192.168.1.0/24
Sur le réseau distant j'ai un routeur (une Debian Lenny) que je contrôle. Ce routeur a une adresse 192.168.1.1 pour s'adapter au réseau du coin. Ce routeur fait partie d'un VPN auquel je peux accéder sans problème (son adresse sur le VPN est 192.168.38.1).


[10.1.1.0/24] ---> [VPN] ---> [192.168.38.1 + 192.168.1.1] ---> [192.168.1.0/24]


Je veux accéder à certains services présents sur le réseau distant (vnc, partages SMB, serveurs d'impression). Le réseau distant n'a pas besoin de joindre mon réseau (sauf pour répondre à mes connexions).

Je ne peux pas reparamétrer les machines du réseau distant. Donc pas de routage possible sur le chemin du retour des paquets. Alors j'imagine qu'il faut que les paquets qui viennent de mon réseau soient transformés via une règle SNAT pour qu'ils apparaissent comme provenant de 192.168.1.1 Ca c'est facile:
iptables -t nat -A POSTROUTING --destination 192.168.38.0/24 -j SNAT --to-source 192.168.1.1


Mais il faut également que je fasse comprendre à ce routeur que ce qui est destiné à 192.168.38.0/24 doit être transformé en 192.168.1.0/24
Pour cela je pensais utiliser la cible NETMAP. Mais cette cible ne transforme que l'adresse source, pas l'adresse cible. Ou alors j'ai mal compris.

J'ai tout de même testé ça:
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j NETMAP --to 192.168.1.0/24
Et ça:
iptables -t nat -A PREROUTING -s 10.1.1.0/24 -j NETMAP --to 192.168.1.0/24
Mais non.

Une idée ?
  • # Règle PREROUTING avec filtre sur l'interface d'entrée

    Posté par  . Évalué à 0.

    ce qui est destiné à 192.168.38.0/24 doit être transformé en 192.168.1.0/24

    Concrètement, ce qui est destiné à 192.168.38.0/24, c'est tout ce qui arrive par l'interface réseau virtuelle du VPN. Il faut donc l'intercepter avec l'option -i, au niveau de la chaîne PREROUTING :

    iptables -t nat -A PREROUTING -i $IF_VPN ...

    $IF_VPN est le nom de l'interface du VPN (ifconfig pour l'obtenir).

    Ensuite, il suffit de modifier la destination de ces paquets, en spécifiant une plage d'adresses de destination :

    ... -j DNAT --to 192.168.1.0-192.168.1.254

    iptables fera ainsi la correspondance 192.168.38.XX -> 192.168.0.XX

    Ce qui nous donne :

    iptables -t nat -A PREROUTING -i $IF_VPN -j DNAT --to 192.168.1.0-192.168.1.254
    • [^] # Re: Règle PREROUTING avec filtre sur l'interface d'entrée

      Posté par  . Évalué à 3.

      La cible DNAT ne fait pas de remplacement 1 vers 1. Ca fait du remplacement plus ou moins aléatoire. C'est fait pour de l'équilibrage de charge.

      De plus avec ton exemple, il ne serait plus possible d'utiliser le VPN car 192.168.38.1 serait redirigé vers une adresse aléatoire. Il faut probablement placer la règle en POSTROUTING. Non testé.

      Clairement il manque l'équivalent de NETMAP en sortie pour son problème. Il existe probablement une astuce mais là je ne vois pas.
      • [^] # Re: Règle PREROUTING avec filtre sur l'interface d'entrée

        Posté par  . Évalué à 2.

        Je pense qu'il y a confusion :-)

        La seconde commande NETMAP citée fonctionne probablement très bien (du moins je ne vois pas pourquoi ça ne marcherait pas, si j'en crois le man et mon expérience de Netfilter). Mais encore faut-il router les paquets à destination de la 192.168.1.0/24 vers la bonne interface... C'est à dire à travers le VPN.

        Premier test à effectuer, est-tu capable de joindre l'adresse interne de ton routeur distant, 192.168.1.1 (en t'assurant qu'aucune règle de filtrage sur le routeur en question empeche le ping de répondre...) ?

        tcpdump est ton ami. Si les paquets n'arrivent pas sur le routeur distant, et qu'ils ne sont pas filtrés quelque part, c'est probablement qu'il te manque la route correspondante sur ton routeur local. Si les paquets arrivent, mais que tu n'as pas de réponse au ping (toujours dans l'hypothèse selon laquelle tu n'as pas de filtrage), alors c'est qu'il te manque la route retour (autrement dit, une route vers 10.1.1.0/24 depuis le routeur distant).
        • [^] # Re: Règle PREROUTING avec filtre sur l'interface d'entrée

          Posté par  . Évalué à 2.

          Je réponds un peu tard.

          Les paquets qui vont vers le réseau 192.168.1.1 sont envoyés comme si le réseau destination est 192.168.38.1
          Car il existe déjà un "vrai" 192.168.1.1 connecté au VPN. Et il est probable que d'autres réseaux 192.168.1.1 viennent se greffer plus tard. Le but est donc de transformer ces sous-réseaux tous identiques en quelque chose de routable.
          • [^] # Re: Règle PREROUTING avec filtre sur l'interface d'entrée

            Posté par  . Évalué à 1.

            Je vois le problème, mais ça ne change pas grand chose au chmilblick. Tes paquets ne partent probablement pas vers le VPN.

            Ce qu'il faut, c'est que tes paquets partent vers le VPN quand tu cherche à joindre un réseau donné. Donc il te faut une règle NETMAP en PREROUTING sur la passerelle locale qui va réécrire sur un réseau (choisi pour être unique), tu met une route vers ce réseau qui transite par le VPN, et une règle PREROUTING sur la passerelle VPN distante, pour réécrire les adresses arbitraires en adresses locale (par rapport au réseau distant, je sais pas si je me fais bien comprendre...). Bien évidemment, ça ne t'exonère pas des règles de SNAT en POSTROUTING pour gérer le problème de la route retour.

            Autre solution, le PBR, Policy Based Routing. Tu gères sur la passerelle locale plusieurs tables de routage (une par réseau distant), et tu utilise des règles iproute (ip rule add ...) pour envoyer les paquets dans les bonnes règles. Le problème étant que si les adresses source sont identiques pour accéder à plusieurs réseaux distants, ça va être coton pour faire des règles iproute qui conviennent...

            L'avantage dans ce cas là c'est que tu n'as pas de double NAT (chose que certains protocoles risquent de ne pas apprécier).

            Enfin, comme cela a été suggéré, tu peux utiliser un client openvpn sur chaque poste client, pour obtenir les adresses et routes nécessaires pour chaque réseau. Tu ne sera connecté qu'à un réseau à la fois mais ça résoud le problème. Dans la mesure ou les adresses à joindre sont des ip "internes", tu n'échapperas jamais vraiment au conflit autrement, il y aura toujours un cas pour t'embêter. Si il ne s'agit pas de connexions persistante, c'est probablement la meilleure solution, même si elle t'oblige à maintenir plusieurs configurations openvpn, à gérer les certificats et leur révocation, etc.
  • # Et pourquoi pas juste

    Posté par  . Évalué à 1.

    iptables -t nat -A POSTROUTING -o <interface_sur_le_réseau_192.168.1.0> -j MASQUERADE ?

Suivre le flux des commentaires

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