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 NeoX . É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 mazarini . É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.
[^] # Re: Si ca peut aider...
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
Malheureusement, je n'ai pas la main sur le firewall, mais merci quand même :-)
# Si tu veux pas que je trolle ...
Posté par Batchyx . Évalué à 3.
Commence par arrêter d'utiliser
ifconfig
etroute
et utiliseip addr
etip 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 versX.X.X.X
. Ensuite tu fait des bidouilles surX.X.X.X
, puis ensuite, tu rajoute, comme ça, salement, surX.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'IPX.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 estX.X.X.X
et la destination estY.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 versY.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 étantZ.Z.Z.1
.Pour l'autre, c'est très simple:
Si tu à envie de mettre un nom plus explicite au lieu de 2, édite
/etc/iproute2/rt_tables
, rajoute une entrée à toi, du genre2 directy
, ensuite tu pourra utilisertable directy
à la place detable 2
[^] # Re: Si tu veux pas que je trolle ...
Posté par aurel (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 :-)
Pour simplifier le tout, c'est depuis une 3ème machine que je me connecte sur
X.X.X.X
etY.Y.Y.Y
pour faire tous mes bricolages :-)Lorsque
Y.Y.Y.Y
se connecte par SSH surX.X.X.X
, c'est juste pour créer les 2 interfacestun1
. À ce moment là, je peux pingerMachineA/Z.Z.Z.1
depuisMachineB/Z.Z.Z.2
(et vice-versa).Si
MachineA
n'est pas un container OpenVZ, il me suffit de lui ajouter la nouvelle route versY.Y.Y.Y
en passant parZ.Z.Z.2
, et d'avoir l'IP forwarding d'activé surMachineB
pour pouvoir pingerY.Y.Y.Y
depuisMachineA
. 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
depuisMachineA/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
depuisMachineA/Z.Z.Z.1
C'est quand même bizarre non ? Ou bien ?
Aurel.
PS: merci je note pour
ip addr
etip route
:-)[^] # Re: Si tu veux pas que je trolle ...
Posté par Batchyx . Évalué à 2.
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):
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 aurel (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.