Home » International » French » Problème insoluble
| Problème insoluble [message #43085] |
Wed, 20 July 2011 08:08  |
anotherservice
Messages: 2
Registered: July 2011
|
Junior Member |
|
|
Bonjour à tous,
Mon premier message sur ce forum, après une semaine de cheveux arrachés, je me tourne vers vous pour un problème qui m'échappe complètement.
Voici ma configuration actuelle (simplifiée pour le case) :
- Un noeud Proxmox, à jour avec :
vmbr0 (bridge interne indépendant)
vmbr1 (bridge externe avec eth0 dedans) et la configuration IPV4 fixe du serveur dédié suivante :
auto vmbr1
iface vmbr1 inet static
address 46.105.111.210
netmask 255.255.255.0
network 46.105.111.0
broadcast 46.105.111.255
gateway 46.105.111.254
bridge_ports eth0
bridge_stp off
bridge_fd 0
Jusqu'ici tout fonctionne parfaitement.
- Une machine virtuelle OpenVZ (container) avec des interface en veth (pas de venet).
Une première interface eth0, bridgée avec vmbr0 sur l'interne, config IP en DHCP (sans gateway par défaut) provenant d'une autre VM, aucun souci, fonctionnement optimal.
Une seconde interface eth1, bridgée avec vmbr1 sur l'externe, config IP fixée avec une IP failover et la config suivante :
auto eth1
iface eth1 inet static
address 91.121.49.65
netmask 255.255.255.255
broadcast 91.121.49.65
post-up route add 46.105.111.254 dev eth1
post-up route add default gw 46.105.111.254
post-down route del 46.105.111.254 dev eth1
post-down route del default gw 46.105.111.254
Pour que cela fonctionne, j'ai une adresse MAC virtuelle créée dans l'interface OVH :
02:00:00:2a:21:95 proxy96041 91.121.49.65 ovh
Pour configurer cette MAC virtuelle, le fichier de configuration du container contient :
NETIF="ifname=eth0,bridge=vmbr0,mac=00:10:20:25:6E:00,host_ifname=veth96041.0,host_mac=00:18:51:44:91:73;ifname=eth1,bridge=vmbr1,mac=02:00:00:2a:21:95,host_ifname=veth96041.1,host_mac=00:18:51:E5:0E:58
Jusque là tout va bien. Nous voilà au problème.
1) Sans rien faire de plus que ça, j'arrive à pinger la machine virtuelle sur son IP, mais sans vraiment y arriver.
J'effectue un ping depuis mon PC personnel à la maison :
C:\ping -t 91.121.49.65
Envoi d'une requête 'Ping' 91.121.49.65 avec 32 octets de données*:
Réponse de 91.121.49.65*: octets=32 temps=49 ms TTL=57
Réponse de 91.121.49.65*: octets=32 temps=45 ms TTL=57
Réponse de 91.121.49.65*: octets=32 temps=46 ms TTL=57
Réponse de 91.121.49.65*: octets=32 temps=45 ms TTL=57
Réponse de 91.121.49.65*: octets=32 temps=45 ms TTL=57
Sur le noeud physique :
root@on-005:/etc/vz/conf# tcpdump -i vmbr1 host 91.121.49.65
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), capture size 96 bytes
02:37:49.332028 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2201, length 40
02:37:49.332083 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2201, length 40
02:37:50.332827 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2202, length 40
02:37:50.332861 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2202, length 40
02:37:51.335764 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2203, length 40
02:37:51.335798 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2203, length 40
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
Mais sur la VM rien, le calme plat :
root@proxy-96041:/# tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
Et même, le tcpdump freeze !
Comme indiqué sur la documentation OpenVZ, je rajoute alors la route de l'IP fail-over sur le bridge vmbr1 (et ceci à chaque start/stop de la VM) :
#!/bin/bash
ip route add 91.121.49.65 dev vmbr1
Et là miracle, tout apparaît nickel, mais avec un énorme hic (et c'est ici que j'espère votre éclairage) :
Sur le noeud physique :
root@on-005:/etc/vz/conf# tcpdump -i vmbr1 host 91.121.49.65
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), capture size 96 bytes
02:54:16.247584 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2924, length 40
02:54:16.247621 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2924, length 40
02:54:17.265167 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2925, length 40
02:54:17.265196 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2925, length 40
02:54:18.250581 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2926, length 40
02:54:18.250638 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2926, length 40
02:54:19.250505 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2927, length 40
02:54:19.250545 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2927, length 40
02:54:20.252028 IP 164.218.11.109.rev.sfr.net > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2928, length 40
02:54:20.252066 IP 91-121-49-65.ovh.net > 164.218.11.109.rev.sfr.net: ICMP echo reply, id 256, seq 2928, length 40
Mais sur la VM, il croit parler au noeud physique ! :
root@proxy-96041:/# tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:54:18.250606 IP on-005.olympe-network.com > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2926, length 40
02:54:18.250630 IP 91-121-49-65.ovh.net > on-005.olympe-network.com: ICMP echo reply, id 256, seq 2926, length 40
02:54:19.250526 IP on-005.olympe-network.com > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2927, length 40
02:54:19.250542 IP 91-121-49-65.ovh.net > on-005.olympe-network.com: ICMP echo reply, id 256, seq 2927, length 40
02:54:20.252045 IP on-005.olympe-network.com > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2928, length 40
02:54:20.252060 IP 91-121-49-65.ovh.net > on-005.olympe-network.com: ICMP echo reply, id 256, seq 2928, length 40
02:54:21.254168 IP on-005.olympe-network.com > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2929, length 40
02:54:21.254187 IP 91-121-49-65.ovh.net > on-005.olympe-network.com: ICMP echo reply, id 256, seq 2929, length 40
02:54:22.255895 IP on-005.olympe-network.com > 91-121-49-65.ovh.net: ICMP echo request, id 256, seq 2930, length 40
02:54:22.255916 IP 91-121-49-65.ovh.net > on-005.olympe-network.com: ICMP echo reply, id 256, seq 2930, length 40
Il voit les paquets arriver depuis le noeud physique et lui répond directement, le noeud physique retranscrit ensuite bien les paquets, comme s'il faisait de la NAT...
Et cela est très embêtant, car par exemple les logs d'un serveur web ou d'un serveur FTP à l'intérieur de la VM donnent tous comme IP source celle du noeud physique. Et il n'y a pas de header contenant l'IP source, elle est translatée...
Le traceroute est correct et ne voit pas le noeud physique :
C:\tracert 91.121.49.65
Détermination de l'itinéraire vers 91-121-49-65.ovh.net [91.121.49.65]
avec un maximum de 30 sauts*:
1 <1 ms <1 ms <1 ms neufbox [192.168.1.1]
2 40 ms 41 ms 42 ms 1.218.11.109.rev.sfr.net [109.11.218.1]
3 40 ms 40 ms 39 ms 157.117.0.109.rev.sfr.net [109.0.117.157]
4 41 ms * 41 ms 010G.th2-1-6k.routers.ovh.net [86.66.127.118]
5 45 ms 56 ms * gsw-2-6k.fr.eu [213.186.32.162]
6 45 ms 45 ms 45 ms rbx-g1-a9.fr.eu [213.251.128.105]
7 81 ms 45 ms * vss-5a-6k.fr.eu [178.33.100.26]
8 44 ms 44 ms 44 ms 91-121-49-65.ovh.net [91.121.49.65]
Itinéraire déterminé.
Je n'ai activé aucun NAT iptables, voici la commande :
root@on-005:/etc/vz/conf# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Est-ce les "MASQUERADE" (activés par défaut ?!) qui sont responsables de ce problème ? Si oui comment les enlever ? Sinon avez-vous une solution ?
Merci de votre patience, j'espère avoir été clair et pouvoir trouver de l'aide ici !
Merci d'avance 
Cordialement,
Samuel
|
|
|
|
| Re: Problème insoluble [message #43113 is a reply to message #43085] |
Fri, 22 July 2011 09:51  |
anotherservice
Messages: 2
Registered: July 2011
|
Junior Member |
|
|
Bonjour,
J'ai tenté deux choses :
- Mise en mode promiscious des interfaces eth0 et vmbr1, aucun résultat.
- Purge des règles de NAT par défaut qui apparaîssent sur la dernière commande, pas mieux.
Une idée ?
Cordialement,
Samuel
|
|
|
|
Goto Forum:
Current Time: Sun May 05 12:19:56 GMT 2024
Total time taken to generate the page: 0.01939 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
