Pour t'exposer ce que j'ai fait pour monitorer des accès internet sur différents accès :
sur accès internet où j'ai un proxy sortant, je fais deux checks : - internet_www - internet_dns le check internet_www est un check_http vers www.google.fr le check internet_dns est un check_tcp(53) vers 8.8.4.4 ou 8.8.8.8 Le but étant de tester le service, j'ai jugé le ping pas représentatif. Si l'un de ces checks échoue, le cache_peer de DMZ est désactivé ce qui permet au proxies d'utilisateur de ne plus être dirigé sur ce proxy dont l'accès internet est défaillant, mais d'être routés systématiquement vers les autres accès internet. En retour d'expérience sur ces tests, un seul faux positif dans les 2 dernieres années (pb d'infra chez google, qui avait été rapidement réparé) Par contre c'est bien pratique car ça permet de mesurer un peu la qualité de l'accès internet, et chez certains opérateurs il reste du boulot... A+ 2012/9/5 Stephane Bortzmeyer <bortzme...@nic.fr>: > 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/ -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB <ste...@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
