traceroute / iptables

Le
Philippe Gras
Bonjour à toutes et à tous,

1). comme je viens de découvrir traceroute, je l'ai essayé sur mon =
serveur :

# traceroute google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
send: Opération non permise

# traceroute avoirun.com
traceroute to avoirun.com (5.135.191.38), 30 hops max, 60 byte packets
1 XXXX.kimsufi.com (5.135.191.38) 0.094 ms 0.053 ms 0.051 ms

Logique, c'est chez moi :-)

# iptables -n -v -L
Chain INPUT (policy DROP 1224 packets, 71793 bytes)
…
59085 4236K ACCEPT udp -- * * 0.0.0.0/0 =
0.0.0.0/0 udp dpt:53
…
Chain OUTPUT (policy DROP 2077 packets, 274K bytes)
…
1357K 108M ACCEPT udp -- * * 0.0.0.0/0 =
0.0.0.0/0 udp dpt:53
39257 2984K ACCEPT udp -- * * 0.0.0.0/0 =
0.0.0.0/0 udp dpt:123
…

Par contre, quand je fais traceroute -I, tout se passe bien :-)
# traceroute -I google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.684 ms 0.699 ms 0.872 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 3.461 ms 3.501 ms 5.102 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.288 ms 4.548 ms 4.578 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 4.525 ms 4.536 ms 4.553 ms
6 209.85.245.83 (209.85.245.83) 11.334 ms 7.894 ms 7.696 ms
7 209.85.245.236 (209.85.245.236) 20.138 ms 19.948 ms 20.148 ms
8 216.239.50.135 (216.239.50.135) 19.560 ms 19.598 ms 19.603 ms
9 mad01s25-in-f14.1e100.net (216.58.211.206) 20.056 ms 20.065 ms =
20.068 ms

# traceroute -I cloudflare.net
traceroute to cloudflare.net (104.20.36.89), 30 hops max, 60 byte =
packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.674 ms 0.950 ms 1.001 ms
2 rbx-g2-a9.fr.eu (178.33.100.219) 0.869 ms 0.920 ms 0.928 ms
3 ams-5-a9.nl.eu (94.23.122.79) 8.649 ms 8.680 ms 8.695 ms
4 80.249.211.140 (80.249.211.140) 9.108 ms 9.134 ms 9.147 ms
5 104.20.36.89 (104.20.36.89) 9.206 ms 9.158 ms 9.227 ms

Où ai-je merdé dans ma configuration iptables ?

2). Ci-dessus, je vois que mon serveur est à 5 sauts de Cloudflare, =
mais à 9 sauts de
Google. C'est par ailleurs marrant quand je compare avec Google VF :

# traceroute -I google.fr
traceroute to google.fr (216.58.211.195), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.650 ms 0.925 ms 0.974 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 0.936 ms 0.955 ms 0.966 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.044 ms 4.073 ms 4.088 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 7.014 ms 7.028 ms 7.040 ms
6 209.85.245.83 (209.85.245.83) 4.815 ms 13.509 ms 13.451 ms
7 209.85.245.236 (209.85.245.236) 20.128 ms 20.187 ms 20.139 ms
8 216.239.50.135 (216.239.50.135) 19.718 ms 19.463 ms 19.586 ms
9 mad01s25-in-f195.1e100.net (216.58.211.195) 20.023 ms 20.036 ms =
19.944 ms

Ça veut dire que google.{com | fr } est au même endroit (Mountain =
View ?) ;-)

Existe-t-il un outil qui permette de choisir ses routes en fonction d'un =
algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?

D'avance merci,

Ph. Gras=
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
fra-duf-no-spam
Le #26378569
Le 16756ième jour après Epoch,
Philippe Gras écrivait:

Bonjour à toutes et à tous,



Bonjour.


1). comme je viens de découvrir traceroute, je l'ai essayé sur mon serveur :

# traceroute google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
send: Opération non permise



[...]

Chain OUTPUT (policy DROP 2077 packets, 274K bytes)
…
1357K 108M ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:53
39257 2984K ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:123



[...]

Où ai-je merdé dans ma configuration iptables ?



Merdé n'est pas vraiment le mot. Tu n'autorise que 2 ports UDP en
sortie, et traceroute va par défaut incrémenter les ports UDP à   chaque
test. Donc en général ça n'a pas le droit de sortir du coup.

Essaye avec -U ou -UL pour forcer en UDP port 53

2). Ci-dessus, je vois que mon serveur est à 5 sauts de Cloudflare, mais à 9 sauts de
Google. C'est par ailleurs marrant quand je compare avec Google VF :

# traceroute -I google.fr
traceroute to google.fr (216.58.211.195), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.650 ms 0.925 ms 0.974 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 0.936 ms 0.955 ms 0.966 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.044 ms 4.073 ms 4.088 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 7.014 ms 7.028 ms 7.040 ms
6 209.85.245.83 (209.85.245.83) 4.815 ms 13.509 ms 13.451 ms
7 209.85.245.236 (209.85.245.236) 20.128 ms 20.187 ms 20.139 ms
8 216.239.50.135 (216.239.50.135) 19.718 ms 19.463 ms 19.586 ms
9 mad01s25-in-f195.1e100.net (216.58.211.195) 20.023 ms 20.036 ms 19 .944 ms

Ça veut dire que google.{com | fr } est au même endroit (Mounta in View
?) ;-)



C'est quoi google? :-P

Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?



À moins de tirer assez fort le câble RJ45 pour rapprocher google de chez
toi, les routes sont choisies à chaque noeud, selon pas mal de crità ¨res
comme la charge machine, l'encombrement de ligne, etc...

Tu ne peux en général pas forcer une route particulière.
Philippe Gras
Le #26378582
Le 17 nov. 2015 à 18:26, (François TOURDE) a écrit :

Le 16756ième jour après Epoch,
Philippe Gras écrivait:

[...]

Où ai-je merdé dans ma configuration iptables ?



Merdé n'est pas vraiment le mot. Tu n'autorise que 2 ports UDP en
sortie, et traceroute va par défaut incrémenter les ports UDP à chaque
test. Donc en général ça n'a pas le droit de sortir du coup.

Essaye avec -U ou -UL pour forcer en UDP port 53



Ça fonctionne, en effet. Ça fonctionne aussi avec -T accessoirement.

Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.

Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?


Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?



À moins de tirer assez fort le câble RJ45 pour rapprocher google de chez
toi, les routes sont choisies à chaque noeud, selon pas mal de critères
comme la charge machine, l'encombrement de ligne, etc…



Là :
http://docs.oracle.com/cd/E37927_01/html/E36455/ipv6-admintasks-72.html

On indique une commande qui propose des routes différentes.

Par contre, ça ne fonctionne pas :-(

# traceroute -a google.com
Bad option `-a' (argc 1)
# traceroute -a v6host.remote.com
Bad option `-a' (argc 1)
# traceroute -a -U google.com
Bad option `-a' (argc 1)

C'est bidon ? Pourtant à mon domicile, ça fonctionne :

$ traceroute -a -I google.com
traceroute: Warning: google.com has multiple addresses; using 173.194.67.138
traceroute to google.com (173.194.67.138), 64 hops max, 72 byte packets
1 [AS0] net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 20.275 ms 19.461 ms 20.450 ms
2 [AS0] 10.123.183.74 (10.123.183.74) 17.503 ms 23.307 ms 17.473 ms
3 [AS0] ae20-0.ncidf104.paris.francetelecom.net (193.253.80.122) 17.437 ms 17.673 ms 17.382 ms
4 [AS0] ae44-0.niaub102.aubervilliers.francetelecom.net (193.252.159.46) 16.232 ms 18.185 ms 17.923 ms
5 [AS0] 81.253.184.34 (81.253.184.34) 29.592 ms 28.185 ms 27.736 ms
6 [AS5511] tengige0-8-0-12.lontr4.london.opentransit.net (193.251.133.167) 32.194 ms 31.852 ms 31.558 ms
7 [AS5511] google-5.gw.opentransit.net (193.251.254.182) 27.798 ms 27.889 ms 29.091 ms
8 [AS15169] 72.14.235.75 (72.14.235.75) 29.027 ms 30.260 ms 30.062 ms
9 [AS15169] 66.249.94.186 (66.249.94.186) 29.778 ms 29.811 ms 29.771 ms
10 [AS15169] 216.239.42.37 (216.239.42.37) 29.023 ms 29.074 ms 29.063 ms
11 [AS15169] 209.85.250.165 (209.85.250.165) 29.527 ms 28.794 ms 29.536 ms
12 * * *
13 [AS15169] wi-in-f138.1e100.net (173.194.67.138) 29.611 ms 30.146 ms 29.519 ms

(À la réflexion, ça ne donne pas les résultats que j'escomptais…)

Tu ne peux en général pas forcer une route particulière.





Il y aurait donc des cas particuliers :-) faisant exception au cas général ?

Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suffirait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie…) de venir se
brancher chez lui :-)=
fra-duf-no-spam
Le #26378600
Le 16756ième jour après Epoch,
Philippe Gras écrivait:

Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.

Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?



traceroute est fait de telle sorte que par défaut, il va utiliser des
ports UDP différents à chaque fois. C'est un choix de constructio n.

Ton firewall n'autorise en sortie que le port 53 et le port xxx (je me
souviens plus), donc ça bloque. C'est la raison.

Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suff irait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie†¦) de venir se
brancher chez lui :-)



Ben voilà, t'as qu'a leur demander ;) ... Bon courage.

D'un autre côté, au vu de tes temps de réponse, tu dois à ªtre en fibre
avec des accès gravement rapides, donc tu risques de gagner une ou deux
millisecondes de temps de réponse, tu vas pas trop le sentir.
Bernard Schoenacker
Le #26378601
Le Tue, 17 Nov 2015 19:43:55 +0100,
Philippe Gras
traceroute -a v6host.remote.com



bonjour,

serait il possible de vérifier les versionsde traceroute installées ?

rmadison traceroute -a amd64
traceroute | 1:2.0.15-1 | oldoldstable | amd64
traceroute | 1:2.0.18-3 | oldstable | amd64
traceroute | 1:2.0.20-2+b1 | stable | amd64
traceroute | 1:2.0.21-1 | testing | amd64
traceroute | 1:2.0.21-1 | unstable | amd64

rmadison traceroute -a i386
traceroute | 1:2.0.15-1 | oldoldstable | i386
traceroute | 1:2.0.18-3 | oldstable | i386
traceroute | 1:2.0.20-2+b1 | stable | i386
traceroute | 1:2.0.21-1 | testing | i386
traceroute | 1:2.0.21-1 | unstable | i386


que donne : apt-cache policy traceroute

traceroute:
Installé : 1:2.0.21-1
Candidat : 1:2.0.21-1
Table de version :
*** 1:2.0.21-1 100
100 /var/lib/dpkg/status
1:2.0.20-2+b1 500
500 http://ftp.fr.debian.org/debian jessie/main i386 Packages


dpkg -l |awk /traceroute/ {print $2 " "$3}'

attention (l'option -a n'est plus acceptée) :

traceroute -a -I google.com
Bad option `-a' (argc 1)


regarde si l'un n'utiliserai pas : paris-traceroute


autrement, traceroute est passé de man(8) à man(1) avec les changements

documentation :

http://www.linuxcertif.com/man/1/traceroute/

http://linux.die.net/man/8/traceroute


slt
bernard
honeyshell
Le #26378602
Tu ne peux en général pas forcer une route particulière.



louer un serveur virtuel à Montain View? => https://cloud.google.com /
Philippe Gras
Le #26378607
Le 17 nov. 2015 à 23:16, Bernard Schoenacker
Le Tue, 17 Nov 2015 19:43:55 +0100,
Philippe Gras
traceroute -a v6host.remote.com



bonjour,

serait il possible de vérifier les versionsde traceroute installées ?

rmadison traceroute -a amd64
traceroute | 1:2.0.15-1 | oldoldstable | amd64
traceroute | 1:2.0.18-3 | oldstable | amd64
traceroute | 1:2.0.20-2+b1 | stable | amd64
traceroute | 1:2.0.21-1 | testing | amd64
traceroute | 1:2.0.21-1 | unstable | amd64

rmadison traceroute -a i386
traceroute | 1:2.0.15-1 | oldoldstable | i386
traceroute | 1:2.0.18-3 | oldstable | i386
traceroute | 1:2.0.20-2+b1 | stable | i386
traceroute | 1:2.0.21-1 | testing | i386
traceroute | 1:2.0.21-1 | unstable | i386


que donne : apt-cache policy traceroute

traceroute:
Installé : 1:2.0.21-1
Candidat : 1:2.0.21-1
Table de version :
*** 1:2.0.21-1 100
100 /var/lib/dpkg/status
1:2.0.20-2+b1 500
500 http://ftp.fr.debian.org/debian jessie/main i386 Packages



# apt-cache policy traceroute
traceroute:
Installé : 1:2.0.18-3
Candidat : 1:2.0.18-3
Table de version :
*** 1:2.0.18-3 0
500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status



dpkg -l |awk /traceroute/ {print $2 " "$3}'

attention (l'option -a n'est plus acceptée) :

traceroute -a -I google.com
Bad option `-a' (argc 1)



Usage:
traceroute [ -46dFITnreAUV ] [ -f first_ttl ] [ -g gate,... ] [ -i device ] [ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l flow_label ] [ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z sendwait ] [ --fwmark=num ] host [ packetlen ]

Quand j'ai relu l'article, je me suis aperçu que j'avais zappé des infos, notamment
en ce qui concerne l'ipv6, auquel je n'ai pas touché sur mon serveur :
http://docs.oracle.com/cd/E37927_01/html/E36455/ipv6-admintasks-72.html

Par contre, ça fonctionne bien chez moi et ça donne juste les infos sur les AS :
$ traceroute -a -I google.com
traceroute: Warning: google.com has multiple addresses; using 74.125.133.138
traceroute to google.com (74.125.133.138), 64 hops max, 72 byte packets
1 [AS0] net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 21.279 ms 20.290 ms 18.497 ms
2 [AS0] 10.123.183.78 (10.123.183.78) 17.939 ms 17.067 ms 17.973 ms
3 [AS0] ae20-0.ncidf104.paris.francetelecom.net (193.253.80.122) 16.968 ms 22.634 ms 17.476 ms
4 [AS0] ae44-0.niaub102.aubervilliers.francetelecom.net (193.252.159.46) 16.959 ms 18.593 ms 17.556 ms
5 [AS0] 81.253.184.122 (81.253.184.122) 30.076 ms 30.269 ms 27.852 ms
6 [AS5511] tengige0-11-0-8.lontr4.london.opentransit.net (193.251.131.203) 28.546 ms 28.653 ms 31.546 ms
7 [AS15169] 72.14.210.106 (72.14.210.106) 28.538 ms 28.062 ms 28.553 ms
8 [AS15169] 72.14.237.59 (72.14.237.59) 55.942 ms 29.774 ms 28.569 ms
9 [AS15169] 209.85.250.140 (209.85.250.140) 29.546 ms 29.554 ms 29.542 ms
10 [AS15169] 209.85.253.108 (209.85.253.108) 30.528 ms 29.376 ms 29.778 ms
11 [AS15169] 209.85.249.14 (209.85.249.14) 29.069 ms * 29.549 ms
12 * * *
13 [AS15169] wo-in-f138.1e100.net (74.125.133.138) 28.522 ms 29.302 ms 28.229 ms

$ traceroute
Version 1.4a12+Darwin
Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface]
[-M first_ttl] [-m max_ttl] [-p port] [-P proto] [-q nqueries] [-s src_addr]
[-t tos] [-w waittime] [-z pausemsecs] host [packetlen]

Bon, j'ai regardé à qui ça correspondait sur un site :
http://bgp.he.net/AS5511

Alors, c'est très intéressant parce qu'on voit qui est connecté avec qui et on peut en déduire
un peu comment tout ça fonctionne commercialement.

Pour le fond de ma question, en fait tout cela m'amène au protocole BGP (cf. le nom du site).

regarde si l'un n'utiliserai pas : paris-traceroute

Je suppose que non, mais ça a l'air intéressant :
http://www.paris-traceroute.net



autrement, traceroute est passé de man(8) à man(1) avec les changements

documentation :

http://www.linuxcertif.com/man/1/traceroute/

http://linux.die.net/man/8/traceroute


slt
bernard

Bernard Schoenacker
Le #26378606
Le Wed, 18 Nov 2015 00:44:53 +0100,
Philippe Gras
Le 17 nov. 2015 à 23:16, Bernard Schoenacker

> Le Tue, 17 Nov 2015 19:43:55 +0100,
> Philippe Gras >
>> traceroute -a v6host.remote.com
>
> bonjour,
>
> serait il possible de vérifier les versionsde traceroute
> installées ?
>
> rmadison traceroute -a amd64
> traceroute | 1:2.0.15-1 | oldoldstable | amd64
> traceroute | 1:2.0.18-3 | oldstable | amd64
> traceroute | 1:2.0.20-2+b1 | stable | amd64
> traceroute | 1:2.0.21-1 | testing | amd64
> traceroute | 1:2.0.21-1 | unstable | amd64
>
> rmadison traceroute -a i386
> traceroute | 1:2.0.15-1 | oldoldstable | i386
> traceroute | 1:2.0.18-3 | oldstable | i386
> traceroute | 1:2.0.20-2+b1 | stable | i386
> traceroute | 1:2.0.21-1 | testing | i386
> traceroute | 1:2.0.21-1 | unstable | i386
>
>
> que donne : apt-cache policy traceroute
>
> traceroute:
> Installé : 1:2.0.21-1
> Candidat : 1:2.0.21-1
> Table de version :
> *** 1:2.0.21-1 100
> 100 /var/lib/dpkg/status
> 1:2.0.20-2+b1 500
> 500 http://ftp.fr.debian.org/debian jessie/main i386
> Packages

# apt-cache policy traceroute
traceroute:
Installé : 1:2.0.18-3
Candidat : 1:2.0.18-3
Table de version :
*** 1:2.0.18-3 0
500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64
Packages 100 /var/lib/dpkg/status

>
>
> dpkg -l |awk /traceroute/ {print $2 " "$3}'
>
> attention (l'option -a n'est plus acceptée) :
>
> traceroute -a -I google.com
> Bad option `-a' (argc 1)

Usage:
traceroute [ -46dFITnreAUV ] [ -f first_ttl ] [ -g gate,... ] [ -i
device ] [ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l
flow_label ] [ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z
sendwait ] [ --fwmark=num ] host [ packetlen ]

Quand j'ai relu l'article, je me suis aperçu que j'avais zappé des
infos, notamment en ce qui concerne l'ipv6, auquel je n'ai pas touché
sur mon serveur :
http://docs.oracle.com/cd/E37927_01/html/E36455/ipv6-admintasks-72.html

Par contre, ça fonctionne bien chez moi et ça donne juste les infos
sur les AS : $ traceroute -a -I google.com
traceroute: Warning: google.com has multiple addresses; using
74.125.133.138 traceroute to google.com (74.125.133.138), 64 hops
max, 72 byte packets 1 [AS0]
net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 21.279
ms 20.290 ms 18.497 ms 2 [AS0] 10.123.183.78 (10.123.183.78)
17.939 ms 17.067 ms 17.973 ms 3 [AS0]
ae20-0.ncidf104.paris.francetelecom.net (193.253.80.122) 16.968 ms
22.634 ms 17.476 ms 4 [AS0]
ae44-0.niaub102.aubervilliers.francetelecom.net (193.252.159.46)
16.959 ms 18.593 ms 17.556 ms 5 [AS0] 81.253.184.122
(81.253.184.122) 30.076 ms 30.269 ms 27.852 ms 6 [AS5511]
tengige0-11-0-8.lontr4.london.opentransit.net (193.251.131.203)
28.546 ms 28.653 ms 31.546 ms 7 [AS15169] 72.14.210.106
(72.14.210.106) 28.538 ms 28.062 ms 28.553 ms 8 [AS15169]
72.14.237.59 (72.14.237.59) 55.942 ms 29.774 ms 28.569 ms 9
[AS15169] 209.85.250.140 (209.85.250.140) 29.546 ms 29.554 ms
29.542 ms 10 [AS15169] 209.85.253.108 (209.85.253.108) 30.528 ms
29.376 ms 29.778 ms 11 [AS15169] 209.85.249.14 (209.85.249.14)
29.069 ms * 29.549 ms 12 * * * 13 [AS15169] wo-in-f138.1e100.net
(74.125.133.138) 28.522 ms 29.302 ms 28.229 ms

$ traceroute
Version 1.4a12+Darwin
Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g
gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-p port] [-P proto]
[-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs]
host [packetlen]

Bon, j'ai regardé à qui ça correspondait sur un site :
http://bgp.he.net/AS5511

Alors, c'est très intéressant parce qu'on voit qui est connecté avec
qui et on peut en déduire un peu comment tout ça fonctionne
commercialement.

Pour le fond de ma question, en fait tout cela m'amène au protocole
BGP (cf. le nom du site).

regarde si l'un n'utiliserai pas : paris-traceroute

Je suppose que non, mais ça a l'air intéressant :
http://www.paris-traceroute.net

>
>
> autrement, traceroute est passé de man(8) à man(1) avec les
> changements
>
> documentation :
>
> http://www.linuxcertif.com/man/1/traceroute/
>
> http://linux.die.net/man/8/traceroute
>
>
> slt
> bernard
>




bonjour,

la page de man(8) Darwin :

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/traceroute.8.html

slt
bernard
Philippe Gras
Le #26378609
Le 17 nov. 2015 à 23:13, honeyshell
Tu ne peux en général pas forcer une route particulière.



louer un serveur virtuel à Montain View? => https://cloud.google.com/



C'est une idée séduisante, mais qui comporte aussi des inconvénients ;-)

Merci de l'avoir soumise, car elle a en tout cas l'intérêt d'être à portée de clic.=
Philippe Gras
Le #26378610
Le 17 nov. 2015 à 22:59, (François TOURDE) a écrit :

Le 16756ième jour après Epoch,
Philippe Gras écrivait:

Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.

Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?



traceroute est fait de telle sorte que par défaut, il va utiliser des
ports UDP différents à chaque fois. C'est un choix de construction.

Ton firewall n'autorise en sortie que le port 53 et le port xxx (je me
souviens plus), donc ça bloque. C'est la raison.



OK. Il envoie chaque requête avec un port différent si je comprends bien.

Avant que je ne configure iptables comme ça j'aurais pu tracer les routes
avec UDP, mais là je suis contraint de le faire avec ICMP, jusqu'à ce que
je me décide à changer…


Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suffirait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie…) de venir se
brancher chez lui :-)



Ben voilà, t'as qu'a leur demander ;) ... Bon courage.

D'un autre côté, au vu de tes temps de réponse, tu dois être en fibre
avec des accès gravement rapides, donc tu risques de gagner une ou deux
millisecondes de temps de réponse, tu vas pas trop le sentir.



Il y a quelques années, alors que je commençais à me servir d'un serveur et que je
réfléchissais au moyen de booster mes sites, un mec que je connais (un peu) avait
subitement fait baisser le temps de réponse DNS du sien en dessous de 20 ms. Ça
m'avait singulièrement impressionné (je plafonne à 375 ms).

Comme il ne l'avait pas fait lui-même, je ne pouvais pas lui demander la recette :-(

Mais c'est possible, donc je continue à chercher…

Je n'ai pas trop de pistes, mais j'ai vu une conférence de Stéphane Bortzmeyer sur
les DNS chez Youtube ces jours-ci (où d'ailleurs il évoquait BGP), et c'est là que je
découvre l'existence de traceroute. Puis que je n'avais même pas à l'installer !!!

Le Graal… Ben finalement non, le Graal c'est juste un peu plus loin :
https://www.youtube.com/watch?v=L9nXfffeAIU

Tikiclop, tikiclop, tikiclop, tikiclop, tikiclop, tikiclop, tikiclop, tikiclop…=
honeyshell
Le #26378614
De mon côté je regarde comment réduire mon ping vers un serv eur de jeu.
Il semble que la solution d'utiliser un VPN améliore ce ping. Si ton
serveur est principalement à destination d'une clientèle amé ricaine
par exemple, alors relier ton serveur en VPN à un serveur américa in
devrait réduire la latence.

Je me pose quand même la question pourquoi un flux crypté irait p lus
vite qu'un flux normal, alors que le traceroute reste le même, vpn ou
non? Si certains sauraient répondre, ça peut être un axe
d'amélioration pour Phlippe.
Publicité
Poster une réponse
Anonyme