Dotaz: rozdíl mezi "ping -I INTERFACE" a "ping -I IPAdresa" ?

[Franta Hanzlík]

Vždycky jsem si myslel (a podle man stránek se zdá), že by příkazy:

ping -I eth1 CÍLOVÁIP
a
ping -I ipaddr(eth1) CÍLOVÁIP

měly být ekvivalentní. Ale zdá se nejsou, na Fedora 14 i686 boxu se to chová takto:

# ping -I 10.128.254.2 -c 3 -nn 90.183.38.60; echo -e '\n'; ping -I eth1 -c 3 -nn 90.183.38.60
PING 90.183.38.60 (90.183.38.60) from 10.128.254.2 : 56(84) bytes of data.
64 bytes from 90.183.38.60: icmp_req=1 ttl=56 time=4.66 ms
64 bytes from 90.183.38.60: icmp_req=2 ttl=56 time=12.7 ms
64 bytes from 90.183.38.60: icmp_req=3 ttl=56 time=4.50 ms
--- 90.183.38.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.502/7.310/12.769/3.861 ms


PING 90.183.38.60 (90.183.38.60) from 10.128.254.2 eth1: 56(84) bytes of data.
From 10.128.254.2 icmp_seq=1 Destination Host Unreachable
From 10.128.254.2 icmp_seq=2 Destination Host Unreachable
From 10.128.254.2 icmp_seq=3 Destination Host Unreachable
--- 90.183.38.60 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
pipe 3

Interface eth1 má IP adresu 10.128.254.2 (ta je u ISP NATována 1:1 na veřejnou), na žádném interface nejsou použity IPv6 ani IP aliasy:

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:30:4f:39:4b:49 brd ff:ff:ff:ff:ff:ff
    inet 10.128.254.2/29 brd 10.128.254.7 scope global eth1
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:08:c7:25:c7:53 brd ff:ff:ff:ff:ff:ff
    inet 10.3.60.10/24 brd 10.3.60.255 scope global eth2
4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:08:c7:19:3b:94 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.254/24 brd 10.0.1.255 scope global eth3
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1e:8c:94:05:cd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp
    inet 90.187.57.21 peer 78.103.210.66/32 scope global ppp0

Setkal se s tím někdo, resp. je pro to nějaké vysvětlení?

Odpovědi

[pepe_]

Ubuntu 10.04 Jde oboje

Nainstalovano : iputils-ping 3:20071127-2ubuntu1

pepe@PC-Pepe:~$ uname -r
2.6.38-10-generic
pepe@PC-Pepe:~$ 


pepe@PC-Pepe:~$ ping -I 10.10.10.1 -c 3 -nn 90.183.38.60; echo -e '\n'; ping -I eth0 -c 3 -nn 90.183.38.60
PING 90.183.38.60 (90.183.38.60) from 10.10.10.1 : 56(84) bytes of data.
64 bytes from 90.183.38.60: icmp_seq=1 ttl=52 time=20.3 ms
64 bytes from 90.183.38.60: icmp_seq=2 ttl=52 time=22.0 ms
64 bytes from 90.183.38.60: icmp_seq=3 ttl=52 time=23.3 ms

--- 90.183.38.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 20.337/21.917/23.355/1.248 ms


PING 90.183.38.60 (90.183.38.60) from 10.10.10.1 eth0: 56(84) bytes of data.
64 bytes from 90.183.38.60: icmp_seq=1 ttl=52 time=23.8 ms
64 bytes from 90.183.38.60: icmp_seq=2 ttl=52 time=29.3 ms
64 bytes from 90.183.38.60: icmp_seq=3 ttl=52 time=23.2 ms

--- 90.183.38.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.237/25.468/29.362/2.768 ms
pepe@PC-Pepe:~$ 

[Franta Hanzlík]

U mne je to kernel 2.6.35.14-96.fc14.i686.PAE a ping je z iputils-20100418. A z ppp0 mi to pingá také oběma způsoby. A z interface eth2 (jeho privátní IP je u dalšího ISP také NATovaná 1:1 na veřejnou) také - když je nastaven jako default GW. A pokud nastavím jako default GW eth1, tak se situace obrátí - z eth1 chodí jak "ping -I eth1", tak "ping -I 10.3.60.10", a "ping -I eth2 ..." nechodí.

Pro úplnost ještě uvedu ip tables a rules (toto chování bude nejspíš způsobeno nějakou kombinací těchto pravidel spolu s různým chováním ping při specifikaci jména interface nebo IP adresy):

# ip route list table wifismrk
90.187.57.21 dev ppp0  scope link 
10.128.254.0/29 dev eth1  scope link  src 10.128.254.2 
10.3.60.0/24 dev eth2  scope link 
192.168.0.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 10.128.254.1 dev eth1 

# ip route list table wifibudka
90.187.57.21 dev ppp0  scope link 
10.128.254.0/29 dev eth1  scope link 
10.3.60.0/24 dev eth2  scope link  src 10.3.60.10 
192.168.0.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 10.3.60.1 dev eth2 

# ip route list table adsl
90.187.57.21 dev ppp0  scope link  src 90.187.57.21 
10.128.254.0/29 dev eth1  scope link 
10.3.60.0/24 dev eth2  scope link 
192.168.0.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default dev ppp0  scope link 

# ip rule show
0:	from all lookup local 
32763:	from 90.187.57.21 lookup adsl 
32764:	from 10.3.60.10 lookup wifibudka 
32765:	from 10.128.254.2 lookup wifismrk 
32766:	from all lookup main 
32767:	from all lookup default 

[Franta Hanzlík]

Teď jsem ještě zkusil:

]# ping -R -I 10.128.254.2 -c 3 -nn 90.183.38.60
PING 90.183.38.60 (90.183.38.60) from 10.128.254.2 : 56(124) bytes of data.

--- 90.183.38.60 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

(tj. oproti verzi která "chodí" je tam navíc přepínač "-R" /Record route/ - a s ním to také přestane ping-at). Pro upřesnění - zvenku z internetu lze na příslušnou IP adresu pingnout i navázat TCP spojení se službami na Linux boxu.

[lertimir]

Tak tohle je pochopitelné. Record Route je nastavení volby Option IP hlavičky na hodnotu 7. Smysl mělo v počátcích internetu, kdy routovacích prvků bylo málo a také v internetu nebyli vnitřní nepřátelé. V současnosti mnoho routerů pakety s nastaveným RR zahazuje, protože tuto techniku je použít pro zkoumání struktury sítě a následně k útoku.

[Franta Hanzlík]

jj, máte pravdu. "-R" jsem asi nikdy dříve nezkoušel. Teď koukám, že takové pakety zřejmě zahodí Linux (ve výchozím nastavení) i několik RouterOSů které jsem teď zkusil - a jeden z nich je i 10.128.254.1 gateway na eth1 interface toho mého keplu.

[Franta Hanzlík]

Eh, omlouvám se, zapomněl jsem main route table, vypadá viz níže. A ještě:

/proc/sys/net/ipv4/conf/*/rp_filter            = 0
/proc/sys/net/ipv4/conf/*/accept_source_route  = 1

# ip route list
90.187.57.21 dev ppp0  scope link  src 90.187.57.21 
78.103.210.66 dev ppp0  proto kernel  scope link  src 90.187.57.21 
10.128.254.0/29 dev eth1  proto kernel  scope link  src 10.128.254.2 
10.3.60.0/24 dev eth2  proto kernel  scope link  src 10.3.60.10 
10.0.1.0/24 dev eth3  proto kernel  scope link  src 10.0.1.254 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.254 
169.254.0.0/16 dev eth1  scope link  metric 1002 
169.254.0.0/16 dev eth2  scope link  metric 1003 
169.254.0.0/16 dev eth3  scope link  metric 1004 
169.254.0.0/16 dev eth0  scope link  metric 1005 
default via 10.3.60.1 dev eth2 

[cynic_asshole]

[root@ganymed ~]# ping -I 139.84.66.15 -c 3 -nn 90.183.38.60; echo -e '\n'; ping -I re0 -c 3 -nn 90.183.38.60
ping: -I, -L, -T flags cannot be used with unicast destination


ping: invalid multicast interface: `re0'

[Franta Hanzlík]

Zdá se, že interface musí být schopno multicastingu, aby bylo možno použít "-I" volbu. U Linuxu jsou tak nastaveny asi všechny Ethernet interface:

# ip addr show eth1
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:30:4f:39:4b:49 brd ff:ff:ff:ff:ff:ff
    inet 10.128.254.2/29 brd 10.128.254.7 scope global eth1

Jak je to v BSD a co je re0 se přiznám že nevím.

[cynic_asshole]

[root@ganymed ~]# ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 52:54:00:00:01:8f
        inet XX:XX:XX:XX:XX netmask 0xffffff00 broadcast XX:XX:XX:XX:XX:XX
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

man ping
…
-I interface
	     Source multicast packets with the given interface address.  This
	     flag only applies if the ping destination is a multicast address.

Taková je situace na BSD.

Zkus si udělat na tom interface tcpdump v obou pokusech; podle mého v tom bude mít prsty ARP a směrování. V případě pingu z IP adresy bys měl vidět ARP dotaz na default GW a v případě pingu z interface bys měl vidět ARP dotaz na destinační IP adresu. V tom bude ten rozdíl. Bohužel si to nemůžu na ničem vyzkoušet sám, ale vycházím z logické úvahy.

[Franta Hanzlík]

Tak na Linuxu vypadá popis volby "-I" jinak:

-I interface address
              Set source address to specified interface address. Argument may be numeric IP address
              or name of device. When pinging IPv6 link-local address this option is required.

Takže žiju v tom, že tahle volba vynutí odeslání ICMP paketu ven daným (jménem rozhraní n. jeho IP adresou) rozhraním (programově asi přes volání bind()). A bude se to řešit standardním postupem - pokud je cíl na segmentu tohoto interface, tak se zjistí přes ARP; pokud ne a routovací tabulky specifikují gateway, tak se to pošle tam.
V mém případě (cíl je mimo sítě stroje a routovaci tabulka "wifismrk" obsahuje

10.128.254.0/29 dev eth1  scope link  src 10.128.254.2 
default via 10.128.254.1 dev eth1 

) jsem očekával že to půjde na gateway 10.128.254.1 a ta to pošle dál. A hlavně, že "ping -I 10.128.254.2" a "ping -I eth1" se bude chovat stejně - že v druhém případě se jméno interface použije na získání jeho IP a dál je všechno stejné.
Můžete Vaši logickou úvahu rozvinout? Ona je totiž asi správná - v případě specifikace interface opravdu z mašiny odchází ARP dotazy na MAC cíle (90.183.38.60), ačkoliv podle konfigurace eth1 by mělo být jasné, že na jeho segmentu cíl není.
Jasno by asi vneslo mrknutí do zdrojáků a ev. nějaké trasování utility ping, ale asi mi to nestojí za ten čas - na tom Linuxu vše funguje jak má, tak proč to škrábat :). Jen mi to nějak nabouralo moje zažité představy. Traceroute má pro spcifikaci rozhraní přepínač "-i", a s tím to funguje bez problémů (a má zvlášť "-s" na specifikování zrdojové adresy). U mtr zase jde specifikovat jen odchozí adresa a podle toho se vybere interface. A já si napotvoru vyberu ping ;)
Díky

[Michal Kubeček]

Ten popis neodpovídá tomu, co je ve zdrojácích. Ty dva případy se ve skutečnosti řeší různě: zadáte-li adresu, nabinduje se socket na tu adresu, zadáte-li interface, použije se socket option SO_BINDTODEVICE. Což celkem dává smysl - už od jádra 2.2 je totiž formulace "adresa daného rozhraní" principiálně nesmyslná. O víkendu snad budu mít trochu času a zkusím ten váš problém zreprodukovat, abych zjistil, co se tam děje.

Jen pro jistotu: nemůže vám ty pakety zahazovat netfilter?

[Franta Hanzlík]

Hmm, tak se zdá že traceroute to dělá "čistě" tím, že umožňuje zadat obojí, zařízení i source addr. A ping s "-I netdev" možná zdrojovou adresu vůbec nenastaví, takže proto ty ARP dotazy na cílovou adresu. Tadyhle je k tomu nějaký pokec (na tři kliky; asi by se toho našlo víc):

http://codingrelic.geekhold.com/2009/10/code-snippet-sobindtodevice.html

S tou "adresa daného rozhraní" se něco asi dělat dá, viz getifaddrs(). Netfilter pakety nezahazuje (je vypnutý).

[Michal Kubeček]

S tou "adresa daného rozhraní" se něco asi dělat dá, viz getifaddrs().

Všimněte si, že na konci je s a i popis v manuálové stránce říká "get interface addresses".

[Franta Hanzlík]

Ano, já to nerozporuji, ten popis je celkem jasný. Ale v případě, že interface má právě jednu adresu (můj případ), mi přijde logické ji použít jako adresu zdroje. Ale jak píši v předchozím, traceroute to umožňuje specifikovat obojí, což je čistší řešení.