Pourquoi la requête ping 192.168.072 (seulement 2 points) renvoie-t-elle une réponse de 192.168.0.58?
J'ai manqué par erreur le point d'une adresse IP et tapé dans 192.168.072.
À ma grande surprise, je me suis connecté à une machine à 192.168.0.58
Si je coche 192.168.072, je reçois des réponses de 192.168.0.58.
Pourquoi est-ce?
Je suis sur un PC Windows sur un domaine Windows.
Si je lance un ping sur 192.168.72, je reçois une réponse de 192.168.0.72. Il semble donc que le 0 dans 072 (dans mon erreur initiale) est significatif.
Cette question était uneQuestion de la semaine concernant le super utilisateur.
Lisez l’entréedu blogpour plus de détails oucontribuez au blogvous-même
Tout le monde complique à l'excès avec les RFC, les classes IP, etc. Exécutez simplement quelques tests pour voir comment la commande ping analyse l’adresse IP saisie par l’utilisateur (absence de paillettes):
> ping 1
Pinging 0.0.0.1 with 32 bytes of data:
> ping 1.2
Pinging 1.0.0.2 with 32 bytes of data:
> ping 1.2.3
Pinging 1.2.0.3 with 32 bytes of data:
> ping 1.2.3.4
Pinging 1.2.3.4 with 32 bytes of data:
> ping 1.2.3.4.5
Ping request could not find Host 1.2.3.4.5. Please check the name and try again.
> ping 255
Pinging 0.0.0.255 with 32 bytes of data:
> ping 256
Pinging 0.0.1.0 with 32 bytes of data:
Comme vous pouvez le constater, la commande ping (sous Windows) vous permet d’utiliser différents formats d’adresse IP. Une adresse IPv4 peut être décomposée en quatre parties («en pointillé») ainsi: A.B.C.D, et la commande ping vous permet de laisser de côté, en remplissant la valeur par défaut 0 comme suit:
1 part (ping A) : 0.0.0.A
2 parts (ping A.B) : A.0.0.B
3 parts (ping A.B.C) : A.B.0.C
4 parts (ping A.B.C.D) : A.B.C.D
Si vous ne fournissez qu'une seule partie, si elle est inférieure à 255 (le maximum pour un octet), elle est traitée comme un octet comme ci-dessus, mais si elle est supérieure à 255, elle est convertie et transférée dans le champ suivant. (ie, mod 256).
Il existe quelques cas Edge, par exemple, si la fourniture de plus de quatre parties ne semble pas fonctionner (par exemple, la requête ping de l’adresse IP de google.com ne fonctionnera pas pour 0.74.125.226.4 ou 74.125.226.4.0).
Vous pouvez également utiliser la notation hexadécimale à la fois en pointillé et quadruple, mais vous devez la formater par 0x en attente à chaque octet.
Il existe donc de nombreuses façons de représenter une adresse IP (IPv4). Vous pouvez utiliser le format plat ou quadruple pointillé (ou triple pointillé, double pointillé ou même simple pointé) et vous pouvez utiliser (ou même mélanger et assortir) décimal, octal et hexadécimal pour chacun. Par exemple, vous pouvez effectuer un ping sur google.com des manières suivantes:
google.com(nom de domaine)74.125.226.4(décimal en pointillé)1249763844(décimal plat)0112.0175.0342.0004(octal en pointillé)011237361004(octal plat)0x4A.0x7D.0xE2.0x04(hex en pointillé)0x4A7DE204(hexa plat)74.0175.0xe2.4(ಠ_ಠ)
(Dieu merci, le support de la notation binaire n'a pas été ajouté!)
Application :
Dans votre cas, la commande ping 192.168.072 utilise le troisième format du tableau ci-dessus (A.B.0.C). Vous effectuez donc une commande ping 192.168.0.072. De plus, étant donné que vous avez un zéro initial sur la dernière partie, elle est traitée comme une valeur octale, ce qui en décimal est 58.
Mystère résolu.
Notez que si la commande Windows ping autorise une telle variété de formats pour l’entrée et interprète les formats non standard de la manière décrite, cela ne signifie pas nécessairement que vous pouvez utiliser ces formats partout. Certains programmes peuvent vous obliger à fournir les quatre parties d’un quad pointillé, d’autres ne permettent pas de mélanger et d’apparier décimal et octal, et ainsi de suite.
De plus, les adresses IPv6 compliquent davantage la logique d'analyse et l'acceptabilité du format d'entrée.
Addendum :
syss a souligné que si vous utilisez un caractère non valide dans l'un des chiffres (par exemple, un 8 ou un 9 lorsque vous utilisez octal, un g en mode hexadécimal, etc.), alors ping est suffisamment intelligent pour le reconnaître et l'interpréter c'est une URL de chaîne (-al? -ic?) au lieu d'une adresse IP numérique.
(En tant que personne qui a eu de nombreux anévrismes et crises cardiaques en essayant d’écrire du code soi-disant «simple» pour tenir compte du nombre en expansion exponentielle de permutations de valeurs de données, j’apprécie qu’il - semble-le - traite correctement toutes les variations d’entrée; cas, au moins 31+32+33+34= 120 variations.)
Ainsi, si vous spécifiez 010.020.030.040, le ping 8.16.24.32 sera exécuté comme prévu, le passage de 010.020.030.080 à ping sera traité comme une URL au lieu d'une adresse IP, comme foo.bar.baz.com qui pourrait (mais n'existe malheureusement pas). En d'autres termes, il essaie d'envoyer une requête ping au sous-domaine 010 sur le sous-domaine 020 sur le domaine 030 dans le domaine de niveau supérieur 080. Cependant, étant donné que 080 n'est pas un TLD valide (comme .com, .net et leurs amis), la connexion échoue dès la première étape.
La même chose se produit avec 090.010.010.010 où le caractère non valide est dans un octet différent. De même, 0xf.0xf.0xf.0xf pings 15.15.15.15, mais 0xh1.0x1.0xg0.0f échoue.
Oh, eh bien, je suppose que c’est ce que vous obtenez de ne pas parler couramment plusieurs bases de nombres.
C’est probablement plus facile et plus sûr de s’assurer de toujours utiliser des adresses à 4 points («40q»? «Quaddy-quad»? «Cutie-q»?).
Alors allez-y et apprenez quelques bases numériques . Vous pourrez montrer et être la vie de fêtes, et comme on dit, il existe 10 types de personnes: celles qui connaissent le binaire et celles qui ne le connaissent pas.
Ne pensons même pas {pensez} _ à propos des adresses IPv6; Je pense qu’ils font partie des 111 phoques !!!
Il y a deux raisons à cela:
Tout d'abord, un préfixe "0" indique un nombre octal . Depuis oct (072) = déc (58), 192.168.072 = 192.168.58.
Deuxièmement, l'avant-dernier 0 peut être supprimé des adresses IP sous la forme d'un raccourci . 127.0.1 est interprété comme 127.0.0.1 et dans votre cas, 192.168.58 est interprété comme 192.168.0.58.
Outre le point important de @ neu242 sur la notation octale et l'observation selon laquelle les adresses IP peuvent être raccourcies, l'autre élément essentiel consiste à savoir comment les adresses IP réduites sont interprétées.
On pourrait nier naïvement que si l’un des quatre nombres manque, l’analyseur ajoute des octets remplis de zéros à la fin (ou au début) de la séquence d’octets. Mais cela ne correspond pas au comportement signalé par le PO: 192.168.072 a été analysé comme 192.168. 0 . 58, pas comme 192.168.58. 0 , ni 0 . 192.168.58.
Apparemment, Windows et Linux ping (la version que vous avez essayée et celles que j'ai essayées) utilisent quelque chose d'équivalent à inet_aton () pour analyser l'argument d'adresse IP. La page de manuel de inet_aton () dit:
The address supplied in cp can have one of the following forms:
a.b.c.d Each of the four numeric parts specifies a byte of the address; the
bytes are assigned in left-to-right order to produce the binary
address.
a.b.c Parts a and b specify the first two bytes of the binary address.
Part c is interpreted as a 16-bit value that defines the rightmost
two bytes of the binary address. This notation is suitable for
specifying (outmoded) Class B network addresses.
a.b Part a specifies the first byte of the binary address. Part b is
interpreted as a 24-bit value that defines the rightmost three bytes
of the binary address. This notation is suitable for specifying
(outmoded) Class C network addresses.
a The value a is interpreted as a 32-bit value that is stored directly
into the binary address without any byte rearrangement.
Donc, voilà ... 192.168.072 correspond au modèle a.b.c, de sorte que le 072 (après l'analyse en tant que nombre octal) a été interprété comme une valeur de 16 bits définissant les 2 octets les plus à droite de l'adresse binaire, ce qui correspond à 0.58.
Les règles ci-dessus équivalent à dire que si l'un des quatre numéros est manquant, les octets remplis à zéro nécessaires sont ajoutés immédiatement avant le dernier numéro donné... pas à la fin ni au début de la chaîne d'octets. (En l'exprimant de cette façon, cela fonctionne si le dernier nombre donné est inférieur à 256.)
Notez que les versions plus récentes de ping peuvent ne pas autoriser ce type de raccourci, ni l'interprétation octale. Le code source 2010 pour iputils (y compris le ping) que j'ai trouvé utilise inet_pton () plutôt que inet_aton () pour analyser l'argument d'adresse IP. La page de manuel de inet_pton () dit:
Contrairement à inet_aton (3) et à inet_addr (3), inet_pton () prend en charge les adresses IPv6. Par ailleurs, inet_pton () accepte uniquement les adresses IPv4 en notation décimale à points, alors que inet_aton (3) et inet_addr (3) autorisent la notation plus générale par les nombres et les points (formats de nombre hexadécimal et octal et les formats qui ne t exigent que les quatre octets soient explicitement écrits).
Vous devez également considérer qu'une adresse IP peut être représentée par des entiers additionnés de manière significative pour leur position.
192.168.0.58 is :
192 * 256^3
+ 168 * 256^2
+ 0 * 256^1
+ 58 * 256^0
Voici la chose cool:
192.168.58 sera 192.168.0.58 car
0 * 256^1
+ 58 * 256^0
= 58
192.11010106 sera également 192.168.0.58 car
168 * 256^2
+ 0 * 256^1
+ 58 * 256^0
= 11010106
3232235578 sera également 192.168.0.58 car
192 * 256^3
+ 168 * 256^2
+ 0 * 256^1
+ 58 * 256^0
= 3232235578