« Internet est cassé » ou plutôt : comment tester du TCP ou de l’UDP

Posté par Benoît Sibaud (site web personnel) le 03 juillet 2019 à 11:46. Édité par Arkem, Davy Defaud et Yves Bourguignon. Modéré par Julien Jorge. Licence CC By‑SA.

Étiquettes :

juil.

2019

N. D. L. A. : cet article est généré via une commande du type ansible-playbook InternetEstCassé.yml pour tester réellement les commandes.

Internet est cassé. Le Web ne marche plus. Le réseau est pété. Ça marche pas. Ce site est indisponible. Des lutins bloquent ma connexion. Les tuyaux sont bouchés. Y a Firefox qui veut pas, etc. Quand il y a un souci de réseau, toutes sortes d’imprécations, de suppositions, de supplications ou de raisons sont lancées. Peut‐on aller plus loin et essayer d’y voir plus clair, de déboguer un peu le souci et d’identifier le problème.

On va parler un peu d'IP — surtout la version 4 —, de TCP, d’UDP, d’ICMP, d’ARP, de DNS, de HTTP, etc., d’un peu de vue pratique de vérification du bon fonctionnement ou de recherche d’un souci. En dehors des pages Wikipédia, une lecture utile : la RFC 1180 « A TCP/IP Tutorial » (avec une traduction en français disponible).

Tester un flux TCP ou UDP

TL;DR : En TCP on va avoir des réponses de type connexion refusée si le port est fermé ou filtré avec rejet, une attente ou un délai d’attente trop long si le trafic est poubellisé, et une connexion établie si tout va bien. En UDP, on sera notifié d’une erreur en cas de port fermé ou filtré avec rejet, et ne saura pas différencier un port ouvert d’une « poubellisation » du trafic. Il y a plein d’outils possibles pour tester un flux TCP ou UDP en client ou en serveur.

Prenons un cas simple : on sait si l’on utilise du TCP ou de l’UDP, et l’on veut joindre un port précis sur une adresse IP donnée.

Port TCP

Port TCP fermé

Commençons par essayer de joindre un port fermé (rien en écoute, le programme qui devait écouter dessus n’a pas été lancé, a mal démarré, écoute sur une autre adresse ou port, une autre version d’IP, a déjà planté, etc.). Dans cet exemple, on veut joindre l’adresse IP 127.0.0.1 et le port TCP 60001, avec ce que l’on a sous la main (souvent sur un serveur, le choix des outils disponibles est limité). On constate des réponses de type connexion refusée.

$ telnet 127.0.0.1 60001
    (durée d'exécution 00:00)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection refused
    (code de retour 1)

$ nc -t -v 127.0.0.1 60001
    (durée d'exécution 00:00)
nc: connect to 127.0.0.1 port 60001 (tcp) failed: Connection refused
    (code de retour 1)

$ bash -c exec 3<>/dev/tcp/127.0.0.1/60001
    (durée d'exécution 00:00)
bash: connect: Connexion refusée
bash: /dev/tcp/127.0.0.1/60001: Connexion refusée
    (code de retour 1)

$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60001
    (durée d'exécution 00:00)
tcp_open:ztcp:174: connection failed: connexion refusée
    (code de retour 1)

$ nmap -v -sT -p 60001 127.0.0.1
    (durée d'exécution 00:00)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:06 CEST
Initiating Ping Scan at 19:06
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:06, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:06
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:06, 0.00s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).

PORT      STATE  SERVICE
60001/tcp closed unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
    (code de retour 0)

$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60001 127.0.0.1 -O info
    (durée d'exécution 00:00)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  localhost (127.0.0.1) <rst,ack>  0.033 ms
    (code de retour 0)

$ openssl s_client -connect 127.0.0.1:60001
    (durée d'exécution 00:00)
140595570463872:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140595570463872:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111
    (code de retour 1)

$ ssh -p 60001 127.0.0.1
    (durée d'exécution 00:00)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60001: Connection refused
    (code de retour 255)

$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60001", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
    (durée d'exécution 00:00)
ERROR in Socket Creation : Connection refused
    (code de retour 111)

$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60001))
    (durée d'exécution 00:00)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ConnectionRefusedError: [Errno 111] Connection refused
    (code de retour 1)

$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60001)
    (durée d'exécution 00:00)
-e:1:in `initialize': Connection refused - connect(2) for "127.0.0.1" port 60001 (Errno::ECONNREFUSED)
    from -e:1:in `open'
    from -e:1:in `<main>'
    (code de retour 1)

$ curl -v -s --max-time 60 http://127.0.0.1:60001
    (durée d'exécution 00:00)
* Expire in 0 ms for 6 (transfer 0x55bf2d3fec40)
* Expire in 60000 ms for 8 (transfer 0x55bf2d3fec40)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55bf2d3fec40)
* connect to 127.0.0.1 port 60001 failed: Connexion refusée
* Failed to connect to 127.0.0.1 port 60001: Connexion refusée
* Closing connection 0
    (code de retour 7)

$ wget --timeout=60 --tries=1 http://127.0.0.1:60001
    (durée d'exécution 00:00)
--2019-06-30 19:06:05--  http://127.0.0.1:60001/
Connexion à 127.0.0.1:60001… échec : Connexion refusée.
    (code de retour 4)

$ links -dump http://127.0.0.1:60001
    (durée d'exécution 00:00)
Connection refused
    (code de retour 1)

$ chromium http://127.0.0.1:60001
   (Ce site est inaccessible. 127.0.0.1 n'autorise pas la connexion.  ERR_CONNECTION_REFUSED)
$ firefox http://127.0.0.1:60001
   (Unable to connect Firefox can’t establish a connection to the server at 127.0.0.1:60001)

Port TCP filtré avec rejet

Essayons de joindre un port TCP filtré avec rejet par un pare‐feu. Dans cet exemple, on veut joindre l’adresse IP 127.0.0.1 et le port TCP 60000 (et l’on va obtenir exactement le même résultat que précédemment, à part pour nmap).

$ telnet 127.0.0.1 60000
   (durée d'exécution 0:00:01.015323)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection refused
    (code de retour 1)

$ nc -t -v 127.0.0.1 60000
   (durée d'exécution 0:00:01.012197)
nc: connect to 127.0.0.1 port 60000 (tcp) failed: Connection refused
    (code de retour 1)

$ bash -c exec 3<>/dev/tcp/127.0.0.1/60000
   (durée d'exécution 0:00:01.006805)
bash: connect: Connexion refusée
bash: /dev/tcp/127.0.0.1/60000: Connexion refusée
    (code de retour 1)

$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60000
   (durée d'exécution 0:00:01.026754)
tcp_open:ztcp:174: connection failed: connexion refusée
    (code de retour 1)

$ nmap -v -sT -p 60000 127.0.0.1
   (durée d'exécution 0:00:00.277299)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:06 CEST
Initiating Ping Scan at 19:06
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:06, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:06
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:06, 0.20s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).

PORT      STATE    SERVICE
60000/tcp filtered unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds
    (code de retour 0)

$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60000 127.0.0.1 -O info
   (durée d'exécution 0:00:00.019657)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  localhost (127.0.0.1)  0.030 ms
    (code de retour 0)

$ openssl s_client -connect 127.0.0.1:60000
   (durée d'exécution 0:00:01.042588)
140296376857728:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140296376857728:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111
    (code de retour 1)

$ ssh -p 60000 127.0.0.1
   (durée d'exécution 0:00:01.022311)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60000: Connection refused
    (code de retour 255)

$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60000", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
   (durée d'exécution 0:00:01.052922)
ERROR in Socket Creation : Connection refused
    (code de retour 111)

$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60000))
   (durée d'exécution 0:00:01.077612)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ConnectionRefusedError: [Errno 111] Connection refused
    (code de retour 1)

$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60000)
   (durée d'exécution 0:00:01.178000)
-e:1:in `initialize': Connection refused - connect(2) for "127.0.0.1" port 60000 (Errno::ECONNREFUSED)
    from -e:1:in `open'
    from -e:1:in `<main>'
    (code de retour 1)

$ curl -v -s --max-time 60 http://127.0.0.1:60000
   (durée d'exécution 0:00:01.038146)
* Expire in 0 ms for 6 (transfer 0x55d959531c40)
* Expire in 60000 ms for 8 (transfer 0x55d959531c40)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d959531c40)
* connect to 127.0.0.1 port 60000 failed: Connexion refusée
* Failed to connect to 127.0.0.1 port 60000: Connexion refusée
* Closing connection 0
    (code de retour 7)

$ wget --timeout=60 --tries=1 http://127.0.0.1:60000
   (durée d'exécution 0:00:01.031294)
--2019-06-30 19:06:20--  http://127.0.0.1:60000/
Connexion à 127.0.0.1:60000… échec : Connexion refusée.
    (code de retour 4)

$ links -dump http://127.0.0.1:60000
   (durée d'exécution 0:00:03.066049)
Connection refused
    (code de retour 1)

$ chromium http://127.0.0.1:60000
   (Ce site est inaccessible. 127.0.0.1 n'autorise pas la connexion.  ERR_CONNECTION_REFUSED)
$ firefox http://127.0.0.1:60000
   (Unable to connect Firefox can’t establish a connection to the server at 127.0.0.1:60000)

Port TCP filtré avec poubellisation

Maintenant tentons de joindre un port TCP filtré avec poubellisation des paquets par un pare‐feu. Dans cet exemple, on veut joindre l’adresse IP 127.0.0.1 et le port TCP 60020. Les résultats obtenus sont de type délai d’attente trop long, en l’absence de réponse.

$ telnet 127.0.0.1 60020
    (durée d'exécution 0:02:10.315065)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection timed out
    (code de retour 1)

$ nc -t -v 127.0.0.1 60020
    (durée d'exécution 0:02:10.256818)
nc: connect to 127.0.0.1 port 60020 (tcp) failed: Connection timed out
    (code de retour 1)

$ bash -c exec 3<>/dev/tcp/127.0.0.1/60020
    (durée d'exécution 0:02:09.811710)
bash: connect: Connexion terminée par expiration du délai d'attente
bash: /dev/tcp/127.0.0.1/60020: Connexion terminée par expiration du délai d'attente
    (code de retour 1)

$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60020
    (durée d'exécution 0:02:10.423479)
tcp_open:ztcp:174: connection failed: connexion terminée par expiration du délai d'attente
    (code de retour 1)

$ nmap -v -sT -p 60020 127.0.0.1
    (durée d'exécution 0:00:00.860462)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:15 CEST
Initiating Ping Scan at 19:15
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:15, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:15
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:15, 0.20s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).

PORT      STATE    SERVICE
60020/tcp filtered unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds
    (code de retour 0)

$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60020 127.0.0.1 -O info
    (durée d'exécution 0:00:05.126178)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  *
    (code de retour 0)

$ openssl s_client -connect 127.0.0.1:60020
    (durée d'exécution 0:02:11.242094)
140029672752256:error:0200206E:system library:connect:Connection timed out:../crypto/bio/b_sock2.c:110:
140029672752256:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=110
    (code de retour 1)

$ ssh -p 60020 127.0.0.1
    (durée d'exécution 0:02:10.451898)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60020: Connection timed out
    (code de retour 255)

$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60020", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
    (durée d'exécution 0:02:10.522130)
ERROR in Socket Creation : Connection timed out
    (code de retour 110)

$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60020))
    (durée d'exécution 0:02:10.415526)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TimeoutError: [Errno 110] Connection timed out
    (code de retour 1)

$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60020)
    (durée d'exécution 0:02:10.149211)
-e:1:in `initialize': Connection timed out - connect(2) for "127.0.0.1" port 60020 (Errno::ETIMEDOUT)
    from -e:1:in `open'
    from -e:1:in `<main>'
    (code de retour 1)

$ curl -v -s --max-time 60 http://127.0.0.1:60020
    (durée d'exécution 0:01:00.105772)
* Expire in 0 ms for 6 (transfer 0x556c2510fc40)
* Expire in 60000 ms for 8 (transfer 0x556c2510fc40)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x556c2510fc40)
* Connection timed out after 60000 milliseconds
* Closing connection 0
    (code de retour 28)

$ wget --timeout=60 --tries=1 http://127.0.0.1:60020
    (durée d'exécution 0:01:00.365540)
--2019-06-30 19:27:14--  http://127.0.0.1:60020/
Connexion à 127.0.0.1:60020… échec : Connexion terminée par expiration du délai d'attente.
Abandon.
    (code de retour 4)

$ links -dump http://127.0.0.1:60020
    (durée d'exécution 0:06:32.165744)
Connection timed out
    (code de retour 1)

$ chromium http://127.0.0.1:60020
   (Ce site est inaccessible. 127.0.0.1 a mis trop de temps à répondre. ERR_CONNECTION_TIMED_OUT) 
$ firefox http://127.0.0.1:60020
   (The connection has timed out. The server at 127.0.0.1 is taking too long to respond.

Port TCP en écoute

Au fait, ça donne quoi des connexions TCP réussies ? Dans notre exemple, la connexion est réussie, mais le serveur ne parle pas forcément le bon protocole, et de toute façon il coupe la connexion.

$ telnet 127.0.0.1 60040
    (durée d'exécution 0:00:00.109715)
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.Connection closed by foreign host.
    (code de retour 1)

$ nc -t -v 127.0.0.1 60040
    (durée d'exécution 0:00:00.072833)
Connection to 127.0.0.1 60040 port [tcp/*] succeeded!
    (code de retour 0)

$ bash -c exec 3<>/dev/tcp/127.0.0.1/60040
    (durée d'exécution 0:00:00.077887)

    (code de retour 0)

$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60040
    (durée d'exécution 0:00:00.582218)
Session 1 (host 127.0.0.1, port 60040 fd 3) opened OK.
Setting default TCP session 1
    (code de retour 0)

$ nmap -v -sT -p 60040 127.0.0.1
    (durée d'exécution 0:00:00.575144)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:34 CEST
Initiating Ping Scan at 19:34
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:34, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:34
Scanning localhost (127.0.0.1) [1 port]
Discovered open port 60040/tcp on 127.0.0.1
Completed Connect Scan at 19:34, 0.00s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0022s latency).

PORT      STATE SERVICE
60040/tcp open  unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds
    (code de retour 0)

$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60040 127.0.0.1 -O info
    (durée d'exécution 0:07:30.000489)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  localhost (127.0.0.1) <syn,ack>  0.097 ms
    (code de retour 0)

$ openssl s_client -connect 127.0.0.1:60040
    (durée d'exécution 0:00:00.123910)
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---write:errno=104
    (code de retour 1)

$ ssh -p 60040 127.0.0.1
    (durée d'exécution 0:00:00.210452)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_exchange_identification: Connection closed by remote host
    (code de retour 255)

$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60040", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
    (durée d'exécution 0:00:01.093543)

    (code de retour 0)

$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60040))
    (durée d'exécution 0:00:00.156651)

    (code de retour 0)

$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60040)
    (durée d'exécution 0:00:01.445306)

    (code de retour 0)

$ curl -v -s --max-time 60 http://127.0.0.1:60040
    (durée d'exécution 0:00:00.182162)
* Expire in 0 ms for 6 (transfer 0x55ebb4398c40)
* Expire in 60000 ms for 8 (transfer 0x55ebb4398c40)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55ebb4398c40)
* Connected to 127.0.0.1 (127.0.0.1) port 60040 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:60040
> User-Agent: curl/7.64.0
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
    (code de retour 52)

$ wget --timeout=60 --tries=1 http://127.0.0.1:60040
    (durée d'exécution 0:00:00.215817)
--2019-06-30 19:42:33--  http://127.0.0.1:60040/
Connexion à 127.0.0.1:60040… connecté.
requête HTTP transmise, en attente de la réponse… Erreur de lecture (Connexion ré-initialisée par le correspondant) dans les en-têtes.
Abandon.
    (code de retour 4)

$ links -dump http://127.0.0.1:60040
    (durée d'exécution 0:00:00.214406)
Error reading from socket
    (code de retour 1)

$ chromium http://127.0.0.1:60040
   (Ce site est inaccessible. Il se peut que la page Web à l'adresse http://127.0.0.1:60040/ soit temporairement inaccessible ou qu'elle ait été déplacée de façon permanente à une autre adresse Web.  ERR_SOCKET_NOT_CONNECTED)

$ firefox http://127.0.0.1:60040
   (The connection was reset. The connection to the server was reset while the page was loading.)

Trafic réseau

Jetons un œil au trafic réseau échangé (si le port est fermé, la réponse est un TCP RST ; si le trafic est rejeté, la réponse est un « ICMP port inaccessible » ; si le trafic est poubellisé, le TCP SYN (et les réessais) restent sans réponse ; enfin, si le port est ouvert, la connexion s’établit avec la poignée de main TCP, la fermeture de session pouvant être différente suivant si des données ont été envoyées ou non). Ici, source et destination sont une seule et même machine, mais peu importe.

$ sudo tshark -i lo -f "host 127.0.0.1 and (tcp or icmp)"
Running as user "root" and group "root". This could be dangerous.
tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled due to running Wireshark as superuser. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user.
Capturing on 'Loopback'
(n° paquet, horloge, source -> destination  protocole...)
    1 0.000000000    127.0.0.1 → 127.0.0.1    TCP 74 39766 → 60001 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10596677 TSecr=0 WS=128
    2 0.000016574    127.0.0.1 → 127.0.0.1    TCP 54 60001 → 39766 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
(...)
   37 8.190159737    127.0.0.1 → 127.0.0.1    TCP 74 42694 → 60000 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10598724 TSecr=0 WS=128
   38 8.190177891    127.0.0.1 → 127.0.0.1    ICMP 102 Destination unreachable (Port unreachable)
   39 9.190192177    127.0.0.1 → 127.0.0.1    TCP 74 [TCP Retransmission] 42694 → 60000 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10598975 TSecr=0 WS=128
   40 9.190276171    127.0.0.1 → 127.0.0.1    ICMP 102 Destination unreachable (Port unreachable)
(...)
  103 28.328151130    127.0.0.1 → 127.0.0.1    TCP 74 51006 → 60020 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10603759 TSecr=0 WS=128
  104 29.326198277    127.0.0.1 → 127.0.0.1    TCP 74 [TCP Retransmission] 51006 → 60020 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10604009 TSecr=0 WS=128
  105 31.330178795    127.0.0.1 → 127.0.0.1    TCP 74 [TCP Retransmission] 51006 → 60020 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=10604510 TSecr=0 WS=128
(...)
  207 1683.477081380    127.0.0.1 → 127.0.0.1    TCP 74 45876 → 60040 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=11017546 TSecr=0 WS=128
  208 1683.477103411    127.0.0.1 → 127.0.0.1    TCP 74 60040 → 45876 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=11017546 TSecr=11017546 WS=128
  209 1683.477118197    127.0.0.1 → 127.0.0.1    TCP 66 45876 → 60040 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11017546 TSecr=11017546
  210 1683.477172642    127.0.0.1 → 127.0.0.1    TCP 66 60040 → 45876 [FIN, ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11017546 TSecr=11017546
  211 1683.477299723    127.0.0.1 → 127.0.0.1    TCP 66 45876 → 60040 [FIN, ACK] Seq=1 Ack=2 Win=43776 Len=0 TSval=11017546 TSecr=11017546
  212 1683.477307741    127.0.0.1 → 127.0.0.1    TCP 66 60040 → 45876 [ACK] Seq=2 Ack=2 Win=43776 Len=0 TSval=11017546 TSecr=11017546
(...)
  276 1688.854649280    127.0.0.1 → 127.0.0.1    TCP 66 45900 → 60040 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11018891 TSecr=11018891
  277 1688.854689131    127.0.0.1 → 127.0.0.1    TCP 66 60040 → 45900 [FIN, ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=11018891 TSecr=11018891
  278 1688.854759615    127.0.0.1 → 127.0.0.1    HTTP 145 GET / HTTP/1.1 
  279 1688.854773879    127.0.0.1 → 127.0.0.1    TCP 54 60040 → 45900 [RST] Seq=2 Win=0 Len=0

Port UDP

Port UDP fermé

Et si l’on teste de l’UDP, lorsque rien n’est en écoute, par exemple, on peut détecter que le port est fermé (globalement le client est notifié de la fermeture).

$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60011
    (durée d'exécution 0:00:00.009070)

    (code de retour 1)

$ bash -c exec 3<>/dev/udp/127.0.0.1/60011; echo coin >&3; sleep 10
    (durée d'exécution 0:00:10.011074)

    (code de retour 0)

$ traceroute -U -N 1 -m 1 -q 1 -p 60011 127.0.0.1
    (durée d'exécution 0:00:00.030841)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  localhost (127.0.0.1)  0.039 ms
    (code de retour 0)

$ sudo nmap -v -sU -p 60011 127.0.0.1
    (durée d'exécution 0:00:00.519691)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:42 CEST
Initiating UDP Scan at 19:42
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:42, 0.24s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000090s latency).

PORT      STATE  SERVICE
60011/udp closed unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds
           Raw packets sent: 1 (28B) | Rcvd: 2 (84B)
    (code de retour 0)

Port UDP filtré avec rejet

Ou que le trafic est rejeté par un pare‐feu, cela revient plus ou moins au même :

$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60010
    (durée d'exécution 0:00:00.027297)

    (code de retour 1)

$ bash -c exec 3<>/dev/udp/127.0.0.1/60010; echo coin >&3; sleep 10
    (durée d'exécution 0:00:10.010258)

    (code de retour 0)

$ traceroute -U -N 1 -m 1 -q 1 -p 60010 127.0.0.1
    (durée d'exécution 0:00:00.015655)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  localhost (127.0.0.1)  0.035 ms
    (code de retour 0)

$ sudo nmap -v -sU -p 60010 127.0.0.1
    (durée d'exécution 0:00:00.392441)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:43 CEST
Initiating UDP Scan at 19:43
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:43, 0.22s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000081s latency).

PORT      STATE  SERVICE
60010/udp closed unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.33 seconds
           Raw packets sent: 1 (28B) | Rcvd: 2 (84B)
    (code de retour 0)

Port UDP filtré avec poubellisation

En revanche, il est devient difficile de différencier le trafic UDP poubellisé du trafic réussi (car le client n’est pas notifié de l’erreur, le protocole UDP n’est pas connecté et ne garantit ni livraison, ni l’ordre d’arrivée, ni la non‐duplication des paquets transmis).

$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60030
    (durée d'exécution 0:00:20.026213)
Connection to 127.0.0.1 60030 port [udp/*] succeeded!
    (code de retour 0)

$ bash -c exec 3<>/dev/udp/127.0.0.1/60030; echo coin >&3; sleep 10
    (durée d'exécution 0:00:10.010664)

    (code de retour 0)

$ traceroute -U -N 1 -m 1 -q 1 -p 60030 127.0.0.1
    (durée d'exécution 0:00:05.016796)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  *
    (code de retour 0)

$ sudo nmap -v -sU -p 60030 127.0.0.1
    (durée d'exécution 0:00:02.354541)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:43 CEST
Initiating UDP Scan at 19:43
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:43, 2.04s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up.

PORT      STATE         SERVICE
60030/udp open|filtered unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.23 seconds
           Raw packets sent: 2 (56B) | Rcvd: 2 (56B)
    (code de retour 0)

Port UDP en écoute

On retrouve le même résultat sur un test avec effectivement un serveur en écoute :

$ sh -c echo coin|nc -u -v -w10 127.0.0.1 60050
    (durée d'exécution 0:00:20.029595)
Connection to 127.0.0.1 60050 port [udp/*] succeeded!
    (code de retour 0)

$ bash -c exec 3<>/dev/udp/127.0.0.1/60050; echo coin >&3; sleep 10
    (durée d'exécution 0:00:10.015239)

    (code de retour 0)

$ traceroute -U -N 1 -m 1 -q 1 -p 60050 127.0.0.1
    (durée d'exécution 0:00:05.020411)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  *
    (code de retour 0)

$ sudo nmap -v -sU -p 60050 127.0.0.1
    (durée d'exécution 0:00:02.302030)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:44 CEST
Initiating UDP Scan at 19:44
Scanning localhost (127.0.0.1) [1 port]
Completed UDP Scan at 19:44, 2.03s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up.

PORT      STATE         SERVICE
60050/udp open|filtered unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.18 seconds
           Raw packets sent: 2 (56B) | Rcvd: 2 (56B)
    (code de retour 0)

Trafic échangé

Regardons le trafic réseau échangé (un port fermé ou un trafic rejeté génère une réponse « ICMP port inaccessible », et un port ouvert ou un trafic poubellisé ne génère aucune réponse). Ici source et destination sont une seule et même machine, mais peu importe.

$ sudo tshark -i lo -f "host 127.0.0.1 and (udp or icmp)"
Running as user "root" and group "root". This could be dangerous.
tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled due to running Wireshark as superuser. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user.
Capturing on 'Loopback'
(n° paquet, horloge, source -> destination  protocole...)
    1 0.000000000    127.0.0.1 → 127.0.0.1    UDP 43 58991 → 60011 Len=1
    2 0.000018701    127.0.0.1 → 127.0.0.1    ICMP 71 Destination unreachable (Port unreachable)
(...)
    9 15.846541876    127.0.0.1 → 127.0.0.1    UDP 43 52810 → 60010 Len=1
   10 15.846560153    127.0.0.1 → 127.0.0.1    ICMP 71 Destination unreachable (Port unreachable)
(...)
   17 31.086988181    127.0.0.1 → 127.0.0.1    UDP 43 48647 → 60030 Len=1
   18 31.086997796    127.0.0.1 → 127.0.0.1    UDP 43 48647 → 60030 Len=1
   19 32.087088785    127.0.0.1 → 127.0.0.1    UDP 43 48647 → 60030 Len=1
(...)
   34 73.221725214    127.0.0.1 → 127.0.0.1    UDP 43 46294 → 60050 Len=1
   35 73.221740517    127.0.0.1 → 127.0.0.1    UDP 43 46294 → 60050 Len=1
   36 74.221835792    127.0.0.1 → 127.0.0.1    UDP 43 46294 → 60050 Len=1

TODO : des idées pour la suite

Des idées pour la suite :

DNS ?
ip route get to, ping, arp, arping, dns / dig / host, tsocks, lsof / strace, HTTP et proxy, SSH et tunnel ?
RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency

# Super récapitulatif

Posté par Yves (site web personnel) le 03 juillet 2019 à 15:38. Évalué à 7.

Merci pour ce récapitulatif des commandes disponibles. C’est instructif, et ça dépanne quand on est dans un environnement où la commande qu’on connait n’est pas disponible.
# telnet

Posté par Pierre Jarillon (site web personnel) le 03 juillet 2019 à 17:55. Évalué à -10.

C'est gentil de commencer par telnet, sauf que telnet n'est plus installé avec ma distribution (Mageia).

Ce n'est pas un oubli, le paquet existe toujours et son titre est netkit-telnet-server - A extremely unsecure telnet server.
Dans la description il est écrit : « Install the telnetd package if you want to support extremely unsecure remote logins to your machine ». Même en étant nul en anglais, on peut comprendre !

telnet est donc une commande à oublier pour des raisons de sécurité, sauf peut-être dans le cas d'un réseau local bien isolé du reste du monde. Il vaut infiniment mieux utiliser ssh, la légère réduction de vitesse due à la cryptographie étant le prix à payer pour la sécurité.
- [^] # Re: telnet
  
  Posté par Benoît Sibaud (site web personnel) le 03 juillet 2019 à 18:16. Évalué à 5. Dernière modification le 03 juillet 2019 à 18:18.
  
  Le tcp syn envoyé par telnet n'a pas plus sécurisé que le tcp syn envoyé par ssh (ou firefox). Et le syn ack renvoyé non plus (ni moins) :).
  
  (pour ceux qui ne lisent pas ansible couramment, j'installe les paquets suivant sur une Debian Sid pour le test zsh, netcat-openbsd, telnet, bash, openssl, openssh-client, perl-base, python3-minimal, ruby, curl, wget, links, traceroute)
  - [^] # Re: telnet
    
    Posté par pasBill pasGates le 03 juillet 2019 à 20:51. Évalué à 2.
    
    Je suggérerais netcat plutôt que telnet
    - [^] # Re: telnet
      
      Posté par seveso le 08 juillet 2019 à 20:39. Évalué à 6.
      C'est justement le deuxième exemple fourni dans l'article non ?
      
      $ nc -t -v 127.0.0.1 60001
- [^] # Re: telnet
  
  Posté par Laurent GAUTROT le 03 juillet 2019 à 18:16. Évalué à 6.
  
  Gentil ou méchant, la commande telnet permet d'établir une connexion TCP sur un port arbitraire et pour faire passer n'importe quel type de protocole en texte clair. Le paquet mentionné contient le serveur telnet (d'où la mention de telnetd).
- [^] # Re: telnet
  
  Posté par steph1978 le 03 juillet 2019 à 22:09. Évalué à 10.
  
  telnet est donc une commande à oublier pour des raisons de sécurité
  
  Pfiu ça me rappelle des architectes sécurité qui n'ont jamais touché un serveur : "telnet c'est dangereux, ah on va se faire hacker, interdiction de mettre ça sur les serveurs".
  "Heu mais telnet nous permet de tester les ouvertures de flux. C'est pas Telnet qui est dangereux, c'est le demon telnet = telnetd, qui est dangereux mille millions de mille sabords !"
  
  De toute façon il vaut mieux utiliser nc.
  Et là c'est le retour des architectes sécurité "quoi, nc c'est comme telnet ; ah interdiction !".
  
  Et il y en a qui ont peur des chats noirs ou du chiffre 13…. mais ils ne devraient pas avoir le droit d’édicter des règles.
- [^] # Re: telnet
  
  Posté par Yves Bourguignon le 04 juillet 2019 à 00:29. Évalué à 9.
  Donc en résumé, le serveur telnet (le démon telnetd) aucun intérêt, pas besoin.
  Par contre, le client telnet (la commande) très utile pour faire des diagnostics comme montrés ici.
  Un autre exemple d'un usage détourné de la commande (on n'essaye pas de se connecter à un serveur telnet), on peut vouloir visualiser le dialogue avec un serveur smtp :
```
$ telnet smtp.trifouilly.fr 25
Trying 213.167.234.9...
Connected to smtp.trifouilly.fr.
Escape character is '^]'.
220 smtp-p18.trifouilly.fr ESMTP Postfix
HELO test.mondomaine.com
250 smtp-p18.trifouilly.fr
MAIL FROM:<test@mondomaine.com>
250 2.1.0 Ok
RCPT TO:<toto@mondomaine.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test message
This is the body of the message!
.
250 2.0.0 Ok: queued as 2D8FD4C80FF
quit
221 2.0.0 Bye
Connection closed by foreign host.
```
  - [^] # Re: telnet
    
    Posté par Anonyme le 05 juillet 2019 à 13:54. Évalué à 0.
    
    Par contre, le client telnet (la commande) très utile pour faire des diagnostics comme montrés ici.
    
    Elle est franchement très peu utile quand tu as nc et/ou socat.
- [^] # Re: telnet
  
  Posté par freem le 04 juillet 2019 à 13:16. Évalué à 5.
  
  Si on omets le fait que tu confondes serveur et client, je suis quasi sûr que tu as un client telnet installé par défaut. Je pense ici à busybox, qui entres autres inclues une implémentation de telnet, ping, netcat, traceroute et bien d'autres.
# à continuer

Posté par Alex G. le 04 juillet 2019 à 12:35. Évalué à 3.

Je dirais d'abord ipv6 puis le DNS puis ip.

C'est bien utile de savoir dépanner.

Perso là où je commence à me perdre c'est quand on est dans les sous réseaux.
# pas compris

Posté par freem le 04 juillet 2019 à 13:25. Évalué à 9.

En fait, c'est quoi le message de cette dépêche?

Je ne sais pas pour vous, mais moi je vois surtout un pâté de commandes illisibles et sans explications. Cela dis, ça semble assumé:

cet article est généré via une commande du type ansible-playbook InternetEstCassé.yml pour tester réellement les commandes.

En plus, j'aurais tendance, vu le titre et l'intro, à croire que c'est à destination de l'utilisateur d'un réseau, mais rien sur le DNS, rien sur le routeur… Perso, pour savoir ce qui se passe quand «internet est cassé», je bosse pas sur localhost, je commence par ping la cible, ensuite je ping perdu.com, puis je ping 8.8.8.8, puis je ping mon routeur, et en général à ce moment la, je sais ou est le maillon qui merde.

Du coup, je pense que j'ai rien compris. J'en viens même à me demander s'il y a quoique ce soit à comprendre, alors je voudrais bien quelques explications?
- [^] # Re: pas compris
  
  Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 04 juillet 2019 à 13:37. Évalué à 4.
  
  D'après ce que je comprends, ça répertorie les commandes qui permettent de diagnostiquer pourquoi la connexion est foireuse.
  
  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
- [^] # Re: pas compris
  
  Posté par Benoît Sibaud (site web personnel) le 04 juillet 2019 à 13:45. Évalué à 6.
  
  un pâté de commandes illisibles
  
  C'est toujours le cas devant une langue étrangère si tu ne parles pas la langue en question.
  
  et sans explications.
  
  Que te manque-t-il dans les explications qui manquent selon toi ? Quelles sont tes questions ?
  
  je bosse pas sur localhost
  
  Tu peux mettre une autre IPv4 que 127.0.0.1 si tu veux, ça change rien à la question des flux TCP / UDP.
  
  Par ailleurs ping n'aide pas pour les flux TCP / UDP, il envoie des ICMP ECHO_REQUEST.
  - [^] # Re: pas compris
    
    Posté par Big Pete le 04 juillet 2019 à 14:12. Évalué à 4.
    
    Tu peux mettre une autre IPv4 que 127.0.0.1 si tu veux, ça change rien à la question des flux TCP / UDP.
    
    Si cela peut changer quelques trucs. Typiquement, si tu as un timeout, peut-être que le paquet SYN s'est perdu en route, peut-être que la route retour n'est pas bonne sur la machine destination et que le SYN-ACK s'est lui perdu en route. Normalement, un firewall que tu es sensé traverser (pas un firewall local) ne fait jamais de rejet avec réponse, mais au cas où il voudrait le faire, il ne peut pas envoyer de RST (parce qu'il ne porte pas l'ip destination ; il peut "spoofé" l'ip destination, mais c'est assez moche). Dans ce cas, il envoi un message icmp (qui peut lui même être filtré ou mal routé), du style "host/net unreachable" ou encore "destination host/net prohibited"
    
    Désolé, je répond un peu en vitesse, du coup, j'ai pas pris le temps de traduite le jargon en français. Enfin, bon sinon, c'est cool d'avoir compilé une liste de commande de test, bien pratique ça.
    
    Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
    - [^] # Re: pas compris
      
      Posté par Anonyme le 05 juillet 2019 à 14:08. Évalué à 5.
      Normalement, un firewall […] ne fait jamais de rejet avec réponse
      
      Sauf quand il est bien configuré.
      
      iptables -P INPUT DROP c’est une plaie pour le débug. Je préfère 1000 fois un pare-feu qui me prévient quand je l’ai mal configuré.
      
      Perso j’utilise quelque chose dans ce genre :
      
      iptables -P INPUT DROP iptables -A INPUT -p tcp -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -p icmp -j REJECT --reject-with icmp-host-unreachable
      
      Et, au besoin, je DROP spécifiquement les « méchants » (genre avec fail2ban ou sshguard).
  - [^] # Re: pas compris
    
    Posté par freem le 05 juillet 2019 à 21:50. Évalué à 6.
    C'est toujours le cas devant une langue étrangère si tu ne parles pas la langue en question.
    
    M'enfin, c'est principalement du shell… pas une langue étrangère… en tout cas, pas pour moi.
    
    Quelles sont tes questions ?
    
    Si je prend juste le 1er exemple (mais à vue de nez, ils sont tous du même acabit):
```
$ telnet 127.0.0.1 60001
    (durée d'exécution 00:00)
Trying 127.0.0.1...telnet: Unable to connect to remote host: Connection refused
    (code de retour 1)

$ nc -t -v 127.0.0.1 60001
    (durée d'exécution 00:00)
nc: connect to 127.0.0.1 port 60001 (tcp) failed: Connection refused
    (code de retour 1)

$ bash -c exec 3<>/dev/tcp/127.0.0.1/60001
    (durée d'exécution 00:00)
bash: connect: Connexion refusée
bash: /dev/tcp/127.0.0.1/60001: Connexion refusée
    (code de retour 1)

$ zsh -c autoload -U tcp_open;tcp_open 127.0.0.1 60001
    (durée d'exécution 00:00)
tcp_open:ztcp:174: connection failed: connexion refusée
    (code de retour 1)

$ nmap -v -sT -p 60001 127.0.0.1
    (durée d'exécution 00:00)
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 19:06 CEST
Initiating Ping Scan at 19:06
Scanning 127.0.0.1 [2 ports]
Completed Ping Scan at 19:06, 0.00s elapsed (1 total hosts)
Initiating Connect Scan at 19:06
Scanning localhost (127.0.0.1) [1 port]
Completed Connect Scan at 19:06, 0.00s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).

PORT      STATE  SERVICE
60001/tcp closed unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
    (code de retour 0)

$ sudo traceroute -T -N 1 -m 1 -q 1 -p 60001 127.0.0.1 -O info
    (durée d'exécution 00:00)
traceroute to 127.0.0.1 (127.0.0.1), 1 hops max, 60 byte packets
 1  localhost (127.0.0.1) <rst,ack>  0.033 ms
    (code de retour 0)

$ openssl s_client -connect 127.0.0.1:60001
    (durée d'exécution 00:00)
140595570463872:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140595570463872:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111
    (code de retour 1)

$ ssh -p 60001 127.0.0.1
    (durée d'exécution 00:00)
Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh: connect to host 127.0.0.1 port 60001: Connection refused
    (code de retour 255)

$ perl -e use IO::Socket::INET;new IO::Socket::INET ( PeerHost => "127.0.0.1", PeerPort => "60001", Proto => "tcp",) or die "ERROR in Socket Creation : $!\n";
    (durée d'exécution 00:00)
ERROR in Socket Creation : Connection refused
    (code de retour 111)

$ python3 -c import socket;socket.socket().connect(("127.0.0.1",60001))
    (durée d'exécution 00:00)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ConnectionRefusedError: [Errno 111] Connection refused
    (code de retour 1)

$ ruby -e require "socket";s = TCPSocket.open("127.0.0.1", 60001)
    (durée d'exécution 00:00)
-e:1:in `initialize': Connection refused - connect(2) for "127.0.0.1" port 60001 (Errno::ECONNREFUSED)
    from -e:1:in `open'
    from -e:1:in `<main>'
    (code de retour 1)

$ curl -v -s --max-time 60 http://127.0.0.1:60001
    (durée d'exécution 00:00)
* Expire in 0 ms for 6 (transfer 0x55bf2d3fec40)
* Expire in 60000 ms for 8 (transfer 0x55bf2d3fec40)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55bf2d3fec40)
* connect to 127.0.0.1 port 60001 failed: Connexion refusée
* Failed to connect to 127.0.0.1 port 60001: Connexion refusée
* Closing connection 0
    (code de retour 7)

$ wget --timeout=60 --tries=1 http://127.0.0.1:60001
    (durée d'exécution 00:00)
--2019-06-30 19:06:05--  http://127.0.0.1:60001/
Connexion à 127.0.0.1:60001… échec : Connexion refusée.
    (code de retour 4)

$ links -dump http://127.0.0.1:60001
    (durée d'exécution 00:00)
Connection refused
    (code de retour 1)

$ chromium http://127.0.0.1:60001
   (Ce site est inaccessible. 127.0.0.1 n'autorise pas la connexion.  ERR_CONNECTION_REFUSED)
$ firefox http://127.0.0.1:60001
   (Unable to connect Firefox can’t establish a connection to the server at 127.0.0.1:60001)
```
    Pour l'anecdote, ce pavé est tellement long qu'il semblerait que le select/paste d'X11 a besoin de s'y reprendre à 2 fois.
    
    Pour l'explication de ce qui me plaît pas, perso, je pense que séparer les commandes entres elles aurait rendu la chose nettement plus lisible: ici, on ne peux même pas aisément voir où s'arrête ou se finit une commande.
    De plus, scinder aurait permis d'éventuels commentaires sur les options ou la sortie du programme, voire, soyons fous, un commentaire sur la raison de choisir telle ou telle alternative.
    
    Que te manque-t-il dans les explications qui manquent selon toi ?
    
    Je pense avoir donné quelques indices plus haut dans ce post: pourquoi utiliser telle ou telle alternative, quelles sont les avantages et inconvénients, ce genre de trucs.
    Je suis désolé pour ceux qui n'apprécient pas de lire ça, mais même si je reconnais le travail qu'il y a du y avoir pour lister tout ça, je ne suis pas convaincu que la forme lui rende justice, bien au contraire.
    
    Tu peux mettre une autre IPv4 que 127.0.0.1 si tu veux, ça change rien à la question des flux TCP / UDP.
    
    Ben si, déjà pas besoin de DNS, qui est un des composants les plus fragiles selon mon vécu propre et me semble bien que localhost est traité de manière spécifique par le noyal, bien que j'aie aucune certitude sur ce point.
    Accessoirement, le titre du journal dit bien "internet est cassé", et désolé, mais je ping pas perdu.com sur localhost moi.
  - [^] # Re: pas compris
    
    Posté par Tonton Th (site web personnel, Mastodon) le 07 juillet 2019 à 01:45. Évalué à 2.
    
    Tu peux mettre une autre IPv4 que 127.0.0.1 si tu veux, ça change rien à la question des flux TCP / UDP.
    
    Mmmm. je n'en suis pas si sûr. Il me semble qu'il y a des piles IP qui court-circuitent tout ce qu'il y a en dessous quand elles détectent 127/8. Donc ça a un peu d'influence sur la latence, toussa..
- [^] # Re: pas compris
  
  Posté par Christophe B. (site web personnel) le 04 juillet 2019 à 15:57. Évalué à 5.
  
  Les milles et unes manières de tester la connexion à un port TCP et UDP
  
  honnêtement il faudrait en faire une page bien présentée accessible depuis un smartphone par exemple
  car il y en a pour tout les gouts et le couleurs
  
  Beauo boulot merci …
  
  Petite question pour ma culture personnelle :
  à part installer le client telnet ou télécharger un emulateur de terminal comme Mobaxterm, quelqu'un connaît des commandes équivalentes sous Windows ?
  
  Merci d'avance
  - [^] # Re: pas compris
    
    Posté par n.rigaud le 08 juillet 2019 à 14:15. Évalué à 2.
    
    Pour info,
    sur mon PC pro sous Windows 10 je dispose nativement des commandes suivantes:
    - curl
    - ssh
    - tracert
    si je veux aller plus loin, je vais plutôt regarder du côté du powershell, avec par exemple la commande suivante:
    - Test-NetConnection
    Cette dernière va me permettre de faire aussi bien un ping que tester un port …
    
    Il est très probable que ces possibilités ne soient pas présentes nativement sur des versions plus anciennes de Windows.
    - [^] # Re: pas compris
      
      Posté par BAud (site web personnel) le 09 juillet 2019 à 10:22. Évalué à 2. Dernière modification le 09 juillet 2019 à 10:22.
      d'autres commandes utiles :
      
      mtr (un traceroute mais en mieux)
      
      dig (plus précis que nslookup)
      
      iftop (comme top mais pour le réseau) cf. http://madb.mageia.org/package/show/application/0/name/iftop
      
      sar pour produire des stats système (fait par un ancien collègue) cf. http://madb.mageia.org/package/show/application/0/name/sysstat
      
      je suis tombé au passage sur sysdig http://madb.mageia.org/package/show/application/0/name/sysdig à creuser :-)
      
      ainsi que sur dstat http://madb.mageia.org/package/show/application/0/name/dstat
      
      et glances réalisé par un contributeur à LinuxFr.org https://linuxfr.org/tags/glances/public pour avoir un état à la connexion, mieux qu'une fortune :p
      - [^] # Re: pas compris
        
        Posté par Anonyme le 09 juillet 2019 à 15:18. Évalué à 5.
        
        mtr (un traceroute mais en mieux)
        
        Si ça peut aider certaines personnes :
        
        $ which mtr mtr: aliased to mtr -ez -o "SDL NBWA J"
        
        Ça affiche (quand c’est possible) les numéros d’AS et les infos MPLS. Ça ajoute également une colonne avec le nombre de paquets perdus et ça remplace la colonne écart type par une colonne gigue.
        
        iftop (comme top mais pour le réseau)
        
        J’aime aussi beaucoup bmon qui affiche le trafic par interface, avec des graphes et des informations assez détaillé :
    - [^] # Re: pas compris
      
      Posté par Christophe B. (site web personnel) le 09 juillet 2019 à 15:49. Évalué à 2.
      
      Merci pour l'info
      je vais voir si je retrouve ces commandes sur les versions server
- [^] # Re: pas compris
  
  Posté par Anonyme le 05 juillet 2019 à 14:00. Évalué à 3.
  
  Perso, pour savoir ce qui se passe quand «internet est cassé», je bosse pas sur localhost, je commence par ping la cible, ensuite je ping perdu.com, puis je ping 8.8.8.8, puis je ping mon routeur, et en général à ce moment la, je sais ou est le maillon qui merde.
  
  Quand l’erreur de connexion n’est pas explicite[1], une bonne technique, c’est de prendre le modèle OSI et de remonter couche par couche.
  
  [1] J’entends par là un timeout par exemple, par opposition à un retour HTTP ou un ICMP port unreachable.
  - [^] # Re: pas compris
    
    Posté par fredezic le 06 juillet 2019 à 18:10. Évalué à 0.
    
    moi généralement je fais l'inverse
    
    je commence par pinger la passerelle par défaut
    
    => si ca marche pas, je verifie le cablage et l'etat de la passerelle (généralement c'est la box internet)
    => si ca marche, je pinge le 8.8.8.8
    ==> si ca marche pas je me connecte sur la box, elle ont toute une interface d'admin en http, ca te dit si tu as un probleme avec ton acces internet
    ==> si ca marche, je teste un ping sur www.google.Fr (ca permet de valider le dns),
    ===> si ca marche pas, change ton dns sur ta config (tu peux mettre le dns de google par exemple 8.8.8.8)
    ===> si ca marche, c'est que tu n'as pas de probleme réseau, il faut chercher ailleurs
    
    j'ai déjà eu des problemes avec le dhcp de la box qui ne marchait pas, j'avais du passé en ip fixe. mais c'est plutôt rare
    
    le test des port tcp permet surtout de valider des ouvertures firewall, donc ca se fait surtout dans un cadre pro. je ne vois pas dans quel cas ca peut etre utilisé dans un cadre personnel
    - [^] # Re: pas compris
      
      Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) le 07 juillet 2019 à 14:26. Évalué à 1. Dernière modification le 07 juillet 2019 à 14:26.
      
      « si ca marche, je pinge le 8.8.8.8 » Et si Google vient de décider d'arrêter de répondre aux requêtes ICMP echo, ou bien de limiter le taux de réponse ?
      
      Un test général de connectivité doit se faire vers une machine qu'on contrôle, ou bien vers une machine explicitement prévue pour cela (donc pas Google Public DNS).
      - [^] # Re: pas compris
        
        Posté par fredezic le 07 juillet 2019 à 15:39. Évalué à 0.
        
        Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?)
        
        l'avantage du dns de google c'est que c'est une ip facilement mémorisable et qui répond au ping depuis plusieurs années, donc je sais que google n'est pas apprécié sur ce site, mais ca reste le plus simple quand on veut juste vérifier que son accès internet fonctionne
        
        [^] # Re: pas compris
        
        Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) le 09 juillet 2019 à 09:57. Évalué à 3.
        
        « Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?) » OU BIEN VERS UNE MACHINE PRÉVUE POUR CELA, c'était écrit. Les ancres Atlas, par exemple. https://labs.ripe.net/Members/stephane_bortzmeyer/checking-your-internet-connectivity-with-ripe-atlas-anchors
        
        [^] # Re: pas compris
        
        Posté par Anonyme le 09 juillet 2019 à 15:04. Évalué à 2.
        
        Pour info, les citations en Markdown, ça se fait comme dans dans les courriels : >.
        
        Peux tu respecter la netiquette s’il te plaît ? :p
    - [^] # Re: pas compris
      
      Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) le 07 juillet 2019 à 14:28. Évalué à 4.
      « si ca marche, je teste un ping sur www.google.Fr » C'est très sommaire comme test :
      
      ping ne donnera pas de message d'erreur détaillé s'il y a un problème DNS (juste du binaire ça marche / ça marche pas). Pour tester le DNS, il vaut mieux utiliser dig.
      
      s'il y a une panne, comment savoir si elle est de la faute de Google, de l'AFNIC ou du résolveur ?
      - [^] # Re: pas compris
        
        Posté par fredezic le 07 juillet 2019 à 15:50. Évalué à -3.
        
        qui a dit que je voulais une erreur détaillé ?
        le but du test est juste de savoir si la résolution dns fonctionne, c'est tout
        
        en plus dig est tres peu connu, même dans le milieu IT, je suis dans l'informatique et je crois etre le seul a l'utiliser dans mon service (je bosse dans une equipe réseau de 15 personnes) nslookup est beaucoup plus connu
        en plus ce n'est pas dispo sur windows et c'est beaucoup trop verbeux pour ce qu'on veut y faire
        
        PS: personnelement ca commence a devenir pénible ces ayatola du libre et autre barbu. j'ai du mal a comprendre pourquoi je prends un -1 ou je dis simplement comment je fais moi, alors que toi qui se contente de cracher ton venin prends du +3
        
        oui ce n'est pas très académique, oui si le méchant google décide de couper son ping, ca ne marche plus, mais dans les faits, c'est simple et efficace
        
        franchement ce système de note ca ne donne pas envie de participer
        sur ce, ciao et bon dimanche
        
        [^] # Re: pas compris
        
        Posté par Thomas Douillard le 07 juillet 2019 à 18:17. Évalué à 2.
        
        (rep au PS) calme toi, son message a juste à l’instant ou je répond un seul vote positif, alors que le tiens à un vote positif et un vote négatif. Faut pas trop tirer de conclusions sur si peu de votes, si ça se trouve le vote négatif de ton post est de quelqu’un qui a cliqué à côté ;)
        
        Sinon les notes sont influencées par l’ancienneté du compte et les votes passé. Tu as peu commenté donc tu es noté par défaut à 0, alors que Stéphane est plus ancien ici et démarre à +2 grâce à l’historique des votes positifs de ses anciens commentaires, cf. https://linuxfr.org/wiki/karma
# internet broke today

Posté par tinodeleste le 04 juillet 2019 à 17:50. Évalué à -1. Dernière modification le 04 juillet 2019 à 17:50.

moi qui pensait que ca allait parler de çà :-)
https://arstechnica.com/information-technology/2019/07/facebook-cloudflare-microsoft-and-twitter-suffer-outages/
# « Internet est cassé » ou plutôt : comment diagnostiquer le problème

Posté par Vincent Danjean le 09 juillet 2019 à 09:57. Évalué à 2.
J'avoue qu'après le titre et surtout le premier paragraphe (finissant par "identifier le problème"), j'ai été déçu par la fin de l'article. Je n'ai pas le temps de refaire un article complet, mais voici les pistes que j'utilise personnellement quand "internet est cassé".
1. vérifier que j'ai une IP (wifi ou filaire) ip a nm-applet (et /var/log/syslog pour savoir pourquoi la connexion wifi ne s'établit pas le cas échéant)
2. récupération de la gateway ip r
3. test du ping de la gateway (peut ne pas marcher si la gateway les filtre).
  Sur un routeur, il faut se méfier des règles de firewall/nat
  iptables -L iptables -L -t nat ip rule (Pour les cas plus complexes)
  Si tout est ok jusque là, alors c'est plutôt un pb réseau que local à la machine.
4. test du DNS
  ping sur 8.8.8.8 ping sur la/les adresses dans /etc/resolv.conf dig pour vraiment tester le serveur DNS
5. traceroute/ping pour identifier à quel distance se trouve le pb réseau
6. telnet (ou les autres commandes de l'article) si une appli particulière ne fonctionne pas (ça peut être firefox) et vérifier les filtrages.
7. et tout recommencer avec ipv6
  ip -6 a ip -6 r ip6tables -L ping6 fe80::XXXX:YYYY%ethZ ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.