Dlaczego zdarza się host przekierowania ICMP?

25

Konfiguruję okno Debiana jako router dla 4 podsieci. W tym celu zdefiniowałem 4 wirtualne interfejsy na karcie sieciowej, do której podłączona jest sieć LAN ( 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)

Mam dwa inne komputery podłączone do tej sieci. Jeden ma IP 10.1.1.12 (maska ​​podsieci 255.255.255.0), a drugi 10.1.2.20 (maska ​​podsieci 255.255.255.0). Chcę być w stanie dotrzeć do 10.1.1.12 od 10.1.2.20.

Ponieważ przekazywanie pakietów jest włączone w routerze, a zasadą łańcucha FORWARD jest AKCEPTUJ (i nie ma innych reguł), rozumiem, że nie powinno być problemu z pingowaniem od 10.1.2.20 do 10.1.1.12 przechodzącego przez router.

Jednak to, co otrzymuję:

$ 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

Dlaczego to się dzieje?

Z tego, co przeczytałem, Redirect Hostodpowiedź ma coś wspólnego z faktem, że dwa hosty są w tej samej sieci i istnieje krótsza trasa (a przynajmniej tak rozumiem). Są w rzeczywistości w tej samej sieci fizycznej, ale dlaczego miałaby być lepsza trasa, gdyby nie znajdowali się w tej samej podsieci (nie widzą się nawzajem)?

czego mi brakuje?

Niektóre dodatkowe informacje, które możesz chcieć zobaczyć:

# 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
źródło

Odpowiedzi:

22

Na pierwszy rzut oka wygląda na to, że Debian przesuwa granice wysyłania przekierowania ICMP; przytaczając RFC 792 (protokół internetowy) .

  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.

W tym przypadku G1 oznacza 10.1.2.1( eth1:0powyżej), X jest, 10.1.1.0/24a G2 jest 10.1.1.12, a źródłem jest 10.1.2.20(tj G2 and the host identified by the internet source address of the datagram are **NOT** on the same network.). Być może było to historycznie interpretowane inaczej w przypadku aliasów interfejsów (lub adresów dodatkowych) na tym samym interfejsie, ale ściśle mówiąc, nie jestem pewien, czy powinniśmy zobaczyć, jak Debian wysyła to przekierowanie.

W zależności od potrzeb, może być w stanie rozwiązać ten problem poprzez podsieć na eth1coś podobnego 10.1.0.0/22(adresy hostów z 10.1.0.1- 10.1.3.254) zamiast używać aliasów interfejsów dla poszczególnych /24bloków ( eth1, eth1:0, eth1:1, eth1:2); jeśli to zrobisz, musisz zmienić maskę sieci wszystkich podłączonych hostów i nie będziesz mógł używać wersji 10.1.4.x, chyba że rozwinąłeś się do /21.

EDYTOWAĆ

Podejmujemy się trochę poza zakresem pierwotnego pytania, ale pomogę w rozwiązaniu problemów projektowych / bezpieczeństwa wymienionych w twoim komentarzu.

Jeśli chcesz oddzielić użytkowników w biurze od siebie, cofnijmy się o chwilę i spójrzmy na niektóre problemy związane z bezpieczeństwem:

Obecnie masz cztery podsieci w jednej domenie rozgłoszeniowej Ethernet. Wszyscy użytkownicy w jednej domenie transmisji nie spełnia wymogów bezpieczeństwa ty wyrażone w komentarzach (wszystkie maszyny zobaczymy transmisje z innych maszyn i może spontanicznie wysłać ruch do siebie na layer2, niezależnie od ich bramy domyślnej samopoczucia eth1, eth1:0, eth1:1lub eth1:2). Nic nie może zrobić zapora sieciowa Debiana, aby to zmienić (a może powinienem powiedzieć, że nic nie powinna zrobić zapora sieciowa Debiana :-).

  • Musisz przypisać użytkowników do sieci Vlans, zgodnie z polityką bezpieczeństwa podaną w komentarzach. Prawidłowo skonfigurowany Vlan przejdzie długą drogę do rozwiązania wyżej wymienionych problemów. Jeśli twój przełącznik ethernetowy nie obsługuje Vlansów, powinieneś dostać taki, który to robi.
  • Jeśli chodzi o dostęp do wielu domen bezpieczeństwa 10.1.1.12, masz kilka opcji:
    • Opcja 1 : Biorąc pod uwagę wymóg, aby wszyscy użytkownicy mieli dostęp do usług 10.1.1.12, możesz umieścić wszystkich użytkowników w jednej podsieci IP i wdrożyć zasady bezpieczeństwa za pomocą Private Vlans (RFC 5517) , zakładając, że twój przełącznik ethernetowy to obsługuje. Ta opcja nie będzie wymagać iptablesreguł ograniczających ruch wewnątrz biura przekraczający granice bezpieczeństwa (co jest osiągane za pomocą prywatnych sieci Vlan).
    • Opcja 2 : Ty mógł umieścić użytkowników na różne podsieci (odpowiadające VLAN) i wdrożyć iptableszasady wdrażania zasady zabezpieczeń
  • Po zabezpieczeniu sieci na poziomie Vlan skonfiguruj oparte na źródłach zasady routingu, aby wysyłać różnych użytkowników do wielu łączy w górę .

