Bonjour,
Cela fait maintenant plus d'un mois que je me bats avec les interlocuteurs OVH pour leur expliquer un problème simple :
Nous sommes plusieurs abonnés à recevoir les données réseaux d'autres abonnés OVH sur nos cartes réseaux.
Nous sommes donc à même d'analyser les flux réseaux d'autres abonnés. (cool diraient certains)
OVH trouve cela normal et argue du fait qu'il s'agit de messages de diffusions, ou de routes mal configurés sur nos serveurs.
Que nenni, il s'agit de flux web, de torrent etc (pas du broadcast) et nos routes sont bien configurées.
J'ai déjà éclusé 3 interlocuteurs chez eux, si quelqu'un avait un contact compétent.
Merci.
Nicolas
Forum général.général sécurité réseau chez OVH
27
mai
2009
# commutateur
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: commutateur
Posté par Old Geek . Évalué à 1.
Plus précisément on reçoit les paquets en copie (bizarre) à destinations des autres serveurs. Exemple, je surfe sur le site d'un autre abonné OVH depuis chez moi (perso), et j'analyse le réseau depuis mon serveur OVH, le site web de l'autre abonné réponds parfaitement, et j'ai vu passer mes paquets perso vers lui depuis mon serveur hébergé. Par contre on ne voit pas passer les paquets en retour.
[^] # Re: commutateurww
Posté par nicodache . Évalué à 3.
[^] # Re: commutateur
Posté par nono14 (site web personnel) . Évalué à 2.
J'ai déja vu cela sur des commutateurs 6co.
Qd le commutateur rame le traffic n'est plus switché entre les différents ports.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# Machines virtuelles ?
Posté par Olivier (site web personnel) . Évalué à 2.
les serveurs des autres abonnés ainsi que le tiens sont peut-être hébergés sur la même machine physique, que vous partagez via de la virtualisation (vmware, virtualbox, etc...).
Peut-être que c'est cette virtualisation qui ne marche pas correctement, et donc que le soft de virtualisation vous envoie à tout les deux (le site officiel et le tiens), les paquets destinés au site officiel. Il est alors assez logique que tu ne vois pas pas les réponses du site officiel à son client (par exemple, lors du test que tu as fait dans la discussion au-dessus).
J'imagine que c'est faisable (bien que anormal) si les deux machines virtualisées ont la même adresse MAC réseau (carte réseau virtualisé, bien sûr).
[^] # Re: Machines virtuelles ?
Posté par Old Geek . Évalué à 3.
Bien tenté aussi ;) ,
mais non, vu le prix et la gamme de serveurs, ils sont bien physiques !
Nicolas.
# Forums OVH
Posté par Kerro . Évalué à 7.
Comme (presque) partout ailleurs, la ligne chaude d'OVH est principalement uniquement constituée de personnes sachant répondre aux cas simples (traduire par: qui savent lire leur base de connaissance interne).
Exemple tout frais de la semaine dernière: je demande si il y a une limite au nombre d'hôtes déclarés sur leur dns dynamique. Je résume:
Question: quelle est votre limite du nombre d'hôtes de dns dynamique ? Peut-on mettre des adresses privées ? (10.x.y.z par exemple)
Réponse: Les IP fail over seront limiter a 30 par serveur et celle ci aurons des IP ou les 3 premiers champs seront prédéfini par OVH
(les fautes sont d'origine)
Aucun rapport avec la choucroute donc. Je demande qu'une autre personne réponde... Réponse: votre demande concerne un serveur dédié ou un mutualisé ?
Re-aucun rapport avec la choucroute :-)
Exemple d'il y a environ 2 mois:
Question: le serveur FTP pour la sauvegarde de notre serveur xxxxx semble poser problème car le débit est d'environ 10 Go par heure la nuit (contre 150 Go / heure la journée). Par contre pour notre serveur yyyy le débit est normal dans les deux cas.
Réponse: 10Go / heure me semble une valeur correcte
C'est sûr que pour sauvegarder 1 To (quota du ftp), 10 Go de l'heure c'est correct puisqu'il ne faut que 4 jours :-)
[^] # Re: Forums OVH
Posté par Old Geek . Évalué à 2.
[^] # Re: Forums OVH
Posté par err404 (site web personnel) . Évalué à 2.
sinon, tu peux aussi nous donner le lien qui va bien vers le forum en question.
merci
[^] # Re: Forums OVH
Posté par Zenitram (site web personnel) . Évalué à 2.
http://forum.ovh.com/showpost.php?p=281068&postcount=4
[^] # Re: Forums OVH
Posté par Kerro . Évalué à 3.
[^] # Re: Forums OVH
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: Forums OVH
Posté par kowalsky . Évalué à 2.
[^] # Re: Forums OVH
Posté par Old Geek . Évalué à 1.
Voici le fil de discussion ouvert chez OVH,
http://forum.ovh.com/showthread.php?t=47720
Je vous donnerai la conclusion ici, quand cela sera réglé.
(c'est pas gagné lol !)
Nicolas.
[^] # Re: Forums OVH
Posté par Old Geek . Évalué à 2.
mais vu comme je me suis fait allumer là bas,
et que la solution a été trouvée très rapidement ici, ça laisse à réfléchir. Pour les problèmes basiques peut-être ...
MERCI à nicolasi , si tu as besoin de qq chose dis le moi,
je verrai ce que je peux faire. (matos, donc à une assoc, etc)
Nicolas.
# broadcast != flood
Posté par nicolasi . Évalué à 7.
Ca ressemble beaucoup à de l'unicast flooding.
En clair, quand le switch a une entrée dans ca table ARP correspondant à un quelconque serveur mais qu'il ne l'a pas dans sa table MAC, alors il flood sur tous ses ports appartenant au VLAN de ce serveur.
Ca arrive entre autre sur du traffic asymétrique (chemin différent à l'allée et au retour).
C'est du au fait que les tables MAC et ARP n'ont pas par défaut le même timeout.
http://www.cisco.com/en/US/products/hw/switches/ps700/produc(...)
La solution: initialiser le timeout des tables des différents switchs avec la même valeur.
Reste plus qu'à convaincre OVH... Bon courage ;)
Nicolas
[^] # Re: broadcast != flood
Posté par Kerro . Évalué à 2.
[^] # Re: broadcast != flood
Posté par Zenitram (site web personnel) . Évalué à 3.
Le problème existe que sur des machines avec deux cartes réseaux.
De ce que j'ai compris de l'explication d'OVH, le problème arrive effectivement quand elles sont mal configurées sur la machine d'en face, et envoient alors par une carte pour recevoir par une autre.
Donc l'explication se tient non?
[^] # Re: broadcast != flood
Posté par Old Geek . Évalué à 1.
(cela n'arrive que sur les serveurs ayant 2 cartes réseaux)
[^] # Re: broadcast != flood
Posté par nicolasi . Évalué à 1.
[^] # Re: broadcast != flood
Posté par nicolasi . Évalué à 6.
Je vais essayé de faire un petit schéma en espérant que ça passera bien:
serveur1 ----- switch1 ------------------
| |
| |
Rocade Routeur -------- WAN
| |
| |
serveur2 ----- switch2 ------------------
tu essaies de joindre le serveur 2, sauf que switch1 est mettre VRRP sur ce VLAN donc ca part vers lui, ca passe par la rocade pour aboutir au serveur2.
Le retour, par contre, est directe: serveur2 - switch2 - routeur - WAN
Le problème c'est que les entrées de la table mac (faisant le lien entre @MAC et port du switch) disparaissent (timeout) beaucoup plus vite que celles de la table ARP (@MAC - @IP).
Et donc parfois, si le switch1 recoit un paquet a destination de serveur2 il a encore dans sa table ARP mais pas dans sa table MAC.
Il n'envoie pas de requete ARP, ca servirait à rien vu qu'il l'a toujours l'entrée dans sa table ARP, mais il ne sait pas par quelle interface balancer le paquet: méthode bourrin: il flood sur toutes les interfaces, y compris la rocade et donc serveur2 obtient bien son paquet. Par contre, serveur1 (qui est dans le même VLAN) l'a également reçu.
C'est assez effrayant qu'OVH dise que c'est "normal" qu'un client reçoive des paquets (peut-être confidentiel) d'un autre client...
Nicolas
[^] # Re: broadcast != flood
Posté par Old Geek . Évalué à 1.
schéma réseau !
[^] # Re: broadcast != flood
Posté par nicolasi . Évalué à 2.
Quant au fait que tu reçoives beaucoup de paquets, c'est normal aussi :) ç'est parce que ça floodera tant que l'entrée sera présente dans la table ARP du switch (mais pas dans sa table MAC).
Pour Info, sur Cisco, c'est (de mémoire):
timeout table ARP: 4 heures
timeout table MAC: 5 minutes ...
normalement si tu ping le flooder, ça devrait s'arrêter (temporairement...)
Bon courage, je sais pas s'ils vont être très chaud pour modifier tous leurs switchs aussi facilement... mais normalement c est sans danger
Nicolas
[^] # Re: broadcast != flood
Posté par Old Geek . Évalué à 1.
pas top de laisser la config en l'état (je vois aussi passer les petits malins qui scannent le réseau ovh lol, et un serveur torrent assez consommateur, genre laisser un ping dans ma crontab vers lui lol)
mais en effet je ne pense pas qu'ils feront la bascule :( , ok pour donner le lien forum ovh vers linuxfr ?
[^] # Re: broadcast != flood
Posté par nicolasi . Évalué à 1.
[^] # Re: broadcast != flood
Posté par Old Geek . Évalué à 1.
bravo ;) et merci.
[^] # Re: broadcast != flood
Posté par Old Geek . Évalué à 3.
Diffamation en publique avec des faux pseudos de la part de l'opérateur,
dénigrement du client,
Modification des configs en cachette pour corriger le problème !
Comment jugez-vous ces méthodes ?
J'aurais au moins appris ce qu'est l'unicast flooding.
Nicolas
PS: il y aura encore quelques épisodes, mais plus sur le forum OVH
[^] # Re: broadcast != flood
Posté par Kerro . Évalué à 2.
Problème: les autres prestataires sont aussi nuls, sauf à payer le triple. Alors bon, on s'y fait. je ne paye pas le triple et régulièrement notre VPN saute car les paquets UDP ne passent plus certains routeurs. Ce matin même nous avons eu un filtrage de paquets UDP en dessous d'une taille donnée. Toute la signalisation d'OpenVPN était par terre.
Je ne contacte plus le support technique lorsque ces problèmes arrivent car leur seule réponse est "c'est normal". Si tu insistes ils demandent "des preuves".
OVH reste le moins cher, et de loin. Je fais avec.
[^] # Re: broadcast != flood
Posté par LoupArtic . Évalué à -5.
Le forum est un forum d'entraide pour usagers, pas pour du support. Si tu es pas content des usagers qui félicitent certains du staff pour les avoir dépanné alors qu'ils n'en étaient pas obligés, tu es un bon.
Il est vrai que le support en première ligne n'est vraiment pas top, on dirait Free des fois, heureusement qu'en housing c'est autre chose.
Qu'il y ait un problème c'est bien possible.
A vous lire, on remarque bien un problème clair de configuration et oui OVH est assez bouché de ce côté la.
Donc tant que personne ne montre clairement qu'il a prit le control total d'un serveur grace à ce problème, ils feront rien.
Et c'est peut-être bien dommage.
Par contre, quand dans le sujet bizarrement ya eu mass nouveaux profils qui se prennent pour des dieux du réseau et de l'informatique, incendie OVH et le peu de staff présent bénévolement sur le forum, ca énerve vite du monde.
Faut pas s'étonner qu'il soit très très vite partit n'importe comment.
Vous avez qu'a louer vos emplacements directement dans le DC, ovh fera un routage très simple et à vous de configurer vos switchs avec vos options. Hein Kerro :).
[^] # Re: broadcast != flood
Posté par Kerro . Évalué à 4.
Il est vrai que le support en première ligne n'est vraiment pas top
on remarque bien un problème clair de configuration et oui OVH est assez bouché de ce côté la
tant que personne ne montre clairement qu'il a prit le control total d'un serveur grace à ce problème, ils feront rien
C'est vrai que ça respire la qualité :-)
[^] # Re: broadcast != flood
Posté par galactikboulay . Évalué à 3.
J'ai déjà vu le cas en réel aussi, mais en ayant la chance d'avoir accès aux switches pour tout vérifier (genre pas de remplissage de la table de MAC addresses, ...), c'était exactement le phénomène que tu décris.
[^] # Re: broadcast != flood
Posté par Kerro . Évalué à 2.
J'envoie une demande de connexion pour mon.serveur.com
mon.serveur.com = 1.1.1.1
la réponse revient depuis 2.2.2.2 (qui est la seconde interface de mon.serveur.com)
--> la connexion ne se fait pas
[^] # Re: broadcast != flood
Posté par briaeros007 . Évalué à 2.
Et non!
Ils ont une mac différente, mais l'adresse IP est la bonne.
En gros, la table de routage dis juste "tout les paquets en sorties passent par eth0", plutot que "les paquets en sortie ayant l'ip X passent par eth0, et ceux ayant l'ip Y passent par eth1".
la carte réseau fait ce pourquoi elle est concu : elle encapsule des données couche 3 et + (donc ip etc...) dans de l'ethernet.
[^] # Re: broadcast != flood
Posté par Kerro . Évalué à 2.
Ensuite les deux cartes réseau sont sensées être connectées à des équipements différents afin d'assurer la redondance. Si les routeurs sont correctement configurés, ils ne laisseront pas sortir des adresses IP qui ne font pas partie de leur sous-réseau.
Lorsque que je fais sortir une adresse MAC incorrecte (depuis une machine virtuelle), je suis blacklisté pendant plusieurs minutes sur cette carte réseau. Je n'ai pas testé en faisant sortir un adresse IP modifiée.
Bref, je ne suis pas convaincu :-)
[^] # Re: broadcast != flood
Posté par briaeros007 . Évalué à 2.
1°) normalement les acl au niveau des switchs, c'est plus une mac sur un port, qu'une correspondance mac/ip (le switchs ne comprennent pas forcément l'IP).
Et les acl niveau routeurs, c'est souvent "sous réseau sur tel brin", que l'allocation précise.
2°) tu peux avoir plusieurs ips sur ovh, que tu peux attribuer _comme tu veux_ a tes deux interfaces (si tu en as deux) si je ne m'abuse.
Pour chaque nouvelle ip ils s'amusent à mettre à jour, à chaque fois , tous les switchs/routeurs du path ?
dans leur guide, aucun avertissement qu'il faut imperativement la mettre sur la bonne interface http://guides.ovh.net/AjouterAliasIp, mieux ils indiquent que la route par défaut est sur une interface précise si je ne m'abuse pas (regarde HG) (ce qui est à l'origine du problème)
3°) tu peux avoir des VIP, idem que plus haut.
Ensuite les deux cartes réseau sont sensées être connectées à des équipements différents afin d'assurer la redondance. Si les routeurs sont correctement configurés, ils ne laisseront pas sortir des adresses IP qui ne font pas partie de leur sous-réseau.
Ca se contredit :
Si un des switchs tombent, alors tu perd la moitié de ta connectivité (vu que ton ip ne peut pas etre routé).
Si tu utilise une ip en VIP, tu peux pas la migrer...
etc...
Normalement tu attribues plutôt un vlan par client, comme ça tu es sur qu'il risque pas de faire mumuse avec les autres clients. Bon si tu as beaucoup de client ça peut devenir compliqué parce que tu as un nombre limite de vlan (1024 ou 4096, je me souviens plus trop).
La vérification de "pas de spoofing" se fait ensuite à la sortie du vlan.
Ps on peut remarquer que "l'aide d'ovh" n'est pas bonne, vu qu'ils ont oublié dans leur conf de faire un "/sbin/ip route add default via ??? dev eth? table 127" , enfin moi je dis ça, je dis rien hein Xd
[^] # Re: broadcast != flood
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
de faire des alias d'interfaces type eth1:1 malgré les recommandation contraires.
Ex: http://fixunix.com/networking/11256-ip-addr-add-vs-interface(...)
Actually
aliases have inconsistent syntax and behaviour, exactly as you pointed.
Sometimes they behave like different device, sometimes like just one
another address. Anyway avoid them...
[^] # Re: broadcast != flood
Posté par Old Geek . Évalué à 1.
(paquets sortants par la même carte que par laquelle ils sont entrés),
je n'ai plus vu ses données passer par le réseau.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.