Perché succede l'host di reindirizzamento ICMP?

25

Sto configurando un box Debian come router per 4 sottoreti. Per questo ho definito 4 interfacce virtuali sulla scheda NIC a cui è connessa la 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)

Ho altri due computer collegati a questa rete. Uno ha IP 10.1.1.12 (maschera di sottorete 255.255.255.0) e l'altro 10.1.2.20 (maschera di sottorete 255.255.255.0). Voglio essere in grado di raggiungere il 10.1.1.12 dal 10.1.2.20.

Poiché l'inoltro di pacchetti è abilitato nel router e la politica della catena FORWARD è ACCETTA (e non esistono altre regole), capisco che non dovrebbe esserci alcun problema a eseguire il ping dal 10.1.2.20 al 10.1.1.12 attraverso il router.

Tuttavia, questo è quello che ottengo:

$ 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

Perché succede?

Da quello che ho letto la Redirect Hostrisposta ha qualcosa a che fare con il fatto che i due host sono nella stessa rete e che esiste un percorso più breve (o almeno così ho capito). Sono infatti nella stessa rete fisica, ma perché ci sarebbe una via migliore se non si trovassero nella stessa sottorete (non si vedono)?

Cosa mi sto perdendo?

Alcune informazioni extra che potresti voler vedere:

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

Risposte:

22

A prima vista, sembra che Debian stia allungando i confini per l'invio di un reindirizzamento ICMP; citando RFC 792 (Internet Protocol) .

  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.

In questo caso, G1 è 10.1.2.1( eth1:0sopra), X è 10.1.1.0/24e G2 è 10.1.1.12e la sorgente è 10.1.2.20(cioè G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Forse questo è stato storicamente interpretato diversamente nel caso di alias di interfaccia (o indirizzi secondari) sulla stessa interfaccia, ma a rigor di termini non sono sicuro che dovremmo vedere Debian inviare quel reindirizzamento.

A seconda delle esigenze, si potrebbe essere in grado di risolvere questo problema rendendo la sottorete per eth1qualcosa di simile 10.1.0.0/22(indirizzi host da 10.1.0.1- 10.1.3.254) invece di usare degli alias di interfaccia per i singoli /24blocchi ( eth1, eth1:0, eth1:1, eth1:2); se lo hai fatto, dovrai cambiare la maschera di rete di tutti gli host collegati e non sarai in grado di usare 10.1.4.x se non ti espandessi in a /21.

MODIFICARE

Ci stiamo avventurando un po 'al di fuori dell'ambito della domanda originale, ma ti aiuterò a risolvere i problemi di progettazione / sicurezza menzionati nel tuo commento.

Se vuoi isolare gli utenti nel tuo ufficio l'uno dall'altro, facciamo un passo indietro per un secondo e esaminiamo alcuni problemi di sicurezza con quello che hai ora:

Al momento hai quattro sottoreti in un dominio di trasmissione Ethernet. Tutti gli utenti in un dominio di broadcast non soddisfa i requisiti di sicurezza che si articolate nei commenti (tutte le macchine potranno vedere le trasmissioni da altre macchine e potrebbero spontaneamente inviare il traffico tra di loro a Layer2, a prescindere dal loro essere gateway predefinito eth1, eth1:0, eth1:1o eth1:2). Non c'è nulla che il tuo firewall Debian possa fare per cambiare questo (o forse dovrei dire che non c'è niente che il tuo firewall Debian dovrebbe fare per cambiare questo :-).

  • È necessario assegnare gli utenti a Vlans, in base alla politica di sicurezza indicata nei commenti. Un Vlan correttamente configurato farà molto per risolvere i problemi sopra menzionati. Se il tuo switch Ethernet non supporta Vlans, dovresti prenderne uno che lo fa.
  • Per quanto riguarda l'accesso a più domini di sicurezza 10.1.1.12, hai un paio di opzioni:
    • Opzione 1 : dato il requisito per tutti gli utenti di accedere ai servizi 10.1.1.12, è possibile inserire tutti gli utenti in una sottorete IP e implementare politiche di sicurezza con Private Vlans (RFC 5517) , supponendo che lo switch Ethernet supporti questo. Questa opzione non richiederà iptablesregole per limitare il traffico all'interno dell'ufficio dall'attraversamento dei confini di sicurezza (che viene realizzato con i Vlan privati).
    • Opzione 2 : è possibile inserire utenti in diverse sottoreti (corrispondenti a Vlan) e implementare iptablesregole per distribuire le politiche di sicurezza
  • Dopo aver protetto la rete a livello di Vlan, imposta criteri di routing basati sull'origine per inviare diversi utenti ai tuoi uplink multipli.

