Perché non posso eseguire il ping di un indirizzo sul dispositivo di loopback sotto FreeBSD?

10

L'indirizzo IP più comunemente usato sul dispositivo di loopback è 127.0.0.1 per IPv4, sebbene qualsiasi indirizzo compreso tra 127.0.0.0 e 127.255.255.255 sia mappato su di esso.

Questo non è vero, almeno su 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

Questo comportamento è corretto?

— Eugene Yarmash
fonte

9

FreeBSD (anche OS X, e credo che NetBSD e OpenBSD) risponderanno alle richieste inviate agli indirizzi configurati sull'interfaccia di loopback, proprio come farebbero per gli indirizzi su qualsiasi altra interfaccia - Se vuoi una risposta devi prima assegnare l'indirizzo :

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

Sulla logica dietro questa implementazione, vedi RFC 3330 :

127.0.0.0/8 - Questo blocco è assegnato per l'uso come
indirizzo di loopback dell'host Internet . Un datagramma inviato da un protocollo di livello superiore a un
indirizzo in qualsiasi punto di questo blocco dovrebbe tornare indietro all'interno dell'host.
Questo è normalmente implementato usando solo 127.0.0.1/32 per il loopback ,
ma nessun indirizzo all'interno di questo blocco dovrebbe mai apparire su nessuna rete
ovunque [ RFC1700 , pagina 5].

(enfasi mia)
Linux e Windows sono "utili" qui, tuttavia dalla mia sedia rispondere a una richiesta che è stata inviata a un indirizzo non assegnato a questo host non è un comportamento corretto ...

— voretaq7
fonte

7

Vedo lo stesso comportamento che descrivi su FreeBSD 8.1. Anche Mac OS X, che condivide un po 'di DNA con FreeBSD, sembra mappare solo 127.0.0.1.

Windows 7 e Linux (debian con kernel 2.6.26) sembrano entrambi mappare l'intero intervallo di indirizzi come descritto nella citazione di Wikipedia (e come prescritto nella RFC).

Per citare da RFC 3330:

127.0.0.0/8 - Questo blocco è assegnato per l'uso come indirizzo di loopback dell'host Internet. Un datagramma inviato da un protocollo di livello superiore a un indirizzo in qualsiasi punto di questo blocco dovrebbe tornare indietro all'interno dell'host. Questo è normalmente implementato usando solo 127.0.0.1/32 per il loopback, ma nessun indirizzo all'interno di questo blocco dovrebbe mai apparire su nessuna rete ovunque [RFC1700, pagina 5].

A seconda del modo in cui interpreti la parola "dovrebbe", alcuni potrebbero ipotizzare che il comportamento di FreeBSD / MacOS sia errato. Ma dato l'onnipresente uso di 127.0.0.1 come indirizzo di loopback, dubito che probabilmente avrà importanza.

— EAJ
fonte

3

+1 Di default solo 127.0.0.1 è assegnato a lo0. Anche se puoi sicuramente aggiungere il resto; Non riesco a immaginare molte situazioni in cui avrebbe importanza.

— Chris S,

Dipende anche da come interpreti "loop back all'interno dell'host". Ciò significa intrinsecamente che il datagramma verrà consegnato in qualche luogo significativo; o semplicemente ciò che segue nella RFC, che il datagramma non verrà consegnato a un altro host sulla rete. (Concordo con FreeBSD e Darwin, quest'ultimo)

— Chris S,

Dipende anche da come vedi la "correttezza" di rispondere alle richieste su un indirizzo che non ti è stato assegnato esplicitamente. Ho sempre pensato che se l'indirizzo non ti è stato assegnato non avresti alcuna attività di invio di risposte come se fosse la tua, con la possibile eccezione delle richieste di trasmissione.

— voretaq7,

Inoltre +1 per citare lo stesso RFC che ho fatto :)

— voretaq7

2

@ voretaq7 L'ho completamente citato per primo. :)

— EAJ

0

Sta in controtendenza. Non avere una scatola di FreeBSD a portata di mano per confermare se si tratta di FreeBSD o della tua configurazione.

La RFC dice 127.0.0.1/24 - quindi dovrebbe rispondere.

— SuperBOB
fonte

1

In realtà la RFC dice 127.0.0.0/8, ma non specifica quali indirizzi specifici in quell'intervallo usare: per convenzione il primo indirizzo utilizzabile in quell'intervallo (127.0.0.1) è assegnato come localhost, ma potresti usare 127.32 .194.75 nella propria implementazione del sistema operativo, se lo si desidera. (Ciò potrebbe tuttavia farti linciare dagli amministratori di sistema arrabbiati ...)

— voretaq7

0

Ormai è stata data una risposta completa alla domanda circa tre volte, quindi volevo solo aggiungere qualche centesimo.

Si noti che per un po 'di tempo la configurazione ipfw predefinita elimina questo tipo di pacchetti:

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

quindi con il firewall abilitato anziché

ping: sendto: Can't assign requested address

potresti ottenere

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

PS. Di causa può esserci un server senza INET(supporto IPv4) e non avrai nemmeno 127.0.0.1=)

— SaveTheRbtz
fonte