ICMP Yönlendirme Ana Bilgisayarı neden oluyor?

25

4 alt ağ için yönlendirici olarak bir Debian kutusu ayarlıyorum. Bunun için NIC'de LAN'ın bağlı olduğu 4 sanal arayüz tanımladım ( 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)

Bu ağa bağlı iki tane daha bilgisayarım var. Birinde IP 10.1.1.12 (alt ağ maskesi 255.255.255.0) ve diğerinde 10.1.2.20 (alt ağ maskesi 255.255.255.0) vardır. 10.1.2.20'den 10.1.1.12'ye ulaşmak istiyorum.

Yönlendiricide paket iletme etkinleştirildiğinden ve FORWARD zincirinin politikası KABUL EDIYOR (ve başka bir kural yoktur), 10.1.2.20'den 10.1.1.12'ye yönlendiriciden geçerken herhangi bir sorun yaşanmaması gerektiğini biliyorum.

Ancak, bu ne alıyorum:

$ 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

Bu neden oluyor?

Okuduklarımdan itibaren Redirect Hostcevap, iki ana bilgisayarın aynı ağda olması ve daha kısa bir rota olması (ya da anladım) olmasıyla ilgili. Aslında aynı fiziksel ağdalar, ancak aynı alt ağda değillerse (birbirlerini göremiyorlarsa) neden daha iyi bir rota olsun ki?

Neyi kaçırıyorum?

Görmek isteyebileceğiniz bazı ekstra bilgiler:

# 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
kaynak

Yanıtlar:

22

İlk bakışta, Debian ICMP yönlendirmesi göndermek için sınırları zorluyor gibi görünüyor; alıntı RFC 792 (İnternet Protokolü) .

  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.

Bu durumda, G1 10.1.2.1( eth1:0yukarıda), X 10.1.1.0/24ve G2'dir 10.1.1.12ve kaynak 10.1.2.20(yani G2 and the host identified by the internet source address of the datagram are **NOT** on the same network) ' dır . Belki de bu, aynı arayüzdeki arayüz takma adları (veya ikincil adresler) durumunda tarihsel olarak farklı yorumlanmıştır, ancak kesinlikle, Debian'ın bu yönlendirmeyi gönderdiğini görmemiz gerektiğinden emin değilim.

İhtiyaca göre, sizin için alt ağ yaparak çözmek mümkün olabilir eth1gibi bir şey 10.1.0.0/22(den host adresleri 10.1.0.1- 10.1.3.254) yerine bireysel için arayüz takma adları kullanarak /24blokları ( eth1, eth1:0, eth1:1, eth1:2); Bunu yaptıysanız, ekli tüm ana bilgisayarların ağ maskesini değiştirmeniz gerekecektir ve siz genişlemediğiniz sürece 10.1.4.x kullanamazsınız /21.

DÜZENLE

Orijinal sorunun kapsamı dışına biraz çıkıyoruz, ancak yorumunuzda belirtilen tasarım / güvenlik sorunları üzerinde çalışmanıza yardımcı olacağım.

Ofisinizdeki kullanıcıları birbirinden ayırmak istiyorsanız, bir saniye geriye gidelim ve şu anda sahip olduğunuz bazı güvenlik sorunlarına göz atalım:

