Чому відбувається переадресація хоста ICMP?

25

Я встановлюю поле Debian як маршрутизатор для 4 підмереж. Для цього я визначив 4 віртуальних інтерфейси в NIC, де підключена локальна мережа ( 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 - це ACCEPT (а інших правил немає), я розумію, що не повинно виникнути проблем з пінг-програмою від 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.

EDIT

Ми ризикуємо трохи вийти за рамки оригінального питання, але я допоможу розглянути проблеми дизайну / безпеки, згадані у вашому коментарі.

Якщо ви хочете ізолювати користувачів у вашому офісі один від одного, давайте відступимо на секунду і розглянемо деякі проблеми безпеки з тим, що у вас зараз:

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

  • Потрібно призначити користувачів у Вланах, грунтуючись на політиці безпеки, зазначеній у коментарях. Правильно налаштований Vlan пройде довгий шлях до виправлення вищезазначених проблем. Якщо ваш перемикач Ethernet не підтримує власників, вам слід придбати такий.
  • Щодо доступу до кількох доменів безпеки 10.1.1.12, у вас є кілька варіантів:
    • Варіант 1 : Враховуючи вимогу всіх користувачів до доступу до служб 10.1.1.12, ви можете розмістити всіх користувачів в одній підмережі IP та реалізувати політику безпеки з приватними власниками (RFC 5517) , припускаючи, що ваш комутатор Ethernet підтримує це. Цей параметр не вимагатиме iptablesправил обмеження внутрішньо-офісного трафіку від перетину меж безпеки (що здійснюється з приватними власниками).
    • Варіант 2 : Ви можете розмістити користувачів у різних підмережах (відповідні власникам) та застосувати iptablesправила розгортання політики безпеки
  • Після того, як ви захистили свою мережу на рівні Vlan, створіть політику маршрутизації на основі джерела для надсилання різних користувачів із кількох посилань.

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

— Майк Пеннінгтон
джерело
В основному, мені потрібно мати 4 підмережі для різних областей офісу. Деякі підмережі вийдуть в Інтернет за допомогою одного провайдера, а інші використовуватимуть інший. Машини з різних підмереж не повинні бачити або з'єднуватися між собою. ВИКЛЮЧИТЬ для хоста 10.1.1.12, який пропонує деякі послуги, які мають бути доступними для всіх. Наразі я не встановив для цього відповідних правил FORWARD. Однак, оскільки всі форварди прийняті, я подумав, що я повинен мати можливість пройти пінг з 10.1.2.20 по 10.1.1.12.
— El Barto
Хм ... добре, дякую, Майк. Я детальніше загляну в VLAN. Я думав про це, перш ніж починати все це, і думав, що мені це не потрібно. Перемикачі, які ми маємо, підтримують VLAN, хоча вони є некерованими комутаторами, тому, якщо я не помиляюся, я думаю, мені доведеться робити теги на маршрутизаторі Debian, правда? Ізоляція підмереж насправді не є критичною проблемою в цьому офісі, але я думаю, що це було б добре, якщо це не вимагає занадто багато зайвої роботи. Я загляну в це і побачу, що я можу зробити :)
— El Barto
@ElBarto, якщо ваші комутатори не підтримують тег Vlan (і це малоймовірно, якщо вони не керовані), тоді лише тег на Debian не допоможе. Якщо ізоляція внутрішньо-офісної підмережі не є критичною проблемою, тоді покладіть всіх на дві різні підмережі та полегшіть роботу (дві підмережі гарантують, що ви можете проводити політику маршруту на Debian). Я б сказав, що поточна схема з чотирма псевдонімами Debian інтерфейсу не забезпечує реальної ізоляції підмережі, і це додає набагато більше ускладнень.
— Майк Пеннінгтон
Це правильно, з того, що я розумію з посібника користувача, комутатори підтримують "збереження тегу", але не "роблять фактичне тегування". Дякуємо за роз’яснення щодо Debian. Вся справа в тому, що навіть якщо я зберігаю дві підмережі, мені все одно знадобляться машини з підмережі 10.1.2.0/24 для доступу до 10.1.1.12.
— Ель Барто
Машини в іншій підмережі все одно повинні мати доступ 10.1.1.12. Якщо ви заблокуєте Linux для надсилання ICMP недоступними iptables, тоді ви все одно будете записувати з нього CPU, надсилаючи повідомлення ICMP, але принаймні вони не будуть встановлені у ваших хост-таблицях. Це означає, що якщо ви додасте інший інтерфейс Ethernet на Debian (тобто присвячуєте один інтерфейс для кожного класу користувача), Debian більше не повинен надсилати ICMP недоступними; це означає, що у вас є два різних комутаторів Ethernet: по одному для кожного класу користувача. Вашим технікам по кабелюванню це не сподобається, але це робить роботу
— Майк Пеннінгтон,
3

Не зовсім зрозуміло, що ви намагаєтеся зробити, але можу сказати наступне.

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

— Халед
джерело
Мені потрібно обробляти ці 4 підмережі, які всі підключені через один і той самий NIC. Ідея полягає в тому, що хости з різних підмереж не повинні мати можливість з'єднуватися між собою, за винятком хоста 10.1.1.12, який повинен бути доступний для всіх. Я ще не визначив правила переадресації для цього, тому вважав, що будь-який хост із будь-якої з цих підмереж повинен мати змогу досягти 10.1.1.12. Чи є спосіб уникнути переадресації ICMP?
— El Barto
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.