Почему происходит ICMP Redirect Host?

25

Я настраиваю коробку 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
networking  debian  iptables  routing  icmp 
— Эль Барто
источник

Ответы:

22

На первый взгляд кажется, что 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, если не расширились до a /21.

РЕДАКТИРОВАТЬ

Мы немного рискуем выйти за рамки первоначального вопроса, но я помогу разобраться с проблемами дизайна / безопасности, упомянутыми в вашем комментарии.

Если вы хотите изолировать пользователей в своем офисе друг от друга, давайте на секунду отступим и посмотрим на некоторые проблемы безопасности, которые есть у вас сейчас:

В настоящее время у вас есть четыре подсети в одном домене вещания Ethernet. Все пользователи в одном домене вещания не отвечают требованиям безопасности , вы озвученные в комментариях (все машины будут видеть передачи из других машин и могут спонтанно посылать трафик друг на друг Layer2, независимо от их шлюза по умолчанию существ eth1, eth1:0, eth1:1или eth1:2). Ваш брандмауэр Debian ничего не может сделать, чтобы изменить это (или, может быть, я должен сказать, что ваш брандмауэр Debian ничего не должен сделать, чтобы изменить это :-).

  • Вам необходимо назначить пользователей в Vlans, основываясь на политике безопасности, изложенной в комментариях. Правильно настроенный Vlan будет иметь большое значение для решения проблем, упомянутых выше. Если ваш Ethernet-коммутатор не поддерживает Vlans, вы должны получить тот, который поддерживает.
  • Что касается доступа к нескольким доменам безопасности 10.1.1.12, у вас есть несколько вариантов:
    • Вариант 1. Учитывая требование доступа всех пользователей к службам 10.1.1.12, вы можете поместить всех пользователей в одну IP-подсеть и реализовать политики безопасности с помощью Private Vlans (RFC 5517) , предполагая, что ваш коммутатор Ethernet поддерживает это. Эта опция не требует iptablesправил для ограничения трафика внутри офиса от пересечения границ безопасности (что достигается с помощью частных Vlans).
    • Вариант 2. Вы можете поместить пользователей в разные подсети (соответствующие Vlans) и внедрить iptablesправила для развертывания ваших политик безопасности.
  • После того, как вы защитите свою сеть на уровне Vlan, настройте политики маршрутизации на основе источника, чтобы отправлять различным пользователям несколько ваших обратных ссылок.

К вашему сведению, если у вас есть маршрутизатор, который поддерживает VRF , то это становится еще проще; IIRC, у вас есть машина Cisco IOS на месте. В зависимости от модели и образа программного обеспечения, которые у вас уже есть, Cisco может сделать фантастическую работу, изолируя ваших пользователей друг от друга и реализуя политики маршрутизации на основе источника.

— Майк Пеннингтон
источник
В основном мне нужно иметь 4 подсети для разных областей офиса. Некоторые подсети будут выходить в Интернет через одного интернет-провайдера, а другие - другого. Машины из разных подсетей не должны видеть или соединяться друг с другом. КРОМЕ для хоста 10.1.1.12, который предлагает некоторые услуги, которые должны быть доступны для всех. В настоящее время я не установил соответствующие правила FORWARD для этого. Однако, так как все форварды приняты, я подумал, что смогу пинговать с 10.1.2.20 до 10.1.1.12.
— Эль Барто
Хм ... хорошо, спасибо Майк. Я посмотрю в VLAN более глубоко. Я думал об этом, прежде чем начать все это, и подумал, что мне это не понадобится. Имеющиеся у нас коммутаторы поддерживают VLAN, хотя они являются неуправляемыми коммутаторами, поэтому, если я не ошибаюсь, думаю, мне придется выполнить маркировку на маршрутизаторе Debian, верно? Изоляция подсетей на самом деле не является критической проблемой в этом офисе, но я думаю, что это было бы хорошо, если бы не требовалось слишком много дополнительной работы. Я посмотрю на это и посмотрю, что я могу сделать :)
— Эль Барто
@ElBarto, если ваши коммутаторы не поддерживают теги Vlan (и это маловероятно, если они неуправляемые), тогда только тегирование в Debian не поможет. Если внутренняя изоляция подсетей не является критической проблемой, поместите всех в две разные подсети и упростите задачу (две подсети гарантируют, что вы сможете направлять политику в Debian). Я бы сказал, что текущая схема с четырьмя псевдонимами интерфейса Debian не предлагает реальной изоляции подсети, и это добавляет гораздо больше сложностей.
— Майк Пеннингтон
Это верно, из того, что я понимаю из руководства пользователя, переключатели поддерживают «сохранение тега», но не «выполнение реальной маркировки». Спасибо за разъяснения относительно Debian. Дело в том, что даже если я оставлю две подсети, мне все равно понадобятся машины из подсети 10.1.2.0/24 для доступа к 10.1.1.12.
— Эль Барто
Машины в другой подсети по-прежнему должны иметь доступ 10.1.1.12. Если вы заблокируете linux от отправки ICMP недоступных с iptables, то вы все равно будете сжигать ЦП, отправляя ICMP-сообщения, но по крайней мере они не будут установлены в ваших таблицах хоста. Тем не менее, если вы добавите еще один интерфейс Ethernet в Debian (то есть выделите один интерфейс для каждого пользовательского «класса»), Debian больше не должен отправлять ICMP-сообщения о недоступности; это означало бы, что у вас есть два разных коммутатора Ethernet: по одному для каждого пользовательского «класса». Вашему кабельному персоналу это не понравится, но оно выполнит свою работу
— Майк Пеннингтон
3

Не совсем понятно, что вы пытаетесь сделать, но могу сказать следующее.

Эти подсети подключены к одному физическому интерфейсу. Маршрутизатор Linux будет возвращать сообщение перенаправления ICMP, когда полученный пакет должен быть перенаправлен через тот же физический интерфейс.

— Халед
источник
Мне нужно обработать эти 4 подсети, которые все связаны через один и тот же сетевой адаптер. Идея состоит в том, что хосты из разных подсетей не должны иметь возможность подключаться друг к другу, за исключением хоста 10.1.1.12, который должен быть доступен для всех. Я еще не определил правила пересылки для этого, поэтому я думал, что любой хост из любой из этих подсетей должен быть в состоянии достичь 10.1.1.12. Есть ли способ избежать перенаправления ICMP?
— Эль Барто
1
@ElBarto, один из методов - добавить iptablesправило, которое пропускает редиректыeth1
— Майк Пеннингтон,
1

Я согласен с комментариями Халеда и добавил бы в конец его фразы:

«Эти подсети подключены к одному и тому же физическому интерфейсу. Маршрутизатор Linux будет возвращать сообщение перенаправления ICMP, когда полученный пакет должен быть перенаправлен по тому же физическому интерфейсу» в ту же подсеть назначения, а затем перенаправлять запрос на следующий переход. Это случилось со мной сегодня с использованием роутера Mikrotik linux и устройства F5 bigip LTM.

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
— user352048
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.