0.0.0.0:0 et *: * représentent-ils la même chose?

23

J'ai utilisé netstat (sous Windows) pour afficher les ports écoutés pour TCP et UDP:

J'ai remarqué que dans la colonne Adresse étrangère , UDP s'affiche *:*au lieu de 0.0.0.0:0, ces deux valeurs représentent-elles la même chose? Si oui, alors pourquoi UDP s'affiche-t-il *:*au lieu de 0.0.0.0:0?

windows networking netstat

— user612473
source

Je crois que *:*c'est IPv6 tandis 0.0.0.0:0qu'IPv4.

— LPChip

J'ai également remarqué ce qui suit: UDP 0.0.0.0:5355 *:*cela signifie-t-il que des données peuvent être envoyées entre IPv4 et IPv6?

— user612473

regardez ici: security.stackexchange.com/questions/13724/…

— marsh-wiggle

4

l'équivalent IPv6 de 0.0.0.0 est [::]

— marsh-wiggle

2

@LPChip Vous vous trompez. *:*ne dit rien sur la version IP. Cependant, étant donné que l'adresse locale de ce socket est IPv4 uniquement, l'adresse distante doit également être IPv4.

— kasperd

12

Il a été souligné que ma réponse était erronée. Comme je ne peux pas le supprimer, je fournirai à la place le bon.

L'expression *:*signifie "N'importe quelle adresse, n'importe quel port". Tous les écouteurs UDP afficheront cette signature. Cela est dû à la nature sans connexion d'UDP.

Réponse originale (incorrecte). Oui et non. *:*fait référence à TOUTE adresse IPv6. La distinction entre une adresse inconnue / non spécifiée est vague dans IPv4, nous utilisons donc 0.0.0.0/0 pour représenter n'importe quel hôte sur le réseau, mais dans IPv6 il y a une différence subtile.

Cependant, pour la plupart, les gens utilisent ::pour représenter une chaîne contiguë de 0.

Dans une adresse IPv6, toute séquence de zéros contigus peut être remplacée par :: :

0.0.0.0/0=> 0000: 0000: 0000: 0000: 0000: 0000: 0000: 0000 => ::=>*:*
fe80:0000:0000:0000:2000:0aff:fea7:0f7c => fe80::2000:0aff:fea7:0f7c

La représentation à l'aide de caractères génériques permet cependant un contrôle plus fin des modèles d'adresse. Par exemple, ::ne correspondrait pas fe80::2000:0aff:fea7:0f7c, mais le *:*sera.

Cette différence n'est pas vraiment significative pour tout appareil qui n'effectue pas de routage, mais quand vient le temps de sélectionner des itinéraires optimaux vers des espaces d'adressage agrégés, la notation générique permet une sélection plus flexible des réseaux de destination.

— Frank Thomas
source

5

Mais vous avez écrit dans votre réponse que *:* refers to ANY IPv6 address vous dites ici, c'est-à-dire any..addressprobablement IPv4 ou IPv6. Alors c'est quoi? Se *:*limite- t -il à IPv6 ou autorise-t-il également IPv4?

— barlop

2

Les deux sockets mentionnés dans la question sont uniquement IPv4. Vous pouvez le voir à partir de l'adresse locale attribuée à chaque socket. En tant que tel, mentionner IPv6 n'est pas pertinent pour la question.

— kasperd

7

IPv6 n'est pas du tout pertinent pour cette question.

— hobbs

8

Cette réponse est totalement fausse pour la question posée.

— Brad

3

Comme le note le commentaire de Kasperd (et le commentaire de Hobbs aussi), IPv6 n'est pas lié à la question. La question porte sur ce que nous voyons dans la colonne Adresse étrangère, ce qui correspond à ce qui se trouve dans les mêmes lignes dans la colonne Adresse locale, qui est IPv4. (Bien que, avec certains systèmes d'exploitation, l'écoute sur une famille d'adresses / version IP puisse généralement écouter automatiquement sur une autre famille d'adresses.)

— TOOGAM

15

Le /fait référence au masque de sous-réseau, qui fait partie de la couche IP.

Le :fait référence à un port qui fait partie de la couche de transport.

Pour TCP, il est logique qu'il existe une extrémité distante pour une connexion.

UDP, car il est sans connexion, cela n'a aucun sens pour lui d'afficher une adresse étrangère.

Mon intuition est que cela afficherait toujours le caractère générique pour UDP et qu'il est potentiellement là pour rendre l'analyse de la sortie un peu plus conviviale, ou pour montrer si vous utilisez IPv4 / 6:

