Pourquoi ne puis-je pas cingler une adresse sur le périphérique de bouclage sous FreeBSD?

10

De Wikipédia :

L'adresse IP la plus couramment utilisée sur le périphérique de bouclage est 127.0.0.1 pour IPv4, bien que toute adresse comprise entre 127.0.0.0 et 127.255.255.255 lui soit mappée.

Ce n'est pas vrai, du moins sur FreeBSD:

$ ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
ping: sendto: Can't assign requested address

Ce comportement est-il correct?

networking freebsd ipv4 loopback Eugene Yarmash
la source

Réponses:

9

FreeBSD (également OS X, et je crois que NetBSD et OpenBSD) répondra aux demandes envoyées aux adresses configurées sur l'interface de bouclage, tout comme pour les adresses sur toute autre interface - Si vous voulez une réponse, vous devez d'abord attribuer l'adresse :

mgraziano@monitor ~]$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
    inet6 ::1 prefixlen 128 
    inet 127.0.0.1 netmask 0xff000000 
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

[mgraziano@monitor ~]$ ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
ping: sendto: Can't assign requested address
^C

[mgraziano@monitor ~]$ sudo ifconfig lo0 alias 127.1.1.1 netmask 0xFFFFFFFF

[mgraziano@monitor ~]$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
    inet6 ::1 prefixlen 128 
    inet 127.0.0.1 netmask 0xff000000 
    inet 127.1.1.1 netmask 0xffffffff 
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

[mgraziano@monitor ~]$ ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
64 bytes from 127.1.1.1: icmp_seq=0 ttl=64 time=0.020 ms
^C

Sur la logique derrière cette implémentation, voir RFC 3330 :

127.0.0.0/8 - Ce bloc est attribué pour être utilisé comme
adresse de bouclage de l' hôte Internet . Un datagramme envoyé par un protocole de niveau supérieur à une
adresse n'importe où dans ce bloc doit reboucler à l'intérieur de l'hôte.
Ceci est généralement implémenté en utilisant uniquement 127.0.0.1/32 pour le bouclage ,
mais aucune adresse dans ce bloc ne devrait jamais apparaître sur un réseau
où que ce soit [ RFC1700 , page 5].

(c'est moi qui souligne)
Linux et Windows sont "utiles" ici, mais de la part de mon président, répondre à une demande envoyée à une adresse non attribuée à cet hôte n'est pas un comportement correct ...

voretaq7
la source
7

Je vois le même comportement que vous décrivez sur FreeBSD 8.1. Mac OS X, qui partage un peu d'ADN avec FreeBSD, ne semble également mapper que 127.0.0.1.

Windows 7 et Linux (Debian avec le noyau 2.6.26) semblent tous deux mapper la plage d'adresses complète comme vous le décrivez dans la citation de Wikipédia (et comme prescrit dans la RFC).

Pour citer la RFC 3330:

127.0.0.0/8 - Ce bloc est attribué pour être utilisé comme adresse de bouclage de l'hôte Internet. Un datagramme envoyé par un protocole de niveau supérieur à une adresse n'importe où dans ce bloc doit reboucler à l'intérieur de l'hôte. Ceci est généralement implémenté en utilisant uniquement 127.0.0.1/32 pour le bouclage, mais aucune adresse dans ce bloc ne devrait jamais apparaître sur un réseau où que ce soit [RFC1700, page 5].

Selon la façon dont vous interprétez strictement le mot «devrait», certains pourraient faire valoir que le comportement de FreeBSD / MacOS est incorrect. Mais étant donné l'utilisation omniprésente de 127.0.0.1 en tant qu'adresse de bouclage, je doute que cela ait de l'importance.

eaj
la source
3
+1 Par défaut, seul 127.0.0.1 est affecté à lo0. Bien que vous puissiez certainement ajouter le reste; Je ne peux pas imaginer de nombreuses situations où cela importerait.
Chris S
Cela dépend également de la façon dont vous interprétez la «boucle à l'intérieur de l'hôte». Est-ce que cela signifie par nature que le datagramme sera livré dans un endroit significatif; ou simplement ce qui suit dans le RFC, que le datagramme ne sera pas livré à un autre hôte sur le réseau. (Je serais d'accord avec FreeBSD et Darwin, ce dernier)
Chris S
Cela dépend également de la façon dont vous voyez la «justesse» de répondre aux demandes sur une adresse qui ne vous est pas explicitement attribuée. à l'exception peut-être des demandes de diffusion.
voretaq7
+1 également pour avoir cité le même RFC que moi :)
voretaq7
2
@ voretaq7 Je l'ai totalement cité en premier. :)
2011
0

C'est contre la tendance. N'ayez pas de boîte FreeBSD à portée de main pour confirmer si c'est FreeBSD ou votre configuration.

Le RFC dit 127.0.0.1/24 - donc il devrait répondre.

SuperBOB
la source
1
En fait, la RFC indique 127.0.0.0/8, mais ne spécifie pas quelle (s) adresse (s) spécifique (s) dans cette plage à utiliser: par convention, la première adresse utilisable dans cette plage (127.0.0.1) est affectée comme localhost, mais vous pouvez utiliser 127.32 .194.75 dans votre propre implémentation de système d'exploitation si vous le souhaitez. (Cela pourrait cependant vous faire lyncher par des administrateurs système en colère…)
voretaq7
0

On a répondu à la question environ trois fois maintenant, donc je voulais juste ajouter quelques cents.

Notez que pendant un certain temps, la configuration ipfw par défaut supprime ce type de paquets:

./rc.firewall:  ${fwcmd} add 100 allow ip from any to any via lo0
./rc.firewall:  ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any

donc avec un pare-feu activé au lieu de

ping: sendto: Can't assign requested address

Vous pourriez obtenir

[savetherbtz@PH34R ~]$ ping 127.0.0.2
PING 127.0.0.2 (127.0.0.2): 56 data bytes
ping: sendto: Permission denied

PS. Bien sûr, il peut y avoir un serveur construit sans INET(support IPv4) et vous n'aurez même pas 127.0.0.1=)

SaveTheRbtz
la source