Do Twojej dyspozycji, jeśli masz router obsługujący VRF , niektóre z nich stają się jeszcze łatwiejsze; IIRC, masz u siebie komputer Cisco IOS. W zależności od modelu i obrazu oprogramowania, który już masz, Cisco może wykonać fantastyczną robotę, izolując użytkowników od siebie i wdrażając zasady routingu oparte na źródłach.

— Mike Pennington
źródło
Zasadniczo potrzebuję mieć 4 podsieci dla różnych obszarów biura. Niektóre podsieci wychodzą do Internetu za pomocą jednego usługodawcy internetowego, a inne korzystają z innego. Maszyny z różnych podsieci nie powinny widzieć się ani łączyć ze sobą. Z WYJĄTKIEM dla hosta 10.1.1.12, który oferuje niektóre usługi, które powinny być dostępne dla wszystkich. Obecnie nie skonfigurowałem do tego odpowiednich reguł FORWARD. Ponieważ jednak wszystkie naprzód są akceptowane, pomyślałem, że powinienem móc pingować od 10.1.2.20 do 10.1.1.12.
— El Barto,
Hmm ... ok, dzięki Mike. Zagłębię się w sieci VLAN. Myślałem o tym przed rozpoczęciem tego wszystkiego i pomyślałem, że nie będę tego potrzebował. Przełączniki, które mamy, obsługują sieci VLAN, chociaż są to przełączniki niezarządzane, więc jeśli się nie mylę, myślę, że będę musiał wykonać tagowanie na routerze Debian, prawda? Izolacja podsieci nie jest tak naprawdę istotnym problemem w tym biurze, ale myślę, że dobrze byłoby, gdyby nie wymagała zbyt wiele pracy. Zajrzę do tego i zobaczę, co da się zrobić :)
— El Barto,
@ElBarto, jeśli twoje przełączniki nie obsługują tagowania Vlan (i jest to mało prawdopodobne, jeśli nie są zarządzane), to tylko tagowanie na Debianie nie pomogłoby. Jeśli izolacja podsieci wewnątrz biura nie jest krytycznym problemem, umieść wszystkich w dwóch różnych podsieciach i ułatw sobie (dwie podsieci zapewniają, że możesz ustalać trasy na Debianie). Powiedziałbym, że obecny schemat z czterema aliasami interfejsu Debiana nie zapewnia rzeczywistej izolacji podsieci i dodaje znacznie więcej komplikacji.
— Mike Pennington,
Zgadza się, z tego, co rozumiem z instrukcji obsługi, przełączniki obsługują „utrzymywanie znacznika”, ale nie „faktyczne tagowanie”. Dziękujemy za wyjaśnienie dotyczące Debiana. Chodzi o to, że nawet jeśli mam dwie podsieci, nadal będę potrzebować maszyn z podsieci 10.1.2.0/24, aby uzyskać dostęp do 10.1.1.12.
— El Barto
Maszyny w innej podsieci powinny nadal mieć dostęp 10.1.1.12. Jeśli zablokujesz linuksowi wysyłanie nieosiągalnych ICMP iptables, nadal będziesz spalał procesor, wysyłając wiadomości ICMP, ale przynajmniej nie zostaną zainstalowane w twoich tabelach hosta. To powiedziawszy, jeśli dodasz inny interfejs ethernetowy w Debianie (tj. Poświęcisz jeden interfejs na „klasę” użytkownika), Debian nie powinien już wysyłać ICMP nieosiągalnych; oznaczałoby to, że masz dwa różne przełączniki Ethernet: jeden dla każdej „klasy” użytkownika. Twoi technicy okablowania nie lubią tego, ale wykonuje zadanie
— Mike Pennington,
3

Nie jest do końca jasne, co próbujesz zrobić, ale mogę powiedzieć, co następuje.

Te podsieci są podłączone do tego samego interfejsu fizycznego. Router Linux zwróci komunikat przekierowania ICMP, gdy otrzymany pakiet powinien zostać przekazany przez ten sam interfejs fizyczny.

— Khaled
źródło
Muszę obsłużyć te 4 podsieci, które są połączone za pośrednictwem tej samej karty sieciowej. Chodzi o to, że hosty z różnych podsieci nie powinny być w stanie łączyć się ze sobą, z wyjątkiem hosta 10.1.1.12, który powinien być dostępny dla wszystkich. Nie zdefiniowałem jeszcze reguł przekazywania dla tego, więc pomyślałem, że każdy host z dowolnej z tych podsieci powinien mieć możliwość uzyskania dostępu do 10.1.1.12. Czy jest jakiś sposób na uniknięcie przekierowania ICMP?
— El Barto
1
@ElBarto, jedną z metod jest dodanie iptablesreguły, która upuszcza przekierowania wychodząceeth1
— Mike Pennington,
1

Zgadzam się z komentarzami Khaleda i dodałbym również na końcu jego zdania:

„Te podsieci są podłączone do tego samego interfejsu fizycznego. Router Linux zwróci komunikat przekierowania ICMP, gdy otrzymany pakiet powinien zostać przekazany przez ten sam interfejs fizyczny” do tej samej docelowej podsieci, a następnie przekieruje żądanie do następnego przeskoku. Zdarzyło mi się to dzisiaj przy użyciu routera linux Mikrotik i urządzenia LTM bigip F5.

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
— użytkownik352048
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.