¿Por qué sucede ICMP Redirect Host?

25

Estoy configurando un cuadro de Debian como un enrutador para 4 subredes. Para eso he definido 4 interfaces virtuales en la NIC donde está conectada 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)

Tengo otras dos computadoras conectadas a esta red. Uno tiene IP 10.1.1.12 (máscara de subred 255.255.255.0) y el otro 10.1.2.20 (máscara de subred 255.255.255.0). Quiero poder llegar a 10.1.1.12 desde 10.1.2.20.

Como el reenvío de paquetes está habilitado en el enrutador y la política de la cadena FORWARD es ACEPTAR (y no hay otras reglas), entiendo que no debería haber ningún problema para hacer ping desde 10.1.2.20 a 10.1.1.12 pasando por el enrutador.

Sin embargo, esto es lo que obtengo:

$ 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

¿Por qué pasó esto?

Por lo que he leído, la Redirect Hostrespuesta tiene algo que ver con el hecho de que los dos hosts están en la misma red y hay una ruta más corta (o eso entendí). De hecho, están en la misma red física, pero ¿por qué habría una mejor ruta si no están en la misma subred (no pueden verse)?

¿Qué me estoy perdiendo?

Alguna información adicional que tal vez quieras ver:

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

Respuestas:

22

A primera vista, parece que Debian está extendiendo los límites para enviar una redirección ICMP; citando RFC 792 (Protocolo de 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.

En este caso, G1 es 10.1.2.1( eth1:0arriba), X es 10.1.1.0/24y G2 es 10.1.1.12, y la fuente es 10.1.2.20( es decir G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Tal vez esto se ha interpretado históricamente de manera diferente en el caso de alias de interfaz (o direcciones secundarias) en la misma interfaz, pero estrictamente hablando, no estoy seguro de que debamos ver a Debian enviar esa redirección.

Dependiendo de sus necesidades, es posible que pueda resolver esto haciendo la subred para eth1algo así como 10.1.0.0/22(direcciones de host de 10.1.0.1- 10.1.3.254) en lugar de utilizar los alias de interfaz para individuales /24bloques ( eth1, eth1:0, eth1:1, eth1:2); Si hizo esto, deberá cambiar la máscara de red de todos los hosts conectados y no podrá usar 10.1.4.x a menos que se haya expandido a a /21.

EDITAR

Nos aventuramos un poco fuera del alcance de la pregunta original, pero ayudaré a resolver los problemas de diseño / seguridad mencionados en su comentario.

Si desea aislar a los usuarios de su oficina entre sí, retrocedamos un segundo y analicemos algunos problemas de seguridad con lo que tiene ahora:

Actualmente tiene cuatro subredes en un dominio de difusión de Ethernet. Todos los usuarios de un dominio de difusión no cumple con los requisitos de seguridad que se articulan en los comentarios (todas las máquinas verán las transmisiones de otras máquinas y podría enviar tráfico de forma espontánea entre sí en capa 2, independientemente de su ser puerta de enlace predeterminada eth1, eth1:0, eth1:1o eth1:2). No hay nada que su firewall de Debian pueda hacer para cambiar esto (o tal vez debería decir que no hay nada que su firewall de Debian deba hacer para cambiar esto :-).

  • Debe asignar usuarios a Vlans, de acuerdo con la política de seguridad establecida en los comentarios. Un Vlan configurado correctamente contribuirá en gran medida a solucionar los problemas mencionados anteriormente. Si su conmutador ethernet no admite Vlans, debería obtener uno que sí lo haga.
  • Con respecto al acceso a múltiples dominios de seguridad 10.1.1.12, tiene un par de opciones:
    • Opción 1 : dado el requisito de que todos los usuarios accedan a los servicios 10.1.1.12, puede colocar a todos los usuarios en una subred IP e implementar políticas de seguridad con Vlans privados (RFC 5517) , suponiendo que su conmutador Ethernet lo admita. Esta opción no requerirá iptablesreglas para limitar el tráfico dentro de la oficina al cruzar los límites de seguridad (eso se logra con Vlans privados).
    • Opción 2 : puede colocar a los usuarios en subredes diferentes (correspondientes a Vlans) e implementar iptablesreglas para implementar sus políticas de seguridad
  • Después de haber asegurado su red en el nivel Vlan, configure políticas de enrutamiento basadas en la fuente para enviar a diferentes usuarios a sus múltiples enlaces ascendentes.

Para su información, si tiene un enrutador que admite VRF , algo de esto se vuelve aún más fácil; IIRC, tiene una máquina Cisco IOS en el sitio. Dependiendo del modelo y la imagen de software que ya tenga, Cisco podría hacer un trabajo fantástico al aislar a sus usuarios entre sí e implementar políticas de enrutamiento basadas en la fuente.

— Mike Pennington
fuente
Básicamente, lo que necesito es tener 4 subredes para diferentes áreas de una oficina. Algunas subredes saldrán a Internet utilizando un ISP y otras utilizarán uno diferente. Las máquinas de diferentes subredes no deberían poder verse ni conectarse entre sí. EXCEPTO para el host 10.1.1.12 que ofrece algunos servicios que deberían estar disponibles para todos. Actualmente no he configurado las reglas ADELANTE apropiadas para esto. Sin embargo, como se aceptan todos los reenvíos, pensé que debería poder hacer ping desde 10.1.2.20 a 10.1.1.12.
— El Barto
Hmm ... ok, gracias Mike. Examinaré las VLAN más profundamente. Lo había pensado antes de comenzar todo esto, y pensé que no lo necesitaría. Los conmutadores que tenemos admiten VLAN, aunque son conmutadores no administrados, así que, si no me equivoco, supongo que tendré que etiquetar en el enrutador Debian, ¿verdad? El aislamiento de las subredes en realidad no es un problema crítico en esta oficina, pero es algo que creo que sería bueno tener si no requiere demasiado trabajo adicional. Lo investigaré y veré qué puedo hacer :)
— El Barto
@ElBarto, si sus conmutadores no son compatibles con el etiquetado de Vlan (y eso es poco probable si no están administrados), entonces solo etiquetar en Debian no ayudaría. Si el aislamiento de subred dentro de la oficina no es un problema crítico, coloque a todos en dos subredes diferentes y facilite las cosas (dos subredes aseguran que pueda enrutar las políticas en Debian). Diría que el esquema actual con cuatro alias de interfaz Debian no ofrece un aislamiento de subred real, y agrega mucha más complicación.
— Mike Pennington
Así es, por lo que entiendo del manual del usuario, los interruptores admiten "mantener la etiqueta" pero no "hacer el etiquetado real". Gracias por la aclaración sobre Debian. La cuestión es que incluso si mantengo dos subredes, aún necesitaré máquinas de la subred 10.1.2.0/24 para acceder a 10.1.1.12.
— El Barto
Las máquinas en una subred diferente aún deberían poder acceder 10.1.1.12. Si bloquea el envío de linux de ICMP inalcanzables iptables, aún quemará la CPU enviando los mensajes ICMP, pero al menos no se instalarán en sus tablas de host. Dicho esto, si agrega otra interfaz de ethernet en Debian (es decir, dedica una interfaz por 'clase' de usuario), Debian ya no debería enviar ICMP inalcanzables; eso implicaría que tiene dos conmutadores ethernet diferentes: uno para cada 'clase' de usuario. A sus técnicos de cableado no les gustaría, pero hace el trabajo
— Mike Pennington
3

No está realmente claro lo que está tratando de hacer, pero puedo decir lo siguiente.

Estas subredes están conectadas a la misma interfaz física. El enrutador Linux devolverá el mensaje de redireccionamiento ICMP cuando el paquete recibido se reenvíe a través de la misma interfaz física.

— Khaled
fuente
Necesito manejar estas 4 subredes que están conectadas a través de la misma NIC. La idea es que los hosts de las diferentes subredes no deberían poder conectarse entre sí, excepto el host 10.1.1.12, que debería estar disponible para todos. Todavía no he definido las reglas de reenvío para esto, por lo que pensé que cualquier host de cualquiera de esas subredes debería poder llegar a 10.1.1.12. ¿Hay alguna forma de evitar la redirección ICMP?
— El Barto
1
@ElBarto, un método es agregar una iptablesregla que elimine las redirecciones que saleneth1
— Mike Pennington
1

Estoy de acuerdo con los comentarios de Khaled y también agregaría al final de su frase:

"Estas subredes están conectadas a la misma interfaz física. El enrutador Linux devolverá el mensaje de redireccionamiento ICMP cuando el paquete recibido se reenvíe a través de la misma interfaz física" a la misma subred de destino y luego redirija la solicitud al siguiente salto. Eso me pasa hoy usando un enrutador Linux Mikrotik y un dispositivo 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
— usuario352048
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.