IPV4 "*:*" contre IPV6 "[::]:*"

— Luke Exton
source

Je disais ça à quelques amis. Vous pouvez afficher des PORTS en écoute, mais afficher des sessions distantes réelles lorsqu'il n'y en a pas est probablement la raison pour laquelle il s'affiche comme *:*pour les sessions UDP distantes inexistantes. Je suis d'accord avec vous ici.

— NotAdmin Dave

6

Dans les deux cas, les informations sont essentiellement dénuées de sens, mais indiquent plus ou moins la même chose.

Votre première ligne est un socket d'écoute TCP. La colonne d'adresse locale indique l'adresse et le port sur lesquels elle accepte les connexions, et la colonne d'adresse distante ne signifie rien car un socket d'écoute n'a pas encore d'extrémité distante de la connexion. Un socket TCP connecté afficherait l'adresse de l'autre extrémité de la connexion dans cette colonne, mais pour un socket d'écoute, il décide d'afficher une adresse et un port entièrement nuls.

Votre deuxième ligne est un socket UDP. UDP est un protocole sans connexion, ce qui signifie qu'il envoie et reçoit des paquets sans aucune idée de qui s'est connecté à qui, que le paquet fasse partie d'une conversation existante ou que les données viennent d'arriver à l'improviste. La colonne d'adresse locale a la même signification que pour TCP, et la colonne d'adresse distante n'a pas de sens car un socket UDP peut avoir un homologue, plusieurs homologues ou aucun homologue à tout moment. (En fait, POSIX a la notion de "socket UDP connecté" mais cela va un peu loin).

Maintenant, la question: pourquoi affichent-ils différemment? Il semble n'être rien de plus qu'une bizarrerie du code Windows Netstat. Linux (net-tools) netstat s'affiche 0.0.0.0:*pour l'extrémité distante des sockets d'écoute TCP et des sockets UDP (pour IPv4; il s'affiche :::*pour IPv6), ce qui est différent des deux exemples sous Windows, mais au moins il est cohérent au sein du même programme. Peut-être que Windows opte pour une distinction sémantique entre "à remplir ultérieurement" dans le cas de TCP et "ouvert à tout" dans le cas d'UDP, mais tout aussi probable que les deux bits de code ont été écrits par deux personnes différentes sans souci particulier de cohérence.

— Hobbs
source

+1 pour le début du 4ème paragraphe. La version 0.0.0.0 contient de la documentation: Une adresse de tous les zéros est l'adresse "non spécifiée" (selon la norme IPv6 Addressing RFC 4291 sec 2.5.2 ), s'appliquant souvent à des adresses inconnues. La page 4 de la RFC 1700 mentionne "Ne peut être utilisée qu'en tant qu'adresse source", et la section "a" de la RFC 1122 # page-29 décrit l'utilisation plus en détail. ( ma réponse sur ::: mentionne 0.0.0.0)

— TOOGAM

La 0.0.0.0:0valeur dans la colonne Adresse étrangère ne signifie- t-elle pas que n'importe quelle adresse IP et numéro de port peut envoyer des données à ce socket? et si cette valeur était par exemple 127.0.0.0:12345, cela signifie que seule l'adresse IP 127.0.0.0avec le numéro de port 12345peut envoyer des données à ce socket et personne d'autre?

— Tom

6

La différence est simplement notée.

Netstat dans Windows utilise 0.0.0.0:0pour représenter une idée abstraite de "toute adresse et port distants" pour un écouteur TCP IPv4 local et *:*pour un écouteur UDP. Pour IPv6, l'adresse distante est indiquée par [::]:0TCP et *:*UDP.

Sous OS X, *.*est utilisé à la fois pour TCP et UDP, que ce soit IPv4 ou IPv6 (notez que OS X utilise des points pour séparer l'adresse et le port). Linux utilise 0.0.0.0:*pour IPv4 et :::*pour IPv6, les deux premiers deux-points représentant l'abréviation de toutes les adresses IPv6 et le troisième deux-points le séparateur entre l'adresse et le port.

IIRC d'après quelque chose que j'ai entendu ou lu il y a longtemps, je pense que les paires UDP peuvent apparaître, mais généralement pas parce qu'elles sont détruites à la fin et que les connexions UDP sont généralement très courtes, en millisecondes ou moins. Je n'ai jamais vu cela moi-même, donc cela pourrait être incorrect.

— NetworkLlama
source