Warum kann ich unter FreeBSD keine Adresse auf dem Loopback-Gerät anpingen?

10

Die am häufigsten verwendete IP-Adresse auf dem Loopback-Gerät ist 127.0.0.1 für IPv4, obwohl ihm jede Adresse im Bereich von 127.0.0.0 bis 127.255.255.255 zugeordnet ist.

Dies ist zumindest bei FreeBSD nicht der Fall:

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

Ist das richtig?

— Eugene Yarmash
quelle

9

FreeBSD (auch OS X, und ich glaube, NetBSD & OpenBSD) reagiert auf Anforderungen, die an konfigurierte Adressen auf der Loopback-Schnittstelle gesendet werden, genau wie bei Adressen auf jeder anderen Schnittstelle. Wenn Sie eine Antwort wünschen, müssen Sie zuerst die Adresse zuweisen ::

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

Zur Logik dieser Implementierung siehe RFC 3330 :

127.0.0.0/8 - Dieser Block wird zur Verwendung als Internet-Host-
Loopback-Adresse zugewiesen . Ein Datagramm, das von einem übergeordneten Protokoll an eine
Adresse an einer beliebigen Stelle in diesem Block gesendet wird , sollte innerhalb des Hosts zurückgeschleift werden.
Dies wird normalerweise nur mit 127.0.0.1/32 für Loopback implementiert ,
aber es sollten niemals Adressen in diesem Block in einem Netzwerk
irgendwo erscheinen [ RFC1700 , Seite 5].

(Hervorhebung von mir)
Linux und Windows sind hier "hilfreich", aber von meinem Stuhl aus ist die Beantwortung einer Anfrage, die an eine Adresse gesendet wurde, die diesem Host nicht zugewiesen ist, kein korrektes Verhalten ...

— voretaq7
quelle

7

Ich sehe das gleiche Verhalten, das Sie in FreeBSD 8.1 beschreiben. Mac OS X, das einige DNA mit FreeBSD teilt, scheint ebenfalls nur 127.0.0.1 abzubilden.

Windows 7 und Linux (Debian mit 2.6.26 Kernel) scheinen beide den vollständigen Adressbereich abzubilden, wie Sie im Wikipedia-Zitat (und wie im RFC vorgeschrieben) beschreiben.

Um aus RFC 3330 zu zitieren:

127.0.0.0/8 - Dieser Block wird zur Verwendung als Internet-Host-Loopback-Adresse zugewiesen. Ein Datagramm, das von einem übergeordneten Protokoll an eine Adresse an einer beliebigen Stelle in diesem Block gesendet wird, sollte innerhalb des Hosts zurückgeschleift werden. Dies wird normalerweise nur mit 127.0.0.1/32 für Loopback implementiert, aber es sollten niemals Adressen in diesem Block in einem Netzwerk irgendwo erscheinen [RFC1700, Seite 5].

Abhängig davon, wie streng Sie das Wort "sollte" interpretieren, kann es vorkommen, dass das FreeBSD / MacOS-Verhalten falsch ist. Angesichts der allgegenwärtigen Verwendung von 127.0.0.1 als Loopback-Adresse bezweifle ich jedoch, dass dies wahrscheinlich von Bedeutung ist.

— eaj
quelle

3

+1 Standardmäßig ist lo0 nur 127.0.0.1 zugewiesen. Obwohl Sie sicherlich den Rest hinzufügen können; Ich kann mir nicht viele Situationen vorstellen, in denen es wichtig wäre.

— Chris S

Es hängt auch davon ab, wie Sie "Schleife zurück in den Host" interpretieren. Bedeutet das von Natur aus, dass das Datagramm an einen aussagekräftigen Ort geliefert wird? oder einfach das, was im RFC folgt, dass das Datagramm nicht an einen anderen Host im Netzwerk geliefert wird. (Ich würde FreeBSD und Darwin, letzterem, zustimmen)

— Chris S

Es hängt auch davon ab, wie Sie die "Richtigkeit" der Beantwortung von Anfragen an eine Adresse sehen, die Ihnen nicht explizit zugewiesen wurde. Ich hatte immer das Gefühl, dass Sie, wenn die Adresse Ihnen nicht zugewiesen ist, keine geschäftlichen Antworten senden müssen, als ob es Ihre wäre. mit der möglichen Ausnahme von Broadcast-Anfragen.

— voretaq7

Auch +1 für das Zitieren des gleichen RFC, den ich getan habe :)

— voretaq7

2

@ voretaq7 Ich habe es zuerst total zitiert. :)

— eaj

0

Es widerspricht dem Trend. Halten Sie keine FreeBSD-Box bereit, um zu bestätigen, ob es sich um FreeBSD oder Ihre Konfiguration handelt.

Der RFC sagt 127.0.0.1/24 - also sollte er reagieren.

— SuperBOB
quelle

1

Tatsächlich sagt der RFC 127.0.0.0/8, gibt jedoch nicht an, welche spezifischen Adressen in diesem Bereich verwendet werden sollen: Konventionell wird die erste verwendbare Adresse in diesem Bereich (127.0.0.1) als zugewiesen localhost, aber Sie könnten 127.32 verwenden .194.75 in Ihrer eigenen Betriebssystemimplementierung, wenn Sie möchten. (Dies kann jedoch dazu führen, dass Sie von wütenden

— Sysadmins

0

Die Frage ist ungefähr dreimal vollständig beantwortet, also wollte ich nur ein paar Cent hinzufügen.

Beachten Sie, dass die Standard-ipfw-Konfiguration für einige Zeit Pakete dieser Art verwirft:

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

also mit aktivierter Firewall statt

ping: sendto: Can't assign requested address

Sie könnten bekommen

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

PS. Natürlich kann ein Server ohne INET(IPv4-Unterstützung) erstellt werden und Sie haben nicht einmal 127.0.0.1=)

— SaveTheRbtz
quelle