J’ai un serveur chez Ovh depuis des années, et dernièrement étant cibles de joyeux pirates, j’ai installé des sondes sur mon serveur pour les surveiller.
Du coup, je suis tombé sur la supervision d’OVH….
===========================================
# of from to method
===========================================
5736 167.114.37.1 91.121.150.200 ICMP PING
5736 92.222.185.1 91.121.150.200 ICMP PING
5736 92.222.186.1 91.121.150.200 ICMP PING
5735 92.222.184.1 91.121.150.200 ICMP PING
En faisant un petit scan des IPs, on se rend compte que la supervision de chaque DC ping mon serveur :
[email protected]:~# dig +noall +answer -x 167.114.37.1
1.37.114.167.in-addr.arpa. 86369 IN PTR netmon-1-bhs.ovh.ca.
[email protected]:~# dig +noall +answer -x 92.222.184.1
1.184.222.92.in-addr.arpa. 86400 IN PTR netmon-1-rbx.ovh.net.
[email protected]:~# dig +noall +answer -x 92.222.185.1
1.185.222.92.in-addr.arpa. 86400 IN PTR netmon-1-sbg.ovh.net.
[email protected]:~# dig +noall +answer -x 92.222.186.1
1.186.222.92.in-addr.arpa. 86400 IN PTR netmon-1-gra.ovh.net.
Ils l’utilisent certainement pour avoir des infos sur la qualité des liens inter-DC.
Du coup, j’ai posé la question à OVH sans réponses techniques :
@ovh_fr est-ce que l’on a accès au stats de monitoring de vos sondes sur nos serveurs?? (icmp depuis les /24 de supp de chaque datacenter)
— Johan Denoyer (@jdenoy) 2 Octobre 2015
@jdenoy Bjr, Pourquoi souhaite tu avoir cette infos ? trop de requêtes ? Tu peux nous DM si tu veux Cdlt ^RomC — OVH Support FR (@ovh_support_fr) 6 Octobre 2015
Du coup, je suis partis sur une idée de faire la même chose qu’OVH en inverse pour voir ce que ca donne. J’ai fait un traceroute de chaque IP, et ca donne ca :
traceroute [(91.121.150.200:33456) -> (167.114.37.1:33457)], protocol udp, algo hopbyhop, duration 21 s
1 rbx1-3a-a9.fr.eu (91.121.150.252) 5.988 ms 5.547 ms 3.235 ms
2 10.21.50.250 (10.21.50.250) 1.235 ms 1.328 ms 1.284 ms
3 * * *
4 10.21.51.10 (10.21.51.10) 83.031 ms 81.707 ms 81.849 ms
5 * * *
6 * * *
7 * * *traceroute [(91.121.150.200:33456) -> (92.222.184.1:33457)], protocol udp, algo hopbyhop, duration 15 s
1 rbx1-3a-a9.fr.eu (91.121.150.252) 3.008 ms 1.270 ms 5.892 ms
2 10.21.50.40 (10.21.50.40) 1.033 ms 1.276 ms 1.837 ms
3 * * *
4 * * *
5 * * *traceroute [(91.121.150.200:33456) -> (92.222.185.1:33457)], protocol udp, algo hopbyhop, duration 16 s
1 rbx1-3a-a9.fr.eu (91.121.150.252) 1.282 ms 1.349 ms 6.499 ms
2 10.21.50.250 (10.21.50.250) 1.302 ms 1.313 ms 1.863 ms
3 10.21.57.250 (10.21.57.250) 10.323 ms 10.096 ms 10.246 ms
MPLS Label 20359 TTL=255
4 10.21.57.6 (10.21.57.6) 10.184 ms 10.116 ms 10.152 ms
5 * * *
6 * * *
7 * * *traceroute [(91.121.150.200:33456) -> (92.222.186.1:33457)], protocol udp, algo hopbyhop, duration 21 s
1 rbx1-3a-a9.fr.eu (91.121.150.252) 2.711 ms 4.601 ms 1.389 ms
2 10.21.50.250 (10.21.50.250) 1.239 ms 1.336 ms 1.346 ms
3 * * *
4 10.21.148.6 (10.21.148.6) 7.878 ms 7.395 ms 7.431 ms
5 * * *
6 * * *
7 * * *
Du coup, vu que le traceroute ne passe pas, on peut imaginer que ca rentre dans une VRF MPLS chez OVH avec probablement un firewall qui nous interdis de faire la même chose dans l’autre sens.
D’ailleurs on le vois dans le traceroute vers 92.222.185.1, il y a un label MPLS dans la réponse à l’ICMP… (quelqu’un a oublié de désactiver la réponse ICMP sur un P 😉 )