☰

Pingen der IP-Adresse auf einer anderen Schnittstelle als der, die das Signal empfängt

tag-icon • tag-icon ip ping
Pingen der IP-Adresse auf einer anderen Schnittstelle als der, die das Signal empfängt

Ich habe PCa und PCb.

PCa:

$> ip addr && ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:13:3b:0f:24:fc brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.150/24 brd 192.168.3.255 scope global eth6
       valid_lft forever preferred_lft forever
    inet6 fe80::213:3bff:fe0f:24fc/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether f8:b1:56:ba:ae:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.150/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.150/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 172.18.0.150/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a00:801:19:1:288f:db46:14ef:cca8/64 scope global temporary dynamic 
       valid_lft 546270sec preferred_lft 27270sec
    inet6 2a00:801:19:1:50c3:7b14:61bc:1bc0/64 scope global temporary deprecated dynamic 
       valid_lft 460473sec preferred_lft 0sec
    inet6 2a00:801:19:1:fab1:56ff:feba:aeee/64 scope global dynamic 
       valid_lft 2591993sec preferred_lft 604793sec
    inet6 fe80::fab1:56ff:feba:aeee/64 scope link 
       valid_lft forever preferred_lft forever
5: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 10.110.2.204 brd 10.110.0.115
6: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
7: netgw@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1256 qdisc noqueue state UNKNOWN group default 
    link/gre 10.110.1.222 peer 10.110.0.115
    inet 192.168.4.1/24 scope global netgw
       valid_lft forever preferred_lft forever
default via 172.18.0.1 dev eth0 
169.254.0.0/16 dev eth6  scope link  metric 1000 
172.18.0.0/24 dev eth0  proto kernel  scope link  src 172.18.0.150 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.150 
192.168.3.0/24 dev eth6  proto kernel  scope link  src 192.168.3.150 
192.168.5.0/24 dev netgw  scope link 
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.150

PCB:

bash# ip addr && ip route
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:05:68:02:68:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global eth0
3: tunl0: <NOARP> mtu 1480 qdisc noop 
    link/ipip 0.0.0.0 brd 0.0.0.0
4: gre0: <NOARP> mtu 1476 qdisc noop 
    link/gre 0.0.0.0 brd 0.0.0.0
5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:05:68:03:68:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.2/24 brd 192.168.3.255 scope global eth1
7: netpc@NONE: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue 
    link/gre 10.110.0.115 peer 10.110.1.222
    inet 192.168.5.1/24 scope global netpc
19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1280 qdisc pfifo_fast qlen 3
    link/ppp 
    inet 10.110.1.16 peer 192.168.111.111/32 scope global ppp0
192.168.111.111 dev ppp0  proto kernel  scope link  src 10.110.1.16 
10.99.196.40 dev ppp0  scope link 
8.8.8.8 dev ppp0  scope link 
192.168.4.0/24 dev netpc  scope link 
192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.1 
172.18.0.0/24 dev eth0  scope link 
224.0.0.0/4 dev eth0  scope link

PCa, eth6 ist über ein Ethernet-Kabel mit PCb, eth0 verbunden.

Jetzt,Ping 172.18.0.150 auf PCBgibt:

bash# ping 172.18.0.150
PING 172.18.0.150 (172.18.0.150) 56(84) bytes of data.
64 bytes from 172.18.0.150: icmp_seq=1 ttl=64 time=4.31 ms
64 bytes from 172.18.0.150: icmp_seq=2 ttl=64 time=0.848 ms

Der Ping geht also raus ameth0 auf PCBIch nehme an, und kommt herein aufeth6 auf PCa. Die Sache ist, dass eseth0 auf PCadas hat die172.18.0.150IP-Adresse. Wie kommt es, dass ich eine Antwort voneth0 auf PCa, Wanneth0 auf PCBist wirklich verbunden miteth6 auf PCa?

Ist die IP nicht nur an die Schnittstelle selbst gebunden? Ist das das erwartete Verhalten? Vergessen Sie die Tunnel und so ...

Antwort1

Ja, das ist das erwartete Verhalten. Die Ping-Antwort ist ein eigenständiges IP-Paket und nicht speziell mit dem Paket verbunden, auf das sie antwortet. IP-Pakete bilden keine „Schaltkreise“, denen Antworten folgen, jedes Paket wird unabhängig weitergeleitet.

Asymmetrisches Routing ist im Internet weit verbreitet. Bei Verkehr, der ein Land durchquert, übernimmt beispielsweise das Zielnetzwerk normalerweise die lange Strecke. Wenn ich also einen Server am anderen Ende des Landes anpinge, überträgt sein Provider die Anfrage über das ganze Land, aber mein Provider überträgt die Antwort über das ganze Land. Die beiden Routen sind also sehr, sehr unterschiedlich. Es gibt keinen besonderen Grund, warum ein Pfad dem anderen ähnlich sein sollte.

Antwort2

Ich denke, das hat mehr mit dem Standard-Gateway zu tun, wenn Sie Linux verwenden. Da sich alle Schnittstellen auf demselben Host befinden, läuft der gesamte ausgehende Datenverkehr über das Standard-Gateway und die zugehörige Schnittstelle.

Das bedeutet, dass die Antwort, obwohl eine bestimmte IP-Adresse angepingt wurde, über das Standard-Gateway kam, also von der Schnittstelle, die mit dem Standard-Gateway verknüpft ist.

Versuchen Sie Folgendes, um die Standardroute und die für eine bestimmte IP-Adresse verwendeten Schnittstellen anzuzeigen.

ip route

Als Root ausführen oder verwenden sudo.

Antwort3

Hat das irgendetwas mit Scobe Global/Scope Link usw. zu tun?

Es hat wahrscheinlich mit Routing-Tabellen und Metriken zu tun. Versuchen Sie

netstat -nr

in einer Eingabeaufforderung auf der Leiterplatte

Ich gehe davon aus, dass PCb davon überzeugt ist, dass seine Eth2-Schnittstelle „näher“ an PCa liegt als Eth1.

Die in der Ausgabe angezeigte Metrik netstatist ein Maß für die Attraktivität einer Route. Früher war es eine Hop-Anzahl, aber man sollte es sich am besten als Prioritätswert vorstellen, da verschiedene Routing-Protokolle die Kosten von Routen auf unterschiedliche Weise messen.

Sie können Routing-Tabellen vorübergehend mit dem Befehl manipulieren route(siehe route /?).

verwandte Informationen