Я настраиваю маршрутизатор на базе Linux с 4 сетевыми адаптерами, и мне не удается убедить его работать, несмотря на следующие шаги, предложенные на различных веб-сайтах.
Каждый интерфейс находится в отдельной подсети, как показано ниже:
eth0 10.1.0.254 (255.255.255.0)
eth1 10.1.1.254 (255.255.255.0)
eth2 10.1.2.254 (255.255.255.0)
eth3 10.1.3.254 (255.255.255.0)
Каждое устройство в каждой сети настроено на использование 10.1.Икс.254 в качестве шлюза в локальной сети.
Я включил переадресацию IP (а также сделал ее постоянной в /etc/sysctl.conf)
$ cat /proc/sys/net/ipv4/ip_forward
1
И таблица маршрутизации выглядит правильно
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
10.1.1.0 * 255.255.255.0 U 0 0 0 eth1
10.1.2.0 * 255.255.255.0 U 0 0 0 eth2
10.1.3.0 * 255.255.255.0 U 0 0 0 eth3
Интерфейсы
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:8d:xx:xx:xx
inet addr:10.1.0.254 Bcast:10.1.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28919 errors:0 dropped:0 overruns:0 frame:0
TX packets:16132 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:35054376 (35.0 MB) TX bytes:1424175 (1.4 MB)
Interrupt:22
eth1 Link encap:Ethernet HWaddr 00:1b:21:xx:xx:xx
inet addr:10.1.1.254 Bcast:10.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:480 (480.0 B) TX bytes:3996 (3.9 KB)
eth2 Link encap:Ethernet HWaddr 00:1b:21:xx:xx:xx
inet addr:10.1.2.254 Bcast:10.1.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1024 (1.0 KB) TX bytes:4122 (4.1 KB)
eth3 Link encap:Ethernet HWaddr 00:1b:21:xx:xx:xx
inet addr:10.1.3.254 Bcast:10.1.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6419 errors:0 dropped:0 overruns:0 frame:0
TX packets:6702 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:701177 (701.1 KB) TX bytes:612622 (612.6 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1753 errors:0 dropped:0 overruns:0 frame:0
TX packets:1753 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:194373 (194.3 KB) TX bytes:194373 (194.3 KB)
ПК, подключенный к сети 10.1.1.0/24 (с IP-адресом 10.1.1.1, шлюз настроен правильно как 10.1.1.254), он может пинговать локальный интерфейс маршрутизатора Linux, но ни один из трех других интерфейсов маршрутизатора не включен. шлюз.
У меня нет никаких брандмауэров (аппаратных или программных) в этой сетевой настройке.
Я упустил что-то фундаментальное?
Редактировать 1
С ПК 10.1.1.1 я теперь могу пропинговать все интерфейсы на маршрутизаторе, кроме одного, а именно 10.1.0.254. (Я не уверен, что я сделал, чтобы это исправить!)
Все задействованные подсети размещены рядом коммутаторов уровня 3 как VLAN. Интерфейс маршрутизатора Linux, который не отвечает, является единственной VLAN, которая имеет интерфейс маршрутизации на нашем основном коммутаторе.
tcpdump на eth1 не показывает никаких признаков эха ICMP, когда я пытаюсь связаться с этим интерфейсом, несмотря на то, что 10.1.1.1 настроен на использование 10.1.1.254 (eth1 на маршрутизаторе Linux).
Может быть, из-за широковещательных протоколов маршрутизации от коммутатора ПК на 10.1.1.1 не выполняет маршрутизацию через 10.1.1.254?
Редактировать 2
Пока я работал над чем-то другим, я вернулся к этому (ничего не меняя на маршрутизаторе Linux), и он снова перестал работать.
Редактировать 3
конфигурация iptables
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Из того, что вы описываете, должно работать. Если вы можете пинговать интерфейс шлюза в той же сети, но не можете пинговать какой-либо другой интерфейс, это очень странно. Стек TCP / IP должен правильно отвечать на эхо-запрос интерфейса A, даже если он получен через интерфейс B.
Поскольку вы проверяете локальный адрес шлюза (хотя и в другой сети), пересылка пакетов не выполняется. Я вижу три возможных причины:
1) Шлюз на самом деле не получил пакет (проблема маршрутизации / фильтрации на клиенте).
2) Шлюз не отправил ответ в нужное место.
3) Шлюз решил не отвечать (своего рода брандмауэр. Я бы дважды это проверил, просто чтобы убедиться, что это не так).
Я бы использовал tcpdump или wirehark, чтобы убедиться, что происходит на проводе. Вы должны увидеть, как запросы ping покидают клиента. Затем на интерфейсе шлюза вы должны увидеть их прибытие. Затем я бы прослушал все интерфейсы, чтобы увидеть, отправляется ли куда-нибудь ответ. Если вы видите входящий запрос ping, значит, маршрутизация на стороне клиента в порядке. Если вы не видите ответа ping из любого интерфейса, то это либо брандмауэр, либо некоторая странность, происходящая с таблицами маршрутизации на шлюзе. Наконец, если шлюз отправляет ответ через правильный интерфейс и не регистрируется на клиенте, это все ошибка клиента.
Я бы попробовал устройство в другой сети (например, 10.1.3.0/24), желательно напрямую подключенное к сетевой карте сервера, чтобы быть уверенным, что ничто не мешает общению. Возможно, это просто опечатка, и в этом чертовски трудно понять, знаете ли вы, что вам следует увидеть. Настройка другого устройства (или перенастройка ПК, который вы использовали для первого теста) снижает вероятность того, что вы снова допустите опечатку.
И последний вопрос - это когда-нибудь работало, или это новый ящик, установленный и вставленный в сеть?
Редактировать:
Пока вы не включили какой-либо демон маршрутизации в системе Linux, он будет игнорировать трафик маршрутизатора от ваших коммутаторов.
То, что вы наблюдаете, явно указывает на какое-то внешнее влияние (переключатели, межсетевые экраны, инопланетяне или стажер, запертый в NOC;)). Попробуйте протестировать настройку с двумя клиентами, подключенными напрямую к Linux, например:
+-------------+
client1 ---+ ethX ethY +--- client2
+-------------+
Linux box
В этой настройке тестовая маршрутизация на Linux-боксе между всеми интерфейсами. В противном случае вы будете сражаться на нескольких фронтах одновременно, и это снижает шансы на успешное устранение неполадок. Как только вы узнаете, что Linux работает (или нет), пора будет искать причины наблюдаемых помех.
Если у вас есть интеллектуальные коммутаторы, подключенные ко всем интерфейсам вашего Linux-бокса, вы можете определить IP-адрес на порту, напрямую подключенном к Linux-серверу, и попробовать выполнить эхо-запрос между блоком и маршрутизатором. Я, будучи подозрительным параноиком, принес бы в коробку свой ноутбук вместе с горсткой заведомо исправных патч-кордов, чтобы посмотреть, что происходит.
Наверное, глупый вопрос, но ... вы говорите, что у вас нет брандмауэра в этой сети, но вы абсолютно уверены в этом?
В Linux по умолчанию включен брандмауэр, поэтому даже если вы включите IP-переадресацию, он не пропустит ни одного пакета, если вы явно не настроите для него IPTABLES (или полностью отключите брандмауэр).
То же самое, конечно, верно и для ваших ПК: будь то Linux или Windows, они в любом случае будут иметь встроенный брандмауэр, который будет по умолчанию активен, если вы явно не отключите его.
Правила Iptables разрешают пересылку?
iptables -L -n -v