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

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

РПЖ:

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

Сейчас, пинг 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 на PCa , Дело в том, что это eth0 на PCa это имеет 172.18.0.150 Айпи адрес. Почему я получаю ответ от eth0 на PCa , когда eth0 на PCb действительно связан с eth6 на PCa ?

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

ip ping

— JohnyTex
источник

Ответы:

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

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

— David Schwartz
источник

Но IP-адрес имеет интерфейс, а не сам компьютер, верно?

— JohnyTex

@JohnyTex Это зависит от модель хоста , Чаще всего IP-адрес принадлежит самому компьютеру.

— David Schwartz

@JohnyTex Главным образом потому, что так делали старые системы, и потому что иногда проще назначать и управлять ими таким образом. Но для людей, которые регулярно имеют дело с асимметричной маршрутизацией и более сложными настройками, это может стать источником раздражения, требуя назначения IP-адресов фиктивным интерфейсам и других подобных неприятностей. Думайте об этом как об этом "идет дождь". Язык требует, чтобы у вас было «это», чтобы сказать, что есть дождь, но нет ничего, что на самом деле идет дождь.

— David Schwartz

@JohnyTex Не имеет значения, является ли маршрутизация симметричной или асимметричной. С ними обращаются точно так же. Моя цель в создании асимметричной маршрутизации - заставить вас перестать думать о такой симметричной маршрутизации, как будто это имеет значение Это правда, но это также не имеет значения.

— David Schwartz

ОК, теперь я понимаю, что понимаю. Спасибо за ваш совет!

— JohnyTex

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

Так что это означает, что, несмотря на пинг определенного IP-адреса, ответ пришел через шлюз по умолчанию, что означает, что он пришел с интерфейса, связанного со шлюзом по умолчанию.

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

ip route

Запустите как root или используя sudo,

— fswings
источник

Имеет ли это какое-либо отношение к глобальной ссылке / области видимости и т. Д.?

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

netstat -nr

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

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

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

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

— RedGrittyBrick
источник