Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Au secours, mon réseau fuit … que faire ?

Au secours, mon réseau fuit … que faire ?
2014-05-192016-08-10sécurité des réseauxfr
Dans un post précédent, je montrais combien il était facile de faire un réseau avec des fuites. Il suffit pour cela d'avoir plus d'un point de routage.
Publié le 19 Mai 2014 par Pascal Bonnard dans sécurité des réseaux
au secours, mon réseau fuit … que faire ?

Dans un post précédent, je montrais combien il était facile de faire un réseau avec des fuites. Il suffit pour cela d'avoir plus d'un point de routage.

Un réseau avec des fuites présente quelques inconvénients. Il n'y pas de confidentialité des données. C'est un réseau avec un "Man In The Middle" intégré !  En plus, ces fuites consomment de la bande passante. Sur un campus un peu développé, il peut y avoir plusieurs dizaines de switches, avec une toile d'araignée pour bien mailler le tout. Eh bien, cette toile d'araignée diffuse pour rien toutes ces fuites. Le réseau gaspille de la précieuse bande passante. Mais alors, que faire ?!

faire du routage symétrique …

La première idée qui vient à l'esprit, c'est d'instaurer un point de routage unique. Il faut y réfléchir à deux fois. En effet, il faudra que l'ensemble du trafic routé passe par ce point unique. Du coup, le réseau sera mal optimisé (pire qu'avec Spanning Tree, c'est dire …). Le point de routage unique est envisageable sur un réseau de taille modeste. C'est irréaliste sur un réseau complexe.

ARPer plus souvent ?

Et si on envoyait les ARP toutes les 290 secondes ? Le bail des mac@ sera ainsi constamment renouvelé avant son expiration (300 secondes). Comme cela, on aura des tables de mac@ bien à jour, et il n'y aura plus de fuites liées au routage asymétrique … Oui, mais il va y avoir beaucoup de ARP à diffuser un peu partout. En fait, 50 fois plus. Je connais plus d'un responsable réseau qui va hésiter à faire cela.

faire durer les mac@ ?

Bon, alors, il n'y a qu'à mettre 4 heures à la place de 5 minutes pour les tables de mac@... Cela fait peur aussi. En effet, à vue de nez, la taille des tables de mac@ va être au moins 48 fois plus grande ! Et si jamais les tables débordent, les conséquences sont encore pires.

choisir la voie du milieu …

Le plus raisonnable, c'est d'éviter les solutions extrêmes et de rechercher un compromis. En prenant des temporisations de l'ordre de 30 minutes, on arrive à des chiffres moins préoccupants : 8 fois plus de ARPs, et des tables de mac@ 6 fois plus grosses. En complément, on peut aussi réduire le nombre de ARPs en limitant le nombre de points de routage.

Le plus simple est de les associer 2 par 2 à l'aide de VRRP ou d'un protocole propriétaire équivalent.

Crédit photo : © ots-photo - Fotolia.com

5 Commentaires

  • 22 Mai 2014
    2014-05-22
    par
    Frd404
    D'accord! Là c'est beaucoup plus claire. En effet il me manquait une brique pour comprendre. Merci beaucoup pour l'explication. Bonne continuation.
  • 21 Mai 2014
    2014-05-22
    par

    @frd404. Je n'ai pas été suffisament précis. Je pense aux ARPs émis par les switches. Plus précisément, les "SVI", les interfaces L3 associées aux VLANs pour lesquels on veut faire du routage.

    Par exemple, pour les interfaces "vlan 14" et  "vlan 18", il faut configuer "arp timeout 290" pour la première solution. Du coup, les SVIs vont envoyer un ARP toutes les 290 secondes à chaque PC connecté, au lieu d'un ARP toutes les 4 heures.

    Pour les PC (ou les serveurs), cela se configure. A titre d'exemple, quand je sniffe mon PC à la maison, je vois que mon PC envoie un ARP toutes les 3 minutes, et qu'en plus les services microsoft ont plein de chose à dire. Le PC qui gère le groupe résidentiel ARPe toutes les secondes. Et la box elle-même ARP aussi les équipements connectés.

    Je vous remercie pour l'intéret que vous portez à mes articles.

    Pascal

  • 21 Mai 2014
    2014-05-22
    par
    Fredoo404
    Merci pour votre réponse. J'ai bien pigé le fonctionnement du réseau au niveau des équipements de niveau 2 et des requêtes ARP. Ce que je comprends pas c'est quand vous dites: "Et si on envoyait les ARP toutes les 290 secondes ? Le bail des mac@ sera ainsi constamment renouvelé avant son expiration (300 secondes). Comme cela, on aura des tables de mac@ bien à jour" Les requêtes ARP sont initié par des postes clients normalement, donc du coup comment dire "je veux qu'il y ait des requêtes ARP toutes les 290 secondes ?" J'ai toujours pensé que l'ARP ne se contrôlait pas, les postes client on en besoin à un moment donné, ils s'en servent et au passage les switchs enregistre la correspondance @mac source / port source de l’équipement. Je sais pas si vous voyer ce que je veux dire ^^ en tout cas merci pour la réponse et pour vos articles que je trouve très intéressant!
  • 20 Mai 2014
    2014-05-22
    par
    @Frd404 ... C'est très juste, quand le switch voit une trame, il fait une correspondance port+vlan source /@mac source. Cette information est stockée dans la table de commutation. Ici, dans une des directions, on n'a que des ARP, comme expliqué dans un post précédent. Pour ce qui concerne le niveau 2, les trames ARP contiennent une mac@ source et un vlan. Le switch s'en sert pour mettre à jour la table de commutation, comme d'habitude. Pour ce qui concerne le niveau 3, voir dans Wikipedia http://fr.wikipedia.org/wiki/Address_Resolution_Protocol Pascal.
  • 19 Mai 2014
    2014-05-22
    par
    Frd404
    Bonjour, J'aurais juste une petite question. Je ne comprends pas l'utilisation du mot ARP quand vous parlez de la table de commutation... Je suis pas forcément un spécialiste, mais l'alimentation de la table de commutation ne se fait pas via arp. Le switch va voir une trame et va faire une correspondance entre port source / @mac source. Je ne comprends pas ce que vient faire l'arp ici :/ Merci d'avance.

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage