Forum Linux.général Problème du vendredi: réseau, ssh -w, OpenVZ :-)

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
1
28
juin
2013

Hello tous !

Je galère sur un problème dans lequel se mélangent à part égale réseau et virtualisation avec OpenVZ (grâce à Proxmox 3), et plutôt que de continuer à platement sécher, je viens voir si vous auriez une idée :)

La situation

J'ai deux machines dont les adresses ipv4 sont les suivantes:

machine A / X.X.X.X
machine B / Y.Y.Y.Y

Je veux accéder à l'interface réseau Y.Y.Y.Y (et pas à une autre) de la machine B depuis la machine A. Problème: Y.Y.Y.Y n'est pas accessible directement depuis A, car derrière un firewall. Pour arriver à mes fins, je créé donc un tunnel device entre A et B, en executant depuis B (qui peut accéder à X.X.X.X):

/usr/bin/ssh -C -oServerAliveInterval=60 \
  -o PermitLocalCommand=yes \
  -o LocalCommand="/sbin/ifconfig tun1 Z.Z.Z.2 pointopoint Z.Z.Z.1" \
  -w 1:1 \
  root@X.X.X.X \
  "ifconfig tun1 Z.Z.Z.1 pointopoint Z.Z.Z.2"

J'arrive donc à cette situation:

machine A / X.X.X.X et Z.Z.Z.1
machine B / Y.Y.Y.Y et Z.Z.Z.2

Je peux pinger Z.Z.Z.2 depuis la machine A, et Z.Z.Z.1 depuis la machine B. J'active ensuite l'ip-forwarding sur B, et je donne accès à Y.Y.Y.Y à la machine A en y ajoutant la route suivante:

route add -host Y.Y.Y.Y gw Z.Z.Z.2   

Tout marche bien, je peux pinger Y.Y.Y.Y depuis la machine A, et je suis content. En tout cas lorsque je fais des tests dans virtualbox, ou sur des machines physiques sur lesquelles j'ai la main.

Le problème

Dans la réalité, la machine A est un container OpenVZ (et se connecte au réseau par venet, pas par veth). J'arrive à créer les 2 tun1, à leur attribuer des adresses IP, et à faire pinger Z.Z.Z.2 depuis la machine A, et Z.Z.Z.1 depuis la machine B.

Malheureusement, tout se casse la figure lorsque j'ajoute la route "route add -host Y.Y.Y.Y gw Z.Z.Z.2": impossible de continuer à pinger Z.Z.Z.2 depuis la machine A, ni Z.Z.Z.1 depuis la machine B, ni évidemment d'accéder à Y.Y.Y.Y depuis la machine A. Lorsque je supprime la route, je retrouve le ping dans les 2 sens.

Je précise que j'ai évidemment activé l'ip_forwarding, que j'ai les policies d'iptables par défaut sur ACCEPT tant sur filter que sur nat, et qu'à ma connaissance, le setup des machines est identique entre mes tests et la réalité, modulo la virtualisation via OpenVZ de la machine A. J'ai pas mal cherché, et suis tombé sur pas mal de problèmes un peu similaires, qui datent tous de quelques années, et qui se résolvent pour la plupart en rajoutant "ip_nat" dans la variable IPTABLES de /etc/vz/vz.conf. Je ne mets pas de liens ici histoire de ne pas vous biaiser vers mon aveuglement. Évidemment, dans mon cas, ça ne change rien, d'où l'aide que je viens chercher auprès de vous, qui m'avez lu jusqu'ici :-)

A votre bon coeur, et bon week end !

Aurel.

