Je crois que c'est une question qui concerne directement les opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien de spécifique à Free). Avis bienvenus.
http://www.bortzmeyer.org/que-pinguer.html ---------------------------- Lorsqu'on met en place une infrastructure de surveillance de serveurs Internet, il est agaçant de recevoir autant d'alarmes que de serveurs surveillés, alors que c'était simplement la connectivité Internet de la sonde de surveillance qui était en panne. Tous les grands logiciels de surveillance de réseau ont une option pour éviter cela, qui permet de dire que le test d'un serveur dépend du succès d'un test sur un autre composant, par exemple le routeur de sortie (si ce dernier est en panne, il n'y a pas besoin de tester les serveurs et d'alerter si ça rate). Mais quel composant tester pour déterminer qu'on a un accès Internet qui marche ? Avec les logiciels de la famille Nagios comme Icinga, l'option qui permet d'indiquer la dépendance d'un test envers un autre se nomme parents. Si on écrit : define host { host_name freebox address 192.168.1.1 } define host { host_name remote-host parents freebox ... } alors on déclare que le test de remote-host dépend de celui de freebox. Si on est connecté à l'Internet par ce seul routeur, c'est logique. Si freebox est injoignable, le reste de l'Internet l'est aussi. Mais si freebox fonctionne mais ne route plus <http://bugs.freeplayer.org/task/10258> ? Ou bien si quelque chose déconne dans le réseau de Free bloquant tout accès à l'extérieur ? C'est là qu'il est utile de tester autre chose que le premier routeur. On voudrait en fait tester si on a toujours un accès Internet et pouvoir écrire : define host { host_name remote-host parents Internet ... } Mais comment faire ce test ? En pinguant des machines distantes, bien évidemment. Il « suffit » de sélectionner des machines stables, qui répondent aux paquets ICMP d'écho, et qui n'ont elles-mêmes que très peu de pannes. Mais lesquelles choisir ? Il faut bien voir que ces machines sur l'Internet, ces amers ou mires <http://www.bortzmeyer.org/amer-mire.html> ("target" en anglais) ne nous appartiennent pas. Si chaque petit réseau local, pour tester sa connectivité, pingue 192.0.2.1 toutes les trois minutes, et qu'il y a dix millions de petits réseaux qui le font dans le monde, 192.0.2.1 recevra 50 000 paquets/seconde, ce qui est une charge sérieuse même pour un gros serveur. (En débit, cela ne fera pas grand'chose car les paquets de test seront de petite taille. Mais pour les routeurs et les serveurs, ce n'est pas que le nombre de bits par seconde qui compte, celui des paquets par seconde est également important, chaque paquet nécessitant un traitement, indépendemment de sa taille.) Utiliser le premier serveur qu'on a choisi pour des tests répétitifs, c'est comme jeter une canette vide par terre : si une seule personne le fait, c'est juste un peu agaçant, si tout le monde le fait, on détruit l'environnement. Ce n'est pas parce qu'un service est publiquement accessible qu'on peut le bombarder de requêtes pour son usage personnel. Dans le passé, il est déjà arrivé qu'un constructeur configure (bêtement) ses machines pour utiliser un serveur public sans autorisation, l'écroulant ainsi sous la charge <http://slashdot.org/story/06/04/07/130209/d-link-firmware-abuses-open-n tp-servers>. Qu'est-ce que cela nous laisse comme possibilités ? En posant la question, on obtient des réponses (plus ou moins dans l'ordre décroissant du nombre de suggestions) : * 8.8.8.8 (ou, à la rigueur, 8.8.4.4, qui est sans doute moins sollicité), à savoir Google Public DNS <http://www.bortzmeyer.org/google-dns.html>. Un service très fiable, qui a très peu de chances de tomber en panne. Mais peut-on l'utiliser ainsi, de manière automatique, dans des tests répétés ? Cela ne figure certainement pas dans les conditions d'utilisation de ce service, et Google pourrait donc décider de couper les réponses ICMP écho du jour au lendemain (ou de mettre en place une limitation de débit). * www.facebook.com (ou www.google.com) avec l'argument « Si Facebook est en panne, de toute façon, tout l'Internet est fichu ». Cela pose un peu les mêmes problèmes que précédemment. * Pinguer un des serveurs DNS de la racine. Ils marchent en permanence (c'est sans doute un des composants les plus robustes de l'Internet), répondent à l'ICMP écho et, n'étant pas gérés dans un but lucratif, on n'est pas à la merci d'un changement soudain de politique commerciale. Mais ces serveurs ne sont pas prévus pour un tel test automatisé. Ils y résisteront, bien sûr, mais est-ce un usage légitime ? Je ne pense pas et les opérateurs des serveurs racine, interrogés, sont également de cet avis. Il faut aussi se rappeler qu'il s'agit d'un service critique : toute perturbation est à éviter. * Pinguer des équipements du FAI par exemple son serveur Web ou bien les routeurs sur le trajet (après un traceroute pour les repérer). Notez que cela ne détecte pas le cas où la(es) liaison(s) du FAI avec l'Internet sont en panne. Mais la plupart des pannes (comme celle de la Freebox citée plus haut) concernent « le dernier kilomètre » donc c'est peut-être supportable. L'avantage est que tout le monde ne teste pas le même service (les abonnés d'un FAI sont les seuls à tester leur FAI) et que c'est un service qu'on paie. En tirant un peu sur la ficelle, on peut considérer que l'abonnement inclut le droit de pinguer www.mon-FAI.net chaque minute. Les FAI ne sont pas forcément d'accord avec cette analyse, et peuvent faire remarquer que les routeurs sont là pour router, pas pour répondre aux pings. Bref, le débat n'est pas simple. On peut encore le compliquer avec des questions comme « Vaut-il mieux utiliser les paquets ICMP echo de ping ou bien une application comme HTTP ou DNS ? ». Merci à WBrown pour ses bonnes suggestions sur le pinguage du FAI. À noter qu'il n'existe pas de « service public » de mires accessibles pour ce genre de tests mais que le RIPE-NCC a un projet qui s'en rapproche <https://labs.ripe.net/Members/dfk/ripe-atlas-anchors>. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
