Tại sao máy chủ chuyển hướng ICMP xảy ra?

25

Tôi đang thiết lập hộp Debian làm bộ định tuyến cho 4 mạng con. Vì vậy, tôi đã xác định 4 giao diện ảo trên NIC nơi LAN được kết nối ( 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)

Tôi có hai máy tính khác kết nối với mạng này. Một cái có IP 10.1.1.12 (mặt nạ mạng con 255.255.255.0) và cái còn lại 10.1.2.20 (mặt nạ mạng con 255.255.255.0). Tôi muốn có thể đạt 10.1.1.12 từ 10.1.2.20.

Vì chuyển tiếp gói được bật trong bộ định tuyến và chính sách của chuỗi FORWARD là ACCEPT (và không có quy tắc nào khác), tôi hiểu rằng sẽ không có vấn đề gì khi ping từ 10.1.2.20 đến 10.1.1.12 đi qua bộ định tuyến.

Tuy nhiên, đây là những gì tôi nhận được:

$ 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

Lý do tại sao điều này xảy ra?

Từ những gì tôi đã đọc, Redirect Hostphản hồi có liên quan đến thực tế là hai máy chủ lưu trữ trong cùng một mạng và có một tuyến ngắn hơn (hoặc vì vậy tôi hiểu). Thực tế chúng nằm trong cùng một mạng vật lý, nhưng tại sao sẽ có một tuyến tốt hơn nếu chúng không nằm trên cùng một mạng con (chúng không thể nhìn thấy nhau)?

Tôi đang thiếu gì?

Một số thông tin bổ sung mà bạn có thể muốn xem:

# 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 
— El Barto
nguồn

Câu trả lời:

22

Thoạt nhìn, có vẻ như Debian đang mở rộng ranh giới để gửi chuyển hướng ICMP; trích dẫn RFC 792 (Giao thức Internet) .

  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.

Trong trường hợp này, G1 là 10.1.2.1( eth1:0ở trên), X là 10.1.1.0/24và G2 là 10.1.1.12và nguồn là 10.1.2.20(nghĩa là G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Có thể điều này đã được giải thích theo lịch sử khác nhau trong trường hợp bí danh giao diện (hoặc địa chỉ phụ) trên cùng một giao diện, nhưng nói đúng ra tôi không chắc chúng ta sẽ thấy Debian gửi chuyển hướng đó.

Tùy thuộc vào yêu cầu của bạn, bạn có thể có thể giải quyết việc này bằng cách làm cho subnet cho eth1một cái gì đó giống như 10.1.0.0/22(địa chỉ máy chủ từ 10.1.0.1- 10.1.3.254) thay vì sử dụng bí danh giao diện cho cá nhân /24khối ( eth1, eth1:0, eth1:1, eth1:2); nếu bạn đã làm điều này, bạn sẽ cần thay đổi netmask của tất cả các máy chủ được đính kèm và bạn sẽ không thể sử dụng 10.1.4.x trừ khi bạn mở rộng sang a /21.

CHỈNH SỬA

Chúng tôi đang mạo hiểm một chút ngoài phạm vi của câu hỏi ban đầu, nhưng tôi sẽ giúp giải quyết các vấn đề về thiết kế / bảo mật được đề cập trong bình luận của bạn.

Nếu bạn muốn cách ly người dùng trong văn phòng của mình với nhau, hãy lùi lại một chút và xem xét một số vấn đề bảo mật với những gì bạn có bây giờ:

Bạn hiện có bốn mạng con trong một miền phát ethernet. Tất cả các thành viên trong lĩnh vực phát sóng không đáp ứng các yêu cầu bảo mật mà bạn có khớp nối trong các ý kiến (tất cả các máy sẽ thấy chương trình phát sóng từ máy khác và một cách tự nhiên có thể gửi lưu lượng với nhau tại Layer2, bất kể gateway mặc định hạnh phúc của họ eth1, eth1:0, eth1:1hoặc eth1:2). Không có gì tường lửa Debian của bạn có thể làm để thay đổi điều này (hoặc có lẽ tôi nên nói rằng không có gì tường lửa Debian của bạn nên làm để thay đổi điều này :-).

  • Bạn cần chỉ định người dùng vào Vlans, dựa trên chính sách bảo mật được nêu trong các bình luận. Một Vlan được cấu hình đúng sẽ đi một chặng đường dài để khắc phục các vấn đề được đề cập ở trên. Nếu công tắc ethernet của bạn không hỗ trợ Vlans, bạn nên lấy cái đó.
  • Đối với nhiều miền bảo mật truy cập 10.1.1.12, bạn có một vài lựa chọn:
    • Tùy chọn 1 : Đưa ra yêu cầu cho tất cả người dùng truy cập dịch vụ 10.1.1.12, bạn có thể đặt tất cả người dùng vào một mạng con IP và thực hiện các chính sách bảo mật với Private Vlans (RFC 5517) , giả sử công tắc ethernet của bạn hỗ trợ điều này. Tùy chọn này sẽ không yêu cầu iptablescác quy tắc để hạn chế lưu lượng truy cập trong văn phòng vượt qua các ranh giới bảo mật (được thực hiện với Vlans riêng).
    • Tùy chọn 2 : Bạn có thể đặt người dùng vào các mạng con khác nhau (tương ứng với Vlans) và thực hiện iptablescác quy tắc để triển khai các chính sách bảo mật của bạn
  • Sau khi bạn đã bảo mật mạng của mình ở cấp Vlan, hãy thiết lập các chính sách định tuyến dựa trên nguồn để gửi những người dùng khác nhau ra khỏi nhiều liên kết của bạn.

FYI, nếu bạn có một bộ định tuyến hỗ trợ VRF , một số điều này thậm chí còn dễ dàng hơn; IIRC, bạn có máy Cisco IOS tại chỗ. Tùy thuộc vào mô hình và hình ảnh phần mềm bạn đã có, Cisco có thể thực hiện một công việc tuyệt vời để cách ly người dùng của bạn với nhau và thực hiện các chính sách định tuyến dựa trên nguồn.

— Mike Pennington
nguồn
Về cơ bản những gì tôi cần là có 4 mạng con cho các khu vực khác nhau của một văn phòng. Một số mạng con sẽ truy cập internet bằng một ISP và một số mạng khác sẽ sử dụng một mạng con khác. Các máy từ các mạng con khác nhau không thể nhìn thấy hoặc kết nối với nhau. NGOẠI TRỪ cho máy chủ 10.1.1.12 cung cấp một số dịch vụ cần có cho tất cả mọi người. Hiện tại tôi chưa thiết lập các quy tắc FORWARD thích hợp cho việc này. Tuy nhiên, vì tất cả các chuyển tiếp được chấp nhận, tôi nghĩ rằng tôi có thể ping từ 10.1.2.20 đến 10.1.1.12.
— El Barto
Hmm ... ok, cảm ơn Mike. Tôi sẽ xem xét sâu hơn về Vlan. Tôi đã nghĩ về nó trước khi bắt đầu tất cả những điều này, và nghĩ rằng tôi sẽ không cần nó. Các công tắc chúng tôi đã hỗ trợ Vlan, mặc dù chúng là các công tắc không được quản lý, vì vậy, nếu tôi không sai, tôi đoán tôi sẽ phải thực hiện gắn thẻ trên bộ định tuyến Debian, phải không? Sự cô lập của các mạng con thực sự không phải là một vấn đề quan trọng trong văn phòng này, nhưng đó là điều tôi nghĩ sẽ tốt nếu có nó không đòi hỏi quá nhiều công việc. Tôi sẽ xem xét nó và xem những gì tôi có thể làm :)
— El Barto
@ElBarto, nếu các thiết bị chuyển mạch của bạn không hỗ trợ gắn thẻ Vlan (và điều đó không thể xảy ra nếu chúng không được quản lý), thì chỉ gắn thẻ trên Debian sẽ không giúp ích. Nếu cách ly mạng con trong văn phòng không phải là vấn đề quan trọng, thì hãy đặt mọi người vào hai mạng con khác nhau và làm cho mọi việc trở nên dễ dàng (hai mạng con đảm bảo bạn có thể định tuyến chính sách trên Debian). Tôi có thể nói rằng lược đồ hiện tại với bốn bí danh giao diện Debian không cung cấp sự cách ly mạng con thực sự và nó làm tăng thêm sự phức tạp.
— Mike Pennington
Điều đó đúng, từ những gì tôi hiểu từ hướng dẫn sử dụng, các công tắc hỗ trợ "giữ thẻ" nhưng không "thực hiện gắn thẻ thực tế". Cảm ơn đã làm rõ về Debian. Vấn đề là ngay cả khi tôi giữ hai mạng con, tôi vẫn sẽ cần máy từ mạng con 10.1.2.0/24 để truy cập vào 10.1.1.12.
— El Barto
Các máy trong một mạng con khác vẫn có thể truy cập 10.1.1.12. Nếu bạn chặn linux gửi ICMP không thể truy cập được iptables, thì bạn vẫn sẽ ghi CPU từ nó gửi tin nhắn ICMP, nhưng ít nhất chúng sẽ không được cài đặt trong các bảng máy chủ của bạn. Điều đó nói rằng, nếu bạn thêm một giao diện ethernet khác trên Debian (nghĩa là dành một giao diện cho mỗi 'lớp' người dùng), Debian không nên gửi ICMP không thể truy cập được nữa; điều đó có nghĩa là bạn có hai bộ chuyển mạch ethernet khác nhau: một cho mỗi 'lớp' của mỗi người dùng. Kỹ thuật viên cáp của bạn sẽ không thích nó, nhưng nó hoàn thành công việc
— Mike Pennington
3

Nó không thực sự rõ ràng những gì bạn đang cố gắng để làm, nhưng tôi có thể nói như sau.

Các mạng con này được kết nối với cùng một giao diện vật lý. Bộ định tuyến Linux sẽ trả về thông báo chuyển hướng ICMP khi gói tin nhận được sẽ được chuyển tiếp qua cùng một giao diện vật lý.

— Khaled
nguồn
Tôi cần xử lý 4 mạng con này, tất cả đều được kết nối thông qua cùng một NIC. Ý tưởng là các máy chủ từ các mạng con khác nhau không thể kết nối với nhau, ngoại trừ máy chủ 10.1.1.12 sẽ có sẵn cho tất cả. Tôi chưa xác định quy tắc chuyển tiếp cho điều này, vì vậy tôi nghĩ rằng bất kỳ máy chủ nào từ bất kỳ mạng con nào cũng có thể đạt tới 10.1.1.12. Có cách nào để tránh chuyển hướng ICMP không?
— El Barto
1
@ElBarto, một phương pháp là thêm một iptablesquy tắc giảm chuyển hướng đi ra ngoàieth1
— Mike Pennington
1

Tôi đồng ý với ý kiến ​​của Khaled và cũng sẽ thêm vào cuối cụm từ của anh ấy:

"Các mạng con này được kết nối với cùng một giao diện vật lý. Bộ định tuyến Linux sẽ trả về thông báo chuyển hướng ICMP khi gói tin nhận được được chuyển tiếp qua cùng một giao diện vật lý" đến cùng một mạng con đích sau đó chuyển hướng yêu cầu đến bước nhảy tiếp theo. Điều đó xảy ra với tôi ngày hôm nay bằng cách sử dụng bộ định tuyến linux Mikrotik và thiết bị LTM bigip LT5.

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
— người dùng352048
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.