Şu anda bir ethernet yayın etki alanında dört alt ağınız var. Bir yayın Alandaki tüm kullanıcılar yorumlarınızla belden güvenlik gereksinimlerini karşılamıyor (tüm makineler diğer makinelerden yayınları görür ve kendiliğinden Layer2 birbirine trafik göndermek olabilir, ne olursa olsun, varsayılan ağ geçidi varlığının eth1, eth1:0, eth1:1veya eth1:2). Debian güvenlik duvarınızın bunu değiştirmek için yapabileceği hiçbir şey yoktur (veya belki de Debian güvenlik duvarınızın bunu değiştirmek için yapması gereken hiçbir şey olmadığını söylemeliyim :-).

  • Yorumlarda belirtilen güvenlik politikasına dayanarak kullanıcıları Vlans'a atamanız gerekir. Düzgün yapılandırılmış bir Vlan yukarıda belirtilen sorunları çözmek için uzun bir yol kat edecektir. Ethernet anahtarınız Vlans'ı desteklemiyorsa, bir tane edinmelisiniz.
  • Erişilen çoklu güvenlik alanlarıyla ilgili olarak 10.1.1.12, birkaç seçeneğiniz vardır:
    • Seçenek 1 : Tüm kullanıcıların hizmetlere erişme zorunluluğu göz önüne alındığında, 10.1.1.12tüm kullanıcıları bir IP alt ağına koyabilir ve ethernet anahtarınızın bunu desteklediğini düşünerek , Özel Vlans ile güvenlik politikaları uygulayabilirsiniz (RFC 5517) . Bu seçenek, iptablesofis içi trafiği güvenlik sınırlarını aşmakla sınırlandıracak kurallar gerektirmez (bu, özel Vlans'lerle yapılır).
    • 2. Seçenek : Sen olabilir farklı alt kullanıcıları (VLAN'lar için gelen) koymak ve uygulamak iptablesiçin güvenlik politikaları dağıtmak için kurallar
  • Ağınızı Vlan düzeyinde güvenceye aldıktan sonra, farklı kullanıcıları birden fazla bağlantınız üzerinden göndermek için kaynak tabanlı yönlendirme politikaları ayarlayın .

FYI, VRF'leri destekleyen bir yönlendiriciniz varsa , bunların bazıları daha da kolaylaşıyor; IIRC, yerinde bir Cisco IOS makineniz var. Sahip olduğunuz model ve yazılım görüntüsüne bağlı olarak, Cisco, kullanıcılarınızı birbirinden izole etmek ve kaynak tabanlı yönlendirme politikaları uygulamak için harika bir iş yapabilir .

— Mike Pennington
kaynak
Temelde ihtiyacım olan şey bir ofisin farklı alanları için 4 alt ağa sahip olmak. Bazı alt ağlar, bir ISS kullanarak internete girecek, diğerleri ise farklı bir tane kullanacaktır. Farklı alt ağlardan gelen makineler birbirlerini görmemeli veya bağlanmamalıdır. Herkese açık olması gereken bazı hizmetleri sunan 10.1.1.12 ev sahibi için istisna. Şimdilik bunun için uygun FORWARD kurallarını belirleyemedim. Ancak, tüm iletiler kabul edildiğinden, 10.1.2.20'den 10.1.1.12'ye ping yapabilmem gerektiğini düşündüm.
— El Barto
Hmm ... tamam, teşekkürler Mike. VLAN'ları daha derinden inceleyeceğim. Bütün bunlara başlamadan önce düşünmüştüm ve ihtiyacım olmayacağını düşündüm. Yaptığımız anahtarlar VLAN'ları destekliyorlar, ancak bunlar yönetilmeyen anahtarlar olsa da, yanlış değilsem, Debian yönlendiricisinde etiketlemeyi yapmak zorunda kalacağım, değil mi? Alt ağların yalıtılması, aslında bu ofiste kritik bir sorun değil, ancak çok fazladan çalışma gerektirmiyorsa, bunun iyi olacağını düşündüğüm bir şey.
— Bakacağım
@ElBarto, anahtarlarınız Vlan etiketlemeyi desteklemiyorsa (ve bunlar yönetilmezse bu mümkün değildir), o zaman yalnızca Debian'da etiketlemek yardımcı olmaz. Ofis içi alt ağ yalıtımı kritik bir sorun değilse, herkesi iki farklı alt ağa koyun ve işleri kolaylaştırın (iki alt ağ Debian'da politika izlemenizi sağlar). Dört Debian arabirim takma adı olan mevcut şemanın gerçek bir alt ağ yalıtımı sunmadığını ve çok daha fazla karmaşıklık eklediğini söyleyebilirim.
— Mike Pennington
Bu doğru, kullanım kılavuzundan anladığım kadarıyla anahtarlar "etiketi tutmak" ancak "gerçek etiketlemeyi yapmak" anlamına geliyor. Debian ile ilgili açıklama için teşekkürler. Mesele şu ki, iki alt ağı tutsam bile, 10.1.2.0/24 alt ağından 10.1.1.12'ye erişmek için makinelere ihtiyacım olacak.
— El Barto
Farklı bir alt ağdaki makineler hala erişebilmelidir 10.1.1.12. Linux'un ICMP'ye erişilemeyenleri göndermesini engellerseniz iptables, yine de CPU'yu ICMP iletilerini göndermesini önlersiniz, ancak en azından ana bilgisayar tablolarınıza yüklenmezler. Yani Debian (yani adamak bir arayüz kullanıcı 'sınıf' başına), Debian başka ethernet arayüzü eklerseniz, söz konusu olmalıdır göndermez ICMP artık Unreachables; bu iki farklı ethernet anahtarına sahip olduğunuz anlamına gelir: her kullanıcı için bir 'class'. Kablolama teknisyenleriniz bundan hoşlanmaz, ancak işi halleder
— Mike Pennington
3

Ne yapmaya çalıştığınız belli değil, ancak şunu söyleyebilirim.

Bu alt ağlar aynı fiziksel arayüze bağlanır. Linux yönlendiricisi, alınan paketin aynı fiziksel arayüz üzerinden iletilmesi gerektiğinde ICMP yönlendirme iletisini döndürür.

— Halid
kaynak
Hepsi aynı NIC üzerinden bağlı olan bu 4 alt ağı kullanmam gerekiyor. Buradaki düşünce, farklı alt ağlardan gelen ana bilgisayarların, herkes için mevcut olması gereken ana bilgisayar 10.1.1.12 dışında birbirleriyle bağlantı kuramaması gerektiğidir. Bunun için henüz ileriye yönelik kuralları tanımlamamıştım, bu yüzden bu alt ağlardan herhangi bir konağın 10.1.1.12'ye ulaşması gerektiğini düşündüm. ICMP yönlendirmesini engellemenin bir yolu var mı?
— El Barto
1
@ElBarto, bir yöntem, iptablesçıkan yönlendirmeleri bırakan bir kural eklemektireth1
— Mike Pennington
1

Khaled'in yorumlarına katılıyorum ve ifadesinin sonuna da ekleyeceğim:

"Bu alt ağlar aynı fiziksel arayüze bağlı. Linux yönlendirici, alınan paketin aynı fiziksel arayüz üzerinden iletilmesi gerektiğinde, ICMP yönlendirme iletisini" aynı hedef alt ağa iletecek ve isteği bir sonraki sekmeye yönlendirecek. Bugün bana bir Mikrotik linux yönlendirici ve bir F5 bigip LTM cihazı kullanarak başıma geldi.

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
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.