PS: certe on est vendredi et je parle d'OpenVZ, mais essayer ne pas trop troller, des fois que certains trouvent le sujet propice… :-)

  • # arf, vu trop tard

    Posté par  . Évalué à 2.

    j'ai du proxmox3 au boulot, j'aurais pu tester tes cas,
    mais là je suis à la maison, j'ai plus la main…

    faut peut-etre chercher sur le net pour savoir qu'elles sont les differences entre venet et veth,
    je sais que toutes mes machines sont en veth/bridgé sur eth1 de mon serveur, eth0 etant l'interface d'administration.

  • # Si ca peut aider...

    Posté par  . Évalué à 1.

    Pourquoi ne pas modifier le firewall pour autoriser les paquets entre A et B ?

    Pour mon réseau entre mes machines virtuelles, j'ai créer 2 bridges sur des interfaces dummy. Un bridge "local" pour les communications entre machines qui permet aussi les communications sortantes vers internet. Un autre (dmz ?) pour les communications entrantes depuis internet. Le routage permet les flux entre eth0 et les 2 bridges.
    Mes machines virtuelles ont 1 interface sur le réseau local (premier bridge) et éventuellement seconde avec 2 adresses (locale et publique).
    L'hote sert ainsi une sorte de routeur et de firewall.
    Ca a été galère à mettre au point, mais ca me semble pas trop mal. Pas sur que ce soit la bonne méthode, je débute. Le seul truc qui me semble louche, c'est que sur les machines à 2 interfaces, les demandes rentrent par une interface et la réponse sort par l'autre.

  • # Si tu veux pas que je trolle ...

    Posté par  . Évalué à 3.

    Commence par arrêter d'utiliser ifconfig et route et utilise ip addr et ip route à la place. Surtout si tu fait des confs réseaux un poil avancées.

    Maintenant, ip route à une super méga fonctionnalité qui permet de savoir quel route le noyau choisi selon ta destination: ip route get. Tu verra, c'est magique.

    Maintenant sur ta conf:

    tu à Y.Y.Y.Y qui ouvre une session SSH vers X.X.X.X. Ensuite tu fait des bidouilles sur X.X.X.X, puis ensuite, tu rajoute, comme ça, salement, sur X.X.X.X une route vers Y.Y.Y.Y qui passe pas là ou ça passait d'habitude.

    Sauf que pour router ton traffic SSH, le noyau va utiliser ta table de routage. Si quand le démon SSH veut aller renvoyer du TCP à Y.Y.Y.Y, il passe par ton tunnel, c'est mort. Je ne comprend pas comment ça à pu marcher tel quel. T'est sûr qu'il n'y avais pas du NAT entre les deux la première fois ?

    Maintenant, ce genre de conf est possible avec du policy routing. Mais déjà, il va falloir jeter route aux oubliettes, il va pas suivre longtemps le pauvre.

    Ensuite il va falloir savoir ce que tu veux. Déjà tu veux que quand Y.Y.Y.Y te titille sur l'IP X.X.X.X, alors tu veux répondre directement. La manière la plus simple, c'est de router en fonction de l'adresse source: si la source est X.X.X.X et la destination est Y.Y.Y.Y, alors passe directement par l'interface.

    Ensuite, si tu veux que quand tu tape Y.Y.Y.Y dans un logiciel sans rien préciser d'autre (genre l'adresse de bind), ça passe par ton tunnel, ça veut dire que la route qui va vers Y.Y.Y.Y en passant par ton tunnel doit être par défaut. Celle là tu la met dans ta table de routage par défaut. Et tant qu'à faire, spécifie lui bien l'adresse source préférée comme étant Z.Z.Z.1.

    Pour l'autre, c'est très simple:

    ip rule add from X.X.X.X table 2
    ip route add Y.Y.Y.Y via ta-gateway-habituelle dev ton-interface-habituelle table 2
    

    Si tu à envie de mettre un nom plus explicite au lieu de 2, édite /etc/iproute2/rt_tables, rajoute une entrée à toi, du genre 2 directy, ensuite tu pourra utiliser table directy à la place de table 2

    • [^] # Re: Si tu veux pas que je trolle ...

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Hello!

      Merci pour ta réponse: à défaut de résoudre le problème, ca fait travailler les méninges :-)

      tu à Y.Y.Y.Y qui ouvre une session SSH vers X.X.X.X. Ensuite tu fait des bidouilles sur X.X.X.X, puis ensuite, tu rajoute, comme ça, salement, sur X.X.X.X une route vers Y.Y.Y.Y qui passe pas là ou ça passait d'habitude.
      Sauf que pour router ton traffic SSH, le noyau va utiliser ta table de routage. Si quand le démon SSH veut aller renvoyer du TCP à Y.Y.Y.Y, il passe par ton tunnel, c'est mort. Je ne comprend pas comment ça à pu marcher tel quel. T'est sûr qu'il n'y avais pas du NAT entre les deux la première fois ?

      Pour simplifier le tout, c'est depuis une 3ème machine que je me connecte sur X.X.X.X et Y.Y.Y.Y pour faire tous mes bricolages :-)

      Lorsque Y.Y.Y.Y se connecte par SSH sur X.X.X.X, c'est juste pour créer les 2 interfaces tun1. À ce moment là, je peux pinger MachineA/Z.Z.Z.1 depuis MachineB/Z.Z.Z.2 (et vice-versa).

      Si MachineA n'est pas un container OpenVZ, il me suffit de lui ajouter la nouvelle route vers Y.Y.Y.Y en passant par Z.Z.Z.2, et d'avoir l'IP forwarding d'activé sur MachineB pour pouvoir pinger Y.Y.Y.Y depuis MachineA. Je ne vois pas bien où est-ce que j'aurais besoin du NAT dans cette histoire, puisque ca marche très bien sans? À moins que je rate quelque chose?

      Si MachineA est un container OpenVZ, l'ajout de la route n'a pas les même conséquence, et rend impossible les pings:
      * de Z.Z.Z.2 depuis MachineA/Z.Z.Z.1 (et vice-versa), alors que ca me semble totalement indépendant de la route que j'ajoute
      * de Y.Y.Y.Y depuis MachineA/Z.Z.Z.1

      C'est quand même bizarre non ? Ou bien ?

      Aurel.

      PS: merci je note pour ip addr et ip route :-)

      • [^] # Re: Si tu veux pas que je trolle ...

        Posté par  . Évalué à 2.

        Si MachineA n'est pas un container OpenVZ, il me suffit de lui ajouter la nouvelle route vers Y.Y.Y.Y en passant par Z.Z.Z.2, et d'avoir l'IP forwarding d'activé sur MachineB pour pouvoir pinger Y.Y.Y.Y

        C'est ça qui est surprenant, et franchement pas normal.

        Du point de vue de X.X.X.X, il y a deux connections (ou sockets, si tu préfère):

        • La connection SSH: X.X.X.X:22 <-> Y.Y.Y.Y:????
        • Le ping dans le tunnel: Z.Z.Z.1 <-> Y.Y.Y.Y

        Quand tu modifie la route vers Y.Y.Y.Y, tu la modifie pour tout les paquets à destination de Y.Y.Y.Y. Y compris pour les paquets SSH. qui encapsulent tes paquets tunellés. Je ne comprend pas comment ça peut marcher sous Linux de base, à moins que SSH fasse quelque chose de spécial ou qu'il y ai un bug dans le noyau. Quelle est la version de ton noyau ?

        Sinon je vois pas l'intérêt de vouloir continuer à chercher à faire fonctionner avec OpenVZ une configuration réseau qui n'est pas censé marcher de base.

        • [^] # Re: Si tu veux pas que je trolle ...

          Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 29 juin 2013 à 12:27.

          Bonne nouvelle: je commence à comprendre ce que tu veux dire, même si aucune explication évidente ne me vient à l'esprit, sinon que ça "juste marche" dans tous les test que j'ai pu faire hors d'OpenVZ: entre machines physiques ou machines virtuelles dans VirtualBox, avec des Ubuntu Server 12.04.2 LTS :)

          Mon noyau est le 2.6.32-20-pve de proxmox. J'utilise SSH de la même façon que ce qui est décrit ici: https://help.ubuntu.com/community/SSH_VPN, sauf que je ne veux pas relier 2 réseaux, mais simplement accéder à une autre interface réseau (Y.Y.Y.Y) de la machine B depuis la machine A.

          PS: Si ça peut faire avancer le schmilblick, je précise que les adresses X.X.X.X et Z.Z.Z.Z sont routables, contrairement à Z.Z.Z.1/2 qui sont privées (10.0.X.X).

Suivre le flux des commentaires

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