Cordiali saluti, se si dispone di un router che supporta VRF , alcuni di questi diventano ancora più facili; IIRC, hai una macchina Cisco IOS in loco. A seconda del modello e dell'immagine software che già possiedi, Cisco potrebbe fare un lavoro fantastico isolando gli utenti gli uni dagli altri e implementando politiche di routing basate sull'origine.

— Mike Pennington
fonte
Fondamentalmente quello di cui ho bisogno è avere 4 sottoreti per diverse aree di un ufficio. Alcune sottoreti usciranno su Internet usando un ISP e altre ne useranno una diversa. Le macchine di sottoreti diverse non dovrebbero essere in grado di vedere o connettersi tra loro. TRANNE l'host 10.1.1.12 che offre alcuni servizi che dovrebbero essere disponibili per tutti. Al momento non ho impostato le regole FORWARD appropriate per questo. Tuttavia, poiché tutti i forward sono accettati, ho pensato che avrei potuto eseguire il ping dal 10.1.2.20 al 10.1.1.12.
— El Barto,
Hmm ... ok, grazie Mike. Esaminerò le VLAN in modo più approfondito. Ci avevo pensato prima di iniziare tutto questo e ho pensato che non ne avrei avuto bisogno. Gli switch che abbiamo supportano le VLAN, sebbene siano switch non gestiti, quindi, se non sbaglio, suppongo che dovrò fare il tagging sul router Debian, giusto? L'isolamento delle sottoreti non è in realtà un problema critico in questo ufficio, ma penso che sarebbe bello avere se non richiedesse troppo lavoro extra. Lo esaminerò e vedrò cosa posso fare :)
— El Barto,
@ElBarto, se i tuoi switch non supportano il tagging Vlan (e questo è improbabile se non sono gestiti), allora solo taggare su Debian non sarebbe d'aiuto. Se l'isolamento della sottorete all'interno dell'ufficio non è un problema critico, metti tutti in due diverse sottoreti e semplifica le cose (due sottoreti assicurano che tu possa instradare i criteri su Debian). Direi che l'attuale schema con quattro alias di interfaccia Debian non offre alcun reale isolamento di sottorete e aggiunge molta più complicazione.
— Mike Pennington,
Proprio così, da quello che ho capito dal manuale dell'utente, gli switch supportano "mantenere il tag" ma non "fare il tag effettivo". Grazie per il chiarimento su Debian. Il fatto è che anche se mantengo due sottoreti, avrò comunque bisogno di macchine dalla sottorete 10.1.2.0/24 per accedere a 10.1.1.12.
— El Barto,
Le macchine in una sottorete diversa dovrebbero comunque poter accedere 10.1.1.12. Se blocchi linux dall'invio di ICMP non raggiungibile con iptables, allora brucerai comunque la CPU inviando i messaggi ICMP, ma almeno non verranno installati nelle tue tabelle host. Detto questo, se si aggiunge un'altra interfaccia ethernet su Debian (cioè si dedica un'interfaccia per 'classe' utente), Debian non dovrebbe più inviare ICMP non raggiungibile; ciò implicherebbe che hai due diversi switch Ethernet: uno per ogni 'classe' di utente. Ai vostri tecnici di cablaggio non piacerebbe, ma riesce a fare il lavoro
— Mike Pennington,
3

Non è davvero chiaro cosa stai cercando di fare, ma posso dire quanto segue.

Queste sottoreti sono collegate alla stessa interfaccia fisica. Il router Linux restituirà il messaggio di reindirizzamento ICMP quando il pacchetto ricevuto deve essere inoltrato sulla stessa interfaccia fisica.

— Khaled
fonte
Devo gestire queste 4 sottoreti che sono tutte collegate attraverso la stessa scheda NIC. L'idea è che gli host delle diverse sottoreti non dovrebbero essere in grado di connettersi tra loro, ad eccezione dell'host 10.1.1.12 che dovrebbe essere disponibile per tutti. Non ho ancora definito le regole forward per questo, quindi ho pensato che qualsiasi host proveniente da una di queste sottoreti dovrebbe essere in grado di raggiungere il 10.1.1.12. Esiste un modo per evitare il reindirizzamento ICMP?
— El Barto,
1
@ElBarto, un metodo consiste nell'aggiungere una iptablesregola che elimina i reindirizzamenti in uscitaeth1
— Mike Pennington,
1

Sono d'accordo con i commenti di Khaled e aggiungerei anche alla fine della sua frase:

"Queste sottoreti sono collegate alla stessa interfaccia fisica. Il router Linux restituirà il messaggio di reindirizzamento ICMP quando il pacchetto ricevuto deve essere inoltrato sulla stessa interfaccia fisica" alla stessa sottorete di destinazione, quindi reindirizzando la richiesta all'hop successivo. Oggi mi capita di usare un router Linux Mikrotik e un dispositivo 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
— user352048
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.