Retourner aux forums || Retourner au forum Linux.debian
Linux.debian : openvpn, vmware, ovh, l'enfer du décor
Posté par Kerro () le 06 avril 2008Je travaille sur un bête problème depuis presque une semaine. Je n'ai pas avancé d'un milimètre. D'origine ça fonctionne mal, le mieux que j'arrive à faire est que ça fonctionne aussi mal, mais autrement :-)
Chez d'autres hébergeurs, zéro problème. Ca fonctionne tout de suite. Chez ovh je suis planté bien comme il faut.
J'ai:
- un serveur dédié chez ovh, avec Debian Etch dessus.
- vmware installé sur Etch.
- plusieurs machines virtuelles Windows "dans" vmware.
- un vpn entre ce serveur et d'autres machines fait avec openvpn.
Le problème vient d'une sécurité mise en place par ovh: si une machine se met à émettre une adresse MAC qui n'est pas la bonne, le port réseau est fermé pendant une heure je crois sur leur switch (ou sur leur routeur, je ne sais pas).
Manque de chance, j'utilise le mode pont (bridge) pour mes machines virtuelles. Ce mode pont transmet les adresses MAC bidon des cartes réseau virtuelles. Donc couic, impossible de faire fonctionner ça chez ovh.
Chez d'autres hébergeurs ça fonctionne car la plupart n'ont probablement pas la sécurité qu'ovh a mis en place.
Pourquoi utiliser le mode pont ?
C'est le seul et unique moyen que je connaisse pour que vmware daigne faire transiter les paquets via le vpn. Il faut activer le mode pont vers une carte réseau physique.
J'ai essayé en créant une carte réseau bidon (modprobe dummy, etc). Les paquets ne vont plus vers le vpn (mais ça fonctionne entre les machines virtuelles).
J'ai essaye en créant un pont "vide" (brctl addbr br0 et c'est tout). Les paquets ne vont plus vers le vpn. Idem en reliant une ou plusieurs dummy à br0.
J'ai essayé en reliant vmnet0 à eth0 (configuration habituelle) et en utilisant ebtables pour interdire la sortie des paquets ayant la mauvaise MAC vers le réseau physique. Les paquets, une fois de plus, ne vont plus vers le vpn.
Arghhhh, comment ils se sont débrouillés chez vmware pour faire un truc comme ça bor... heu zut à la fin !
Chez xen et virtualbox ils ont utilisés les fonctions "normales" de Linux pour le réseau. Mais chez vmware je suppose que c'est pour être crétin-proof qu'ils ont mis en place leur vmnet à la gomme. Et bien entendu ça ne fonctionne que dans les cas parfaitement standards. Dès qu'on est un poil en dehors des clous c'est la cata.
J'ai aussi essayé avec une interface tap, pas mieux.
J'ai aussi essayé en prenant une grande respiration et en restant zen. Ca n'a rien fait non plus.
Pour faire fonctionner le tout, je suis obligé de mettre openvpn dans les machines Windows. C'est cracra mais en attendant ça fonctionne.
Si quelqu'un a la moindre idée, pas d'hesitation surtout :-)
Qui a existé en premier: le compilateur ou son code source ?
Je ne comprends pas pourquoi..
Je ne comprends pas pourquoi tu n'utilises pas VirtualBox.
Quelle est la différence?
A bientôt
Amicalement
-
[^]Re: Je ne comprends pas pourquoi..
Posté par totof2000 () le 07/04/2008 à 01:05. (lien). Évalué à 2.virtualbox est_il capable de faire tourner un windows ?
-
[^]Re: Je ne comprends pas pourquoi..
-
[^]Retour d'expérience
Posté par Kerro () le 12/04/2008 à 11:39. (lien). Évalué à 2.Tu affirmes que VirtualBox sait faire tourner Windows mieux que vmware. C'est dommage que tu n'aies pas apporté d'arguments lorsque je demandais des retours d'expériences ici: http://linuxfr.org/forums/41/24012.html
Les retours d'expérience que j'ai pu voir à propos de VirtualBox en production ne sont pas à la hauteur de vmware (qui pourtant est loin d'être parfait).--
Qui a existé en premier: le compilateur ou son code source ?
-
-
-
[^]Re: Je ne comprends pas pourquoi..
Posté par NeoX () le 07/04/2008 à 12:41. (lien). Évalué à 1.virtualbox permet de controler un "serveur" de machines virtuelles ?
en gros, vmware se lance en serveur sur la machine chez ovh,
avec ton client, tu demandes au serveur de creer une machine avec certaines caracteristiques...
tu lances la machine virtuelle
puis tu fermes ton client.
la machine virtuelle continue de tourner.
virtualbox permet-il cela ?--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux
-
[^]Re: Je ne comprends pas pourquoi..
Posté par Gérald (page perso, ) le 07/04/2008 à 14:12. (lien). Évalué à 3.Comme assez souvent, je déplore que la première réponse à cette question soit "pourquoi tu fais pas autrement ?".
Il veut utiliser wmware, point.-
[^]Re: Je ne comprends pas pourquoi..
Posté par totof2000 () le 07/04/2008 à 18:18. (lien). Évalué à 1.je déplore que la première réponse à cette question soit "pourquoi tu fais pas autrement ?".
omme assez souvent, je déplore ce genre d'intervention.
C'est une question posée, c'est tout. Peut-être que VMWare sait faire des choses que ne sait pas faire VirtualBox et dont il a besoin ?-
[^]Re: Je ne comprends pas pourquoi..
Posté par Gérald (page perso, ) le 07/04/2008 à 18:32. (lien). Évalué à 3.Hmm mauvaise foi inside mais bon, j'vais rentrer dans ton jeu.
C'est une question posée, c'est tout.
On ne répond pas à une question par une autre question qui s'éloigne du sujet d'origine, encore moins sur un forum car ça tend à pourrir le référencement et donc la visibilité du thread.
Peut-être que VMWare sait faire des choses que ne sait pas faire VirtualBox et dont il a besoin ?
Tu en doutes encore ?
Non parce que bon, vmware est l'acteur phare sur ce secteur et ce depuis des années.
La première release de VirtualBox date de Janvier 2007 (voir http://www.virtualbox.org/wiki/Changelog).
Je pense que, abstraction faites de l'aspect proprio/opensource, vmware est bien plus mature que VirtualBox, à vue de nez hein ...-
[^]Re: Je ne comprends pas pourquoi..
Posté par Grégoire G (Jabber id, page perso, ) le 07/04/2008 à 19:07. (lien). Évalué à 2.Et, si autre chose que vmware était une meilleur solution?
En tout cas, les réponses aux questions des questions m'apportent bien souvent des éléments intéressants.
Internet Explorer est l'acteur phare du net, et pourtant ce n'est pas une lumière.
Concernant le référecement, ce n'est pas forcément un problème puisque cela permet de donner des noms annexes et connexes sur le thème.
Amicalement
Grégoire
-
-
-
NAT ???
si je comprend bien tu as
un VPN entre le serveur dédié et d'autres machines.
un serveur de VM sur le serveur dédié.
et tu souhaites que les VM puissent aller sur le VPN.
as-tu besoin que tes VM soient joignables de l'exterieur (ip publique ?)
si ce n'est pas le cas, regarde du coté du mode NAT des cartes reseaux virtuelles.
Tu auras ainsi
Machine virtuelle 1 - > NAT ( Machine physique ) VPN -> Internet < - le reste du monde
Machine virtuelle 2 _|
Machine virtuelle 3 _|
Avec l'avantage que ce soit transparent pour ta machine physique...
sinon il doit falloir demander à OVH une IP par machine virtuelle que tu utilises,
et ensuite donner ta machine reelle comme passerelle de ces machines virtuelles (avec les regles de parefeu qui vont bien)
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux
-
[^]Re: NAT ???
Posté par snurpsss () le 08/04/2008 à 15:45. (lien). Évalué à 2.Pas mieux...(= j'aurai dit pareil)
Et si les machines doivent être joignables depuis l'exterieur (typiquement RDP dessus, car c'est des windows) , on doit pouvoir faire du port forwarding port 4001 de ton ip reel sur port RDP de ta machine 192.168.0.1, 4002 sur port RDP de la machine en 192.168.0.2, etc...)
-
[^]Re: NAT ???
Posté par Kerro () le 12/04/2008 à 11:55. (lien). Évalué à 2.Une IP par machine virtuelle ne change rien puisque c'est d'abord un problème de MAC (niveau 2, le protocole IP est au niveau 3).
Je dois "juste" faire en sorte que les paquets Ethernet venant des machines virtuelles ne sortent jamais par eth0.
J'ai essayé avec une interface dummy0. Ca fonctionne en local, mais le routage ne se fait pas. Ne me demandez pas pourquoi.
J'ai essayé avec une interface br0 toute seule, pas mieux. br0 reliée à eth0, avec ebtables pour filtrer, pas mieux (?!).
J'ai essayé avec une interface tap0, si si, j'ai insisté :-) Toujours la même chose: ça fonctionne en local, mais pas de routage. C'est à dire que mes machines virtuelles peuvent dialoguer, elles peuvent dialoguer avec l'hôte, mais les paquets ne sont jamais routés vers le vpn ou l'extérieur. Alors qu'avec un bête xen et tap0 ça roule.
Je suis persuadé qu'avec br0 relié à eth0 et ebtables je peux obtenir le bon fonctionnement.
===============
IF=eth0
BR=br0
IP=$(ifconfig $IF | sed -n 's#.*inet adr\:\([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\) .*#\1#p')
MASK=$(ifconfig $IF | sed -n 's#.*Masque\:\([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\)$#\1#p')
GATEWAY=$(route -n | sed -n "s#^0\.0\.0\.0 *\([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\) .*0\.0\.0\.0 .*$IF\$#\1#p")
ifconfig $IF 0.0.0.0
brctl addbr $BR
brctl stp $BR off
brctl setfd $BR 0
brctl addif $BR $IF
ifconfig $BR $IP netmask $MASK up
route add default gateway $GATEWAY dev $BR
===============
Après ces commandes, on n'utilise plus eth0 mais br0. Pour tout.
ping google.fr fonctionne
le vpn fonctionne, etc.
Tout ce qui entre/sort de br0 est recopié sur eth0.
Avec ebtables je peux bloquer les MAC sortantes pour que toute MAC égale à celle d'une des machines virtuelles ne sorte jamais. Et je n'arrive à rien. Soi tout passe, soi rien. Je pense que je n'utilise pas les bonnes commandes pour ebtables.
Quelqu'un sait comment bloquer une mauvaise MAC en sortie d'eth0 dans ce cas ?--
Qui a existé en premier: le compilateur ou son code source ?
En mode non pont.
Salut,
Lorsque tu dis que tu passes en mode bridge, modifies tu ton firewalling en conséquence ?
As tu activé le forwarding de paquet ?
Il n'y a, à priori, pas de raison que cela ne fonctionne pas, hormis si tu as un problème au niveau du filtrage ou du routage.
Aide toi de tcpdump pour déterminer d'ou vient l'erreur.
Sinon, si tu veux rester en mode pont, tu peux utiliser ebtables, l'équivalent de iptables pour le layer 2.
Il y a une règle de snat te permettant de changer ta mac adresse source:
snat
The snat target can only be used in the POSTROUTING chain of the nat
table. It specifies that the source MAC address has to be changed.
--to-source address
Changes the source MAC address to the specified address. The
flag --to-src is an alias for this option.
--snat-target target
Specifies the standard target. After doing the snat, the rule
still has to give a standard target so ebtables knows what to
do. The default target is ACCEPT. Making it CONTINUE could let
you use multiple target extensions on the same frame. Making it
DROP doesn't make sense, but you could do that too. RETURN is
also allowed. Note that using RETURN in a base chain is not
allowed.
--snat-arp
Also change the hardware source address inside the arp header if
the packet is an arp message and the hardware address length in
the arp header is 6 bytes.
-
[^]Re: En mode non pont.
Posté par NeoX () le 07/04/2008 à 20:45. (lien). Évalué à 1.en mode bridge, si je ne me trompe pas, la carte virtuelle est directement relié au cable reseau
cela est donc transparent pour la machine hote--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux-
[^]Re: En mode non pont.
Posté par Kerro () le 12/04/2008 à 11:44. (lien). Évalué à 2.La carte virtuelle est "directement connectée au câble réseau", c'est bien le problème. Les paquets Ethernet sortent avec l'adresse MAC des cartes virtuelles (normal) et c'est ce que je dois éviter.
J'ai regardé le code source du pilote de leur vmnet. Ca cré un pont exactement comme une interface tap si j'ai bien tout compris.--
Qui a existé en premier: le compilateur ou son code source ?-
[^]Re: En mode non pont.
Posté par NeoX () le 12/04/2008 à 14:40. (lien). Évalué à 1.il te reste donc à regler ta VM pour avoir une carte reseau NAT
ca te permet d'avoir N machines virtuelles mais que ce soit la machine hote qui soit emettrice des paquets.--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux-
[^]Re: En mode non pont.
Posté par Kerro () le 12/04/2008 à 14:47. (lien). Évalué à 2.Le mode NAT ne résoud pas le problème. Ca ne permet pas de router les paquets. Seul le mode pont le fait, sauf qu'il ne le fait QUE lorsque qu'il est relié à eth0. D'où le besoin de supprimer tous les paquets sortants avec la mauvaise MAC.
--
Qui a existé en premier: le compilateur ou son code source ?-
[^]Re: En mode non pont.
Posté par NeoX () le 12/04/2008 à 15:53. (lien). Évalué à 1.Le mode NAT devrait le faire car c'est la definition meme...
UNe seule machine est vue sur eth0 et c'est la machine hote.
les machines Guest sont sur un reseau à part et passe par ta machine Hote pour aller sur internet
Le mode PONT/BRIDGE par definition mets ta carte virtuelle directement sur le reseau physique, et donc ce sera son adresse MAC qui sera visible vu qu'elle se retrouve physiquement sur le reseau de ton ISP.--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux-
[^]Re: En mode non pont.
Posté par Kerro () le 12/04/2008 à 18:26. (lien). Évalué à 2.Tu es têtu :-)
Le mode NAT ne permet pas de router.
ROU-TER.
J'ai besoin de router pour utiliser un vpn. Sinon pas besoin de vpn, tout ce passerait en local ou en NAT.
Pour relier 27 sites entre eux avec des services complexes, j'utilise un vpn, pas du NAT. C'est également une question de sécurité.
Alors bon, je pourrais faire un vpn dans un NAT. C'est ce que je fais actuellement :-) C'est juste méga-gruic.--
Qui a existé en premier: le compilateur ou son code source ?-
[^]Re: En mode non pont.
Posté par NeoX () le 13/04/2008 à 22:39. (lien). Évalué à 0.ben chez moi j'ai 10 VM sur ma machine
elles sont toutes en modes NAT
et mon routeur internet ne voit QUE ma machine hote.
si je relie ma machine hote à un VPN, je penses (mais il est vrai que je n'ai pas testé) que mes machines GUEST auront acces au VPN.--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux
-
-
-
-
-
-
Revenir en haut de page || Retourner aux forums || Retourner au forum Linux.debian
Cette page a été générée par Templeet en 0.0812s (dont 0.006 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.