J'aime beaucoup openvpn, j'aime bien vmware (malgré ses défauts), j'aime bien ovh, mais les trois ensemble, y'a comme une incompatibilité.
Je 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 :-)
Forum Linux.debian/ubuntu openvpn, vmware, ovh, l'enfer du décor
6
avr.
2008
# Je ne comprends pas pourquoi..
Posté par GG (site web personnel) . Évalué à 1.
Quelle est la différence?
A bientôt
Amicalement
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Je ne comprends pas pourquoi..
Posté par totof2000 . Évalué à 2.
[^] # Re: Je ne comprends pas pourquoi..
Posté par Sebastian . Évalué à 2.
[^] # Retour d'expérience
Posté par Kerro . Évalué à 2.
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).
[^] # Re: Je ne comprends pas pourquoi..
Posté par NeoX . Évalué à 1.
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 ?
[^] # Re: Je ne comprends pas pourquoi..
Posté par LaBienPensanceMaTuer . Évalué à 3.
Il veut utiliser wmware, point.
[^] # Re: Je ne comprends pas pourquoi..
Posté par totof2000 . Évalué à 1.
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 LaBienPensanceMaTuer . Évalué à 3.
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 GG (site web personnel) . Évalué à 2.
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
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# NAT ???
Posté par NeoX . Évalué à 1.
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)
[^] # Re: NAT ???
Posté par snurpsss . Évalué à 2.
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 . Évalué à 2.
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 ?
# En mode non pont.
Posté par LaBienPensanceMaTuer . Évalué à 2.
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 . Évalué à 1.
cela est donc transparent pour la machine hote
[^] # Re: En mode non pont.
Posté par Kerro . Évalué à 2.
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.
[^] # Re: En mode non pont.
Posté par NeoX . Évalué à 1.
ca te permet d'avoir N machines virtuelles mais que ce soit la machine hote qui soit emettrice des paquets.
[^] # Re: En mode non pont.
Posté par Kerro . Évalué à 2.
[^] # Re: En mode non pont.
Posté par NeoX . Évalué à 1.
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.
[^] # Re: En mode non pont.
Posté par Kerro . Évalué à 2.
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.
[^] # Re: En mode non pont.
Posté par NeoX . Évalué à 0.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.