Dlaczego nie mogę pingować adresu na urządzeniu z pętlą zwrotną w FreeBSD?

10

Najczęściej używany adres IP w urządzeniu pętli zwrotnej to 127.0.0.1 dla IPv4, chociaż dowolny adres z zakresu od 127.0.0.0 do 127.255.255.255 jest do niego odwzorowany.

To nie jest prawda, przynajmniej na 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

Czy to jest prawidłowe zachowanie?

— Eugene Yarmash
źródło

9

FreeBSD (także OS X i wierzę, że NetBSD i OpenBSD) będzie odpowiadać na żądania wysyłane na skonfigurowane adresy w interfejsie sprzężenia zwrotnego, tak jak w przypadku adresów na dowolnym innym interfejsie - jeśli chcesz uzyskać odpowiedź, najpierw musisz przypisać adres :

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

Logikę tej implementacji można znaleźć w RFC 3330 :

127.0.0.0/8 - Blok ten jest przypisany do użycia jako
adres zwrotny hosta internetowego . Datagram wysłany przez protokół wyższego poziomu na
adres w dowolnym miejscu tego bloku powinien zapętlić się z powrotem w hoście.
Zwykle jest to realizowane za pomocą tylko 127.0.0.1/32 dla pętli zwrotnej ,
ale żadne adresy w tym bloku nigdy nie powinny pojawiać się w żadnej sieci w
dowolnym miejscu [ RFC1700 , strona 5].

(moje podkreślenie)
Linux i Windows są tutaj „pomocne”, jednak moje krzesło odpowiada na prośbę wysłaną na adres nieprzypisany do tego hosta nie jest poprawnym zachowaniem ...

— voretaq7
źródło

7

Widzę to samo zachowanie, które opisujesz w FreeBSD 8.1. Mac OS X, który dzieli część DNA z FreeBSD, wydaje się mapować tylko 127.0.0.1.

Windows 7 i Linux (debian z jądrem 2.6.26) wydają się mapować pełny zakres adresów, jak opisano w cytacie z Wikipedii (i zgodnie z zaleceniami RFC).

Cytat z RFC 3330:

127.0.0.0/8 - Blok ten jest przypisany do użycia jako adres zwrotny hosta internetowego. Datagram wysłany przez protokół wyższego poziomu na adres w dowolnym miejscu tego bloku powinien zapętlić się z powrotem w hoście. Zwykle jest to realizowane za pomocą tylko 127.0.0.1/32 dla pętli zwrotnej, ale żadne adresy w tym bloku nigdy nie powinny pojawiać się w żadnej sieci w dowolnym miejscu [RFC1700, strona 5].

W zależności od tego, jak ściśle interpretujesz słowo „powinno”, niektórzy mogą uznać, że zachowanie FreeBSD / MacOS jest nieprawidłowe. Ale biorąc pod uwagę wszechobecne użycie 127.0.0.1 jako adresu sprzężenia zwrotnego, wątpię, czy to ma znaczenie.

— eaj
źródło

3

+1 Domyślnie tylko 127.0.0.1 jest przypisane do lo0. Chociaż na pewno możesz dodać resztę; Nie wyobrażam sobie wielu sytuacji, w których miałoby to znaczenie.

— Chris S

Zależy to również od tego, jak interpretujesz „zapętlenie z powrotem w hoście”. Czy to z natury oznacza, że datagram zostanie dostarczony gdzieś znaczący; lub po prostu, co następuje w RFC, że datagram nie zostanie dostarczony do innego hosta w sieci. (Zgodziłbym się z FreeBSD i Darwinem, tym ostatnim)

— Chris S

Zależy to również od tego, jak postrzegasz „poprawność” odpowiedzi na prośby o adres, który nie został do ciebie wyraźnie przypisany - zawsze uważałem, że jeśli adres nie zostanie Ci przypisany, nie będziesz wysyłał odpowiedzi biznesowych, jak gdyby były twoje, z możliwym wyjątkiem żądań transmisji.

— voretaq7

Również +1 za cytowanie tego samego RFC, co zrobiłem :)

— voretaq7

2

@ voretaq7 Najpierw całkowicie to zacytowałem. :)

— eaj,

0

Przełamuje trend. Nie masz pod ręką pudełka FreeBSD, aby potwierdzić, czy jest to FreeBSD, czy twoja konfiguracja.

RFC mówi 127.0.0.1/24 - więc powinno odpowiadać.

— SuperBOB
źródło

1

Właściwie RFC mówi 127.0.0.0/8, ale nie określa, który konkretny adres (adresy) w tym zakresie użyć: zgodnie z konwencją pierwszy użyteczny adres w tym zakresie (127.0.0.1) jest przypisany jako localhost, ale można użyć 127.32 .194.75 we własnej implementacji systemu operacyjnego, jeśli chcesz. (Może to jednak doprowadzić do zlinczowania przez gniewnych administratorów…)

— voretaq7

0

Odpowiedź na pytanie jest w tej chwili wyczerpana trzy razy, więc chciałem tylko dodać kilka centów.

Zauważ, że od dłuższego czasu domyślna konfiguracja ipfw upuszcza tego rodzaju pakiety:

./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

więc z włączoną zaporą ogniową zamiast

ping: sendto: Can't assign requested address

możesz dostać

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

PS. Oczywiście można zbudować serwer bez INET(obsługa IPv4) i nie będziesz mieć nawet 127.0.0.1=)

— SaveTheRbtz
źródło