☰

Пингование IP-адреса на другом интерфейсе, нежели тот, который получает сигнал

tag-icon • tag-icon ip ping
Пингование IP-адреса на другом интерфейсе, нежели тот, который получает сигнал

У меня есть PCa и PCb.

ПКa:

$> 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

Печатная плата:

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 подключен к PCb, eth0 через кабель Ethernet.

Сейчас,ping 172.18.0.150 на PCbдает:

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

Итак, пинг идет наeth0 на PCbЯ предполагаю, и приходит наeth6 на ПК. Дело в том, что этоeth0 на ПКчто имеет172.18.0.150IP адрес. Как так получилось, что я получаю ответ отeth0 на ПК, когдаeth0 на PCbдействительно связано сeth6 на ПК?

Разве IP не привязан только к самому интерфейсу? Это ожидаемое поведение? Не говоря уже о туннелях и прочем...

решение1

Да, это ожидаемое поведение. Ответ ping — это IP-пакет сам по себе, и он не связан каким-то особым образом с пакетом, на который он отвечает. IP-пакеты не формируют «цепи» для последующих ответов, каждый пакет маршрутизируется независимо.

Асимметричная маршрутизация очень распространена в Интернете. Например, при трафике, проходящем через страну, сеть назначения обычно выполняет дальнюю передачу. Так что если я пингую сервер на другом конце страны, его провайдер переносит запрос через всю страну, но мой провайдер переносит ответ через всю страну. Так что эти два маршрута очень, очень разные. Нет особой причины, по которой один путь должен выглядеть как-то похоже на другой.

решение2

Я думаю, что это больше связано с шлюзом по умолчанию, если вы используете Linux. Поскольку все интерфейсы находятся на одном хосте, любой исходящий трафик будет проходить через шлюз по умолчанию и связанный с ним интерфейс.

Это означает, что даже при отправке ping-запроса на определенный IP-адрес ответ пришел через шлюз по умолчанию, то есть он пришел с интерфейса, связанного со шлюзом по умолчанию.

Попробуйте выполнить следующие действия, чтобы увидеть маршрут по умолчанию и интерфейсы, используемые для данного IP-адреса.

ip route

Запустите как root или с помощью sudo.

решение3

Связано ли это как-то с scobe global/scope link и т. д.?

Вероятно, это связано с таблицами маршрутизации и метриками. Попробуйте

netstat -nr

в командной строке на PCb

Я полагаю, PCb убежден, что его интерфейс Eth2 «ближе», чем Eth1 к PCa.

Метрика, показанная в выводе, netstatявляется мерой желательности маршрута. Раньше это было число переходов, но лучше думать о нем как о значении приоритета, поскольку разные протоколы маршрутизации измеряют стоимость маршрутов по-разному.

Вы можете временно управлять таблицами маршрутизации с помощью routeкоманды (см route /?. )

Связанный контент