Сеть мостов под Linux зависит от таблицы маршрутов
Я проводил эксперимент с Linux-мостом, и моя сетевая топология выглядит так:
Как видите, в локальной сети есть два хоста: Host1(10.74.68.58) и Host2(10.74.68.47). На Host1 я создал мост br0 и назначил ему IP (192.168.3.101). Затем я прикрепил eth0 к мосту:
[root@10.74.68.58:~] # bridge link
2: eth0 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
Я установил маршрут по умолчанию как br0, и это нормально ping 10.74.68.47:
[root@10.74.68.58:~] # ip r
default dev br0 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.101
Но все стало необъяснимым, когда я установил маршрут по умолчанию в eth0:
[root@10.74.68.58:~] # ip r
default dev eth0 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.101
Когда eth0 является интерфейсом маршрута по умолчанию, я пытаюсь пропинговать host2 двумя различными способами:
1, ping 10.74.68.47
Не удалось. После того, как я проверил файл tcpdump (захваченный на интерфейсе br0), я обнаружил, что br0 только получил ответ ARP. Таким образом, нет никакой информации ARP на интерфейсе eth0, таким образом это не может получить макинтош host2. Я думаю, что это правильное поведение, верно ли мое понимание?
2, тогда я попробовал ping -I br0 10.74.68.47
Я хотел использовать опцию -I, чтобы избежать маршрута по умолчанию, но также потерпел неудачу. После того, как я проверил файл tcpdump (захваченный на интерфейсе br0), я обнаружил, что уже есть пара эхо-запроса icmp и пакет эхо-ответа. Это меня сильно смутило. Теперь, когда br0 получил эхо-ответ, почему я не могу успешно пропинговать host2?
[root@10.74.68.58:~] # ping -I br0 10.74.68.47
2 packets transmitted, 0 received, 100% packet loss, time 1006ms
Ребята, можете дать мне несколько советов?
2 ответа
Мост не работает так, как вы думаете, он работает.:-)
Мост связан только с уровнем OSI 2 (кадры Ethernet). На этом уровне IP-адреса и т. Д. Не существуют. Концептуально вы можете представить мост как набор интерфейсов Ethernet. Каждый интерфейс называется портом, и пакет, который входит в один порт, выходит на все остальные порты. (На самом деле, в реализации Linux есть оптимизация, которая хранит таблицу видимых MAC-адресов, но концептуально это не имеет значения).
Таким образом, мост может соединять ("мостить") несколько сегментов Ethernet в один большой сегмент.
Тогда что значит "дать мосту Linux IP-адрес"? В реализации Linux мост не является отдельным аппаратным устройством (как они изначально были), он также доступен с самого хоста. Это означает, что он действует как своего рода "супер-интерфейс Ethernet" со многими портами, но пакеты, которые попадают в ядро или из этого ядра в любой из этих портов или поступают из них на один и тот же IP-адрес.
Поэтому, как только вы делаете интерфейс Ethernet ведомым (портом) моста, он перестает иметь свой собственный адрес. Единственное, что имеет значение - это IP-адрес моста.
Другими словами, создание моста только с одним портом не имеет смысла (вы могли бы использовать интерфейс самостоятельно). Попытка перенаправить пакеты на порт моста не имеет смысла (для ядра это мост - одно устройство).
Если вы хотите поиграть с бриджем, вам нужна такая структура:
10.0.2.1/23 10.0.2.2/23 10.0.3.254/23 10.0.3.1/23 10.0.3.2/23
............ ............ ............... ............ ............
. Host A . . Host B . . Host X . . Host C . . Host D .
. . . . . <-- br0 --> . . . . .
. eth0 . . eth0 . . eth0 eth1 . . eth0 . . eth0 .
.....|...... .....|...... ...|......|.... .....|...... .....|......
| | | | | |
-----+--------------+------------+ +------------+--------------+------
<-------- left Segment ---------> <------- right Segment ----------->
Здесь левый сегмент с узлами A и B соединен узлом X с правым сегментом с узлами C и D, и каждый узел доступен по одному IP-адресу (который назначен интерфейсам или мосту в целом).
Когда ты ping -I br0 10.74.68.47, Protocol stack обнаружим, что ip(10.74.68.47) не находится в той же локальной сети с br0, поэтому он отправляет ARP через eth0. Но eth0 подключил br0, он не может подключиться к стеку протоколов, eth0 отправит ответ ARP на br0, затем br0 обнаружит, что mac не совпадает, поэтому он его отбросил. поэтому стек протоколов не получает ответ ARP.
Вы можете изменить IP-адрес br0 до 10.74.68.x/24. все будет хорошо.