Le mar. 22 nov. 2022 à 16:24, Olivier <[email protected]> a écrit :

Le mar. 22 nov. 2022 à 15:43, <[email protected]> a écrit :

Ta box n’a pas une seule IP mais au moins deux : une pour internet (1.2.3.4) et une pour le réseau interne (192.168.1.*).
Ta machine 1 ne voit pas 1.2.3.4 puisqu’elle sort de la box et n’a pas de raison d’y entrer.

nicolas patrois : pts noir asocial
-

Oui bien sûr.

Néanmoins, ma question porte uniquement sur le point: pourquoi le
traceroute UDP vers la Box1 échoue alors que visiblement Box1 et
Machine sont capables de se parler (certes dans ce cas, le trafic ne
fait que transiter par Box1 mais ce n'est pas la question) ?

Quand bien même Machine1 et Box1 seraient configurés en dépit du bon
sens, quand j'interroge itérativement (avec traceroute) les routeurs
depuis le plus proche de Machine2, je n'arrive pas à obtenir un chemin
stable en moins de 30 sauts ?
Comme mon trafic SIP est par construction initié par Machine1, c'est comme si:
le trafic SIP retour de Machine2 vers Machine1 bénéficiait de l'antériorité du trafic dans le sens opposé
tandis qu'un trafic UDP quelconque, sans antériorité, de Machine2 vers Machine1 partait dans les limbes pour une raison qui m'échappe.


S'il est normal qu'un "traceroute à sec" échoue, j'aimerai bien savoir pourquoi et savoir quel outil utiliser à la place pour débugguer !

En d'autres termes, aurai-je techniquement raison d'attendre que par
défaut, chaque traceroute réussisse sauf programmation explicite et
contraire des routeurs aux extrémités et uniquement ceux-ci ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 22/11/2022 à 16:29, Olivier a écrit :

Néanmoins, ma question porte uniquement sur le point: pourquoi le
traceroute UDP vers la Box1 échoue alors que visiblement Box1 et
Machine sont capables de se parler (certes dans ce cas, le trafic ne
fait que transiter par Box1 mais ce n'est pas la question) ?

la raison des 30 sauts est écrite au tout début des messages affichés
par la commande traceroute:

~$ traceroute free.fr
traceroute to free.fr (212.27.48.10), 30 hops max, 60 byte packets

30 sauts est la valeur maxi par défaut (man traceroute):
---------------
which means we got to the "host", or hit a max (which defaults to 30 hops). ---------------
-m max_ttl, --max-hops=max_ttl
Specifies the maximum number of hops (max time-to-live
value) traceroute will probe. The default is 30.
---------------

et tu peux donc modifier cette valeur (-m xxx).


Pour le reste, il y a pleins d'explications rien que dans le man: ---------------------------
In the modern network environment the traditional traceroute methods
can not be always applicable, because of widespread use of firewalls.
Such firewalls fil‐
ter the "unlikely" UDP ports, or even ICMP echoes. To solve
this, some additional tracerouting methods are implemented (including
tcp), see LIST OF AVAILABLE
METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by
firewalls just as a start of
allowed type of a network session).
---------------



par exemple chez moi, un traceroute free.fr échoue alors qu'un ping
free.fr répond bien.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------0e8c17d360d55210d9e73ae590560233 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

------- Original Message -------
Le mardi 22 novembre 2022 à 22:17, Th.A.C <[email protected]> a écrit :

Le 22/11/2022 à 16:29, Olivier a écrit :

Néanmoins, ma question porte uniquement sur le point: pourquoi le traceroute UDP vers la Box1 échoue alors que visiblement Box1 et
Machine sont capables de se parler (certes dans ce cas, le trafic ne
fait que transiter par Box1 mais ce n'est pas la question) ?

la raison des 30 sauts est écrite au tout début des messages affichés
par la commande traceroute:

~$ traceroute free.fr
traceroute to free.fr (212.27.48.10), 30 hops max, 60 byte packets

30 sauts est la valeur maxi par défaut (man traceroute):
---------------
which means we got to the "host", or hit a max (which defaults to 30 hops). ---------------
-m max_ttl, --max-hops=max_ttl
Specifies the maximum number of hops (max time-to-live
value) traceroute will probe. The default is 30.
---------------

et tu peux donc modifier cette valeur (-m xxx).

Pour le reste, il y a pleins d'explications rien que dans le man: ---------------------------
In the modern network environment the traditional traceroute methods
can not be always applicable, because of widespread use of firewalls.
Such firewalls fil‐
ter the "unlikely" UDP ports, or even ICMP echoes. To solve
this, some additional tracerouting methods are implemented (including
tcp), see LIST OF AVAILABLE
METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of
allowed type of a network session).
---------------

par exemple chez moi, un traceroute free.fr échoue alors qu'un ping
free.fr répond bien.

Il y a aussi l'option --traceroute de nmap qui trouve toute seule la
bonne méthode :
root@rp:/home/hugues# nmap --traceroute free.fr
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-23 08:08 CET
Nmap scan report for free.fr (212.27.48.10)
Host is up (0.017s latency).
Other addresses for free.fr (not scanned): 2a01:e0c:1::1
rDNS record for 212.27.48.10: www.free.fr
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp filtered ssh
25/tcp filtered smtp
80/tcp open http
111/tcp filtered rpcbind
443/tcp open https
2049/tcp filtered nfs

TRACEROUTE (using port 8888/tcp)
HOP RTT ADDRESS
1 1.00 ms 192.168.1.1
2 ...
3 6.42 ms ae107-0.nctou202.rbci.orange.net (193.249.214.86)
4 10.95 ms ae44-0.nrpoi102.rbci.orange.net (193.252.100.54)
5 16.69 ms ae45-0.nridf102.rbci.orange.net (193.251.126.14)
6 15.31 ms ae41-0.noidf002.rbci.orange.net (193.252.98.106)
7 16.49 ms 193.253.13.70
8 16.19 ms p11-9k-1-be1026.intf.routers.proxad.net (212.27.57.126)
9 16.40 ms bzn-9k-2-sys-be2001.intf.routers.proxad.net (194.149.161.246)
10 16.41 ms www.free.fr (212.27.48.10)

Nmap done: 1 IP address (1 host up) scanned in 4.82 seconds

Cordialement,

Hugues
-----------------------0e8c17d360d55210d9e73ae590560233
Content-Type: application/pgp-keys; filename="publickey - [email protected] - 0xE9429B87.asc"; name="publickey - [email protected] - 0xE9429B87.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - [email protected] - 0xE9429B87.asc"; name="publickey - [email protected] - 0xE9429B87.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWUZFMWNSWUpLd1lCQkFI YVJ3OEJBUWRBWlB0M2dhekNrdHVzaXFla2gzcnNsM0FLV0lUaUR1VGEKWk9tZEhCWjBtb3pOSDJo c1lYSnlhWFpsUUhCdExtMWxJRHhvYkdGeWNtbDJaVUJ3YlM1dFpUN0Nqd1FRCkZnb0FJQVVDWUZF MzRRWUxDUWNJQXdJRUZRZ0tBZ1FXQWdFQUFoa0JBaHNEQWg0QkFDRUpFRnZWSk5jdgo0dmswRmlF RTZVS2JoNHIyQ0RlSDZZRkJXOVVrMXkvaStUUWpDQUQvYTNwQ0hBSStsT2o1NHVOVVNTU0MKTDE4 NjFQYjI4YWs2K2JvRnN6bnVHc0FCQVBVczh3QnJLQXZxZ0RWYXFZdVd6d1BjTXNnZWJ3U0huOER3 Cmp1SDV6VmdPempnRVlGRTFjUklLS3dZQkJBR1hWUUVGQVFFSFFPbDZ3OXNiR1lmZHZOeVVPb3pj cExiZgp0aW56SWMraDVicS9rMU91TXdVRkF3RUlCOEo0QkJnV0NBQUpCUUpnVVRmaEFoc01BQ0VK RUZ2VkpOY3YKNHZrMEZpRUU2VUtiaDRyMkNEZUg2WUZCVzlVazF5L2krVFRoUEFEOUZTNFlrcFR0 RXJWNDFPRTBBaTNYClIxNlcrT3REa1p3bTZRVTY0VnUzSmJvQkFMMURMQngxRExLRE5kclZhTUZ1 NGp4MXBZV0JqTEpVZ0xLegpzbDMzakRNTQo9NXVpVgotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBC TE9DSy0tLS0tCg==
-----------------------0e8c17d360d55210d9e73ae590560233--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFAmN9x5YJEFvVJNcv4vk0FiEE6UKbh4r2CDeH6YFBW9Uk1y/i +TQAAArfAQC7uKxJ2t8qMTUV3QxL2aVSgkLcLBGGabA+r+NE/vomZQEAryZc qYHyfCGwxWSyvM9fd5IhfwixDjv7UsavUMUO/Ac=
=9zGv
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

De mon point de vue, le problème de fond est le secret qui entoure le paramétrage des routeurs des opérateurs.
Je suis d'accord pour qu'un opérateur optimise son réseau et ses
ressources mais le fait qu'un administrateur système consciencieux ne
sache pas comment vérifier la connectivité entre deux machines
connectées à Internet (le contenu de ce fil de discussion l'illustre)
est un problème quand parallèlement on voit la qualité du support
proposé :

"Je fais ce que je veux sur mes équipements et j'envoie bouler ceux
qui m'appellent pour autre chose que des coupures franches et
totales,"

Je comprends bien qu'on ne dévoile pas au public des paramétrages
contre le SPAM ou le DoS ou d'autre fléaux, mais de là à rendre
caduque les outils de base d'administration comme traceroute.
Qu'on nous propose une alternative fiable, acceptée (pourquoi pas une
liste précise d'options à ajouter à traceroute, nmap ou autre).


En tout cas, merci à tous pour vos réponses.
J'en retiens que:

1. traceroute en UDP ne marche pas.
2. on teste la connectivité de bout en bout avec ICMP (ping, traceroute -I, ...)
3. si on observe une anomalie sur un N-uplet précis (protocole
IP-port/ source-destination), on peut ouvrir un ticket

Merci à tous

Le mer. 23 nov. 2022 à 08:12, Hugues Larrive <[email protected]> a écrit :

------- Original Message -------
Le mardi 22 novembre 2022 à 22:17, Th.A.C <[email protected]> a écrit :

Le 22/11/2022 à 16:29, Olivier a écrit :

Néanmoins, ma question porte uniquement sur le point: pourquoi le traceroute UDP vers la Box1 échoue alors que visiblement Box1 et
Machine sont capables de se parler (certes dans ce cas, le trafic ne
fait que transiter par Box1 mais ce n'est pas la question) ?

la raison des 30 sauts est écrite au tout début des messages affichés par la commande traceroute:

~$ traceroute free.fr
traceroute to free.fr (212.27.48.10), 30 hops max, 60 byte packets

30 sauts est la valeur maxi par défaut (man traceroute):
---------------
which means we got to the "host", or hit a max (which defaults to 30 hops). ---------------
-m max_ttl, --max-hops=max_ttl
Specifies the maximum number of hops (max time-to-live
value) traceroute will probe. The default is 30.
---------------

et tu peux donc modifier cette valeur (-m xxx).

Pour le reste, il y a pleins d'explications rien que dans le man: ---------------------------
In the modern network environment the traditional traceroute methods
can not be always applicable, because of widespread use of firewalls.
Such firewalls fil‐
ter the "unlikely" UDP ports, or even ICMP echoes. To solve
this, some additional tracerouting methods are implemented (including
tcp), see LIST OF AVAILABLE
METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of
allowed type of a network session).
---------------

par exemple chez moi, un traceroute free.fr échoue alors qu'un ping free.fr répond bien.

Il y a aussi l'option --traceroute de nmap qui trouve toute seule la
bonne méthode :
root@rp:/home/hugues# nmap --traceroute free.fr
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-23 08:08 CET
Nmap scan report for free.fr (212.27.48.10)
Host is up (0.017s latency).
Other addresses for free.fr (not scanned): 2a01:e0c:1::1
rDNS record for 212.27.48.10: www.free.fr
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp filtered ssh
25/tcp filtered smtp
80/tcp open http
111/tcp filtered rpcbind
443/tcp open https
2049/tcp filtered nfs

TRACEROUTE (using port 8888/tcp)
HOP RTT ADDRESS
1 1.00 ms 192.168.1.1
2 ...
3 6.42 ms ae107-0.nctou202.rbci.orange.net (193.249.214.86)
4 10.95 ms ae44-0.nrpoi102.rbci.orange.net (193.252.100.54)
5 16.69 ms ae45-0.nridf102.rbci.orange.net (193.251.126.14)
6 15.31 ms ae41-0.noidf002.rbci.orange.net (193.252.98.106)
7 16.49 ms 193.253.13.70
8 16.19 ms p11-9k-1-be1026.intf.routers.proxad.net (212.27.57.126)
9 16.40 ms bzn-9k-2-sys-be2001.intf.routers.proxad.net (194.149.161.246)
10 16.41 ms www.free.fr (212.27.48.10)

Nmap done: 1 IP address (1 host up) scanned in 4.82 seconds

Cordialement,

Hugues

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Nov 23, 2022 at 09:42:10AM +0100,
Olivier <[email protected]> wrote
a message of 146 lines which said:

J'en retiens que:

Désolé mais non, ce n'est toujours pas ça.

1. traceroute en UDP ne marche pas.

Ça dépend. Port 53 vers un serveur DNS va marcher (ou alors c'est que
le serveur a un gros problème). Évidemment, ça ne nous dit rien de ce
que vont faire les intermédiaires.

2. on teste la connectivité de bout en bout avec ICMP (ping,
traceroute -I, ...)

Non. ICMP peut être bloqué. Si on veut tester la connectivité avec un serveur, la seule méthode qui marchera à tous les coups est de tester
avec le service que ce serveur est censé fournir.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)