Я настраиваю Debian-бокс в качестве роутера на 4 подсети. Для этого я определил 4 виртуальных интерфейса на сетевой карте, к которой подключена локальная сеть (eth1).
eth1 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98
inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::960c:6dff:fe82:d98/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6026521 errors:0 dropped:0 overruns:0 frame:0
TX packets:35331299 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:673201397 (642.0 MiB) TX bytes:177276932 (169.0 MiB)
Interrupt:19 Base address:0x6000
eth1:0 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98
inet addr:10.1.2.1 Bcast:10.1.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:19 Base address:0x6000
eth1:1 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98
inet addr:10.1.3.1 Bcast:10.1.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:19 Base address:0x6000
eth1:2 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98
inet addr:10.1.4.1 Bcast:10.1.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:19 Base address:0x6000
eth2 Link encap:Ethernet HWaddr 6c:f0:49:a4:47:38
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::6ef0:49ff:fea4:4738/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:199809345 errors:0 dropped:0 overruns:0 frame:0
TX packets:158362936 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:3656983762 (3.4 GiB) TX bytes:1715848473 (1.5 GiB)
Interrupt:27
eth3 Link encap:Ethernet HWaddr 94:0c:6d:82:c8:72
inet addr:192.168.2.5 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::960c:6dff:fe82:c872/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:110814 errors:0 dropped:0 overruns:0 frame:0
TX packets:73386 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16044901 (15.3 MiB) TX bytes:42125647 (40.1 MiB)
Interrupt:20 Base address:0x2000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:22351 errors:0 dropped:0 overruns:0 frame:0
TX packets:22351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2625143 (2.5 MiB) TX bytes:2625143 (2.5 MiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:41358924 errors:0 dropped:0 overruns:0 frame:0
TX packets:23116350 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3065505744 (2.8 GiB) TX bytes:1324358330 (1.2 GiB)
У меня есть два других компьютера, подключенных к этой сети. У одного IP 10.1.1.12 (маска подсети 255.255.255.0), а у другого 10.1.2.20 (маска подсети 255.255.255.0). Я хочу иметь возможность достичь 10.1.1.12 с 10.1.2.20.
Поскольку в маршрутизаторе включена пересылка пакетов, а политика цепочки FORWARD - ПРИНЯТЬ (и других правил нет), я понимаю, что при прохождении эхо-запроса с 10.1.2.20 на 10.1.1.12 через маршрутизатор не должно возникнуть проблем.
Однако вот что я получаю:
$ ping -c15 10.1.1.12
PING 10.1.1.12 (10.1.1.12): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 81d4 0 0000 3f 01 e2b3 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 1
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 899b 0 0000 3f 01 daec 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 2
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 78fe 0 0000 3f 01 eb89 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 3
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 14b8 0 0000 3f 01 4fd0 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 4
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 8ef7 0 0000 3f 01 d590 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 5
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 ec9d 0 0000 3f 01 77ea 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 6
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 70e6 0 0000 3f 01 f3a1 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 7
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 b0d2 0 0000 3f 01 b3b5 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 8
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f8b4 0 0000 3f 01 6bd3 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 1c95 0 0000 3f 01 47f3 10.1.2.20 10.1.1.12
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 62bc 0 0000 3f 01 01cc 10.1.2.20 10.1.1.12
Почему это происходит?
Из того, что я прочитал Redirect Host ответ имеет какое-то отношение к тому факту, что два хоста находятся в одной сети и существует более короткий маршрут (по крайней мере, я так понял). Фактически, они находятся в одной физической сети, но почему может быть лучший маршрут, если они не находятся в одной подсети (они не видят друг друга)?
Что мне не хватает?
Дополнительная информация, которую вы, возможно, захотите увидеть:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth2
10.1.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.1.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2
0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 eth3
# iptables -L -n
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
# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- !10.0.0.0/8 10.0.0.0/8
MASQUERADE all -- 10.0.0.0/8 !10.0.0.0/8
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
На первый взгляд кажется, что Debian расширяет границы для отправки перенаправления ICMP; цитирование RFC 792 (Интернет-протокол).
The gateway sends a redirect message to a host in the following situation. A gateway, G1, receives an internet datagram from a host on a network to which the gateway is attached. The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram's internet destination network, X. If G2 and the host identified by the internet source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination. The gateway forwards the original datagram's data to its internet destination.
В этом случае G1 - это 10.1.2.1 (eth1:0 выше), X есть 10.1.1.0/24 а G2 - это 10.1.1.12, а источник 10.1.2.20 (т.е. G2 and the host identified by the internet source
address of the datagram are **NOT** on the same network). Возможно, это исторически интерпретировалось по-разному в случае псевдонимов интерфейса (или вторичных адресов) на одном и том же интерфейсе, но, строго говоря, я не уверен, что мы должны увидеть, что Debian отправляет это перенаправление.
В зависимости от ваших требований, вы можете решить эту проблему, создав подсеть для eth1 что-то вроде 10.1.0.0/22 (адреса хостов из 10.1.0.1 - 10.1.3.254) вместо использования псевдонимов интерфейса для отдельных /24 блоки (eth1, eth1:0, eth1:1, eth1:2); если вы это сделали, вам нужно будет изменить сетевую маску всех подключенных хостов, и вы не сможете использовать 10.1.4.x, если не расширите его до /21.
РЕДАКТИРОВАТЬ
Мы рискуем немного выйти за рамки исходного вопроса, но я помогу проработать проблемы дизайна / безопасности, упомянутые в вашем комментарии.
Если вы хотите изолировать пользователей в вашем офисе друг от друга, давайте вернемся на секунду назад и рассмотрим некоторые проблемы безопасности с тем, что у вас есть сейчас:
В настоящее время у вас есть четыре подсети в одном широковещательном домене Ethernet. Все пользователи в одном широковещательном домене не соответствуют требованиям безопасности, сформулированным вами в комментариях (все машины будут видеть широковещательные сообщения с других машин и могут самопроизвольно отправлять трафик друг другу на уровне Layer2, независимо от их шлюза по умолчанию. eth1, eth1:0, eth1:1 или eth1:2). Ваш брандмауэр Debian ничего не может сделать, чтобы это изменить (или, может быть, я должен сказать, что нет ничего, что ваш брандмауэр Debian должен сделать, чтобы изменить это :-).
10.1.1.12, у вас есть несколько вариантов: 10.1.1.12, вы можете поместить всех пользователей в одну IP-подсеть и реализовать политики безопасности с Частные вланы (RFC 5517), если ваш коммутатор Ethernet поддерживает это. Этот вариант не потребует iptables правила для ограничения внутриофисного трафика от пересечения границ безопасности (что достигается с помощью частных Vlan).iptables правила для развертывания ваших политик безопасностиК вашему сведению, если у вас есть маршрутизатор, поддерживающий VRF, кое-что из этого становится еще проще; IIRC, у вас есть машина с Cisco IOS. В зависимости от модели и образа программного обеспечения, которые у вас уже есть, Cisco может отлично изолировать ваших пользователей друг от друга. и реализовать политику маршрутизации на основе источника.
Не совсем понятно, что вы пытаетесь сделать, но могу сказать следующее.
Эти подсети подключены к одному физическому интерфейсу. Маршрутизатор Linux вернет сообщение перенаправления ICMP, когда полученный пакет должен быть переадресован через тот же физический интерфейс.
Я согласен с комментариями Халеда и также добавлю в конце его фразы:
«Эти подсети подключены к одному и тому же физическому интерфейсу. Маршрутизатор Linux будет возвращать сообщение перенаправления ICMP, когда полученный пакет должен быть перенаправлен через тот же физический интерфейс». в ту же подсеть назначения затем перенаправляем запрос на следующий переход. Это случилось со мной сегодня с использованием маршрутизатора Mikrotik linux и устройства LTM F5 bigip.
root@(primaryadc)(cfg-sync In Sync)(Standby)(/Common)(tmos)# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.153.20: icmp_seq=1 Redirect Host(New nexthop: 192.168.153.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=82.8 ms
From 192.168.153.20: icmp_seq=2 Redirect Host(New nexthop: 192.168.153.2)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=123 ms
**routing table**
0.0.0.0 192.168.153.20 0.0.0.0 UG 0 0 0 external
Физически это кажется более простым решением - поместите каждую локальную сеть на отдельный коммутатор и установите 4-портовый сетевой адаптер в свой единый блок, который будет обслуживать их все.