25 votos

¿Por qué Redirección ICMP Host suceder?

Estoy configurando un Debian cuadro como un router para 4 subredes. Por lo que he definido 4 interfaces virtuales en la NIC donde la LAN está conectado (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 otros dos equipos conectados 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 ser capaz de llegar a 10.1.1.12 de 10.1.2.20.

Desde el reenvío de paquetes está habilitado en el enrutador y la política de la cadena FORWARD es ACEPTAR (y que 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 router.

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é sucede esto?

Por lo que he leído la Redirect Host respuesta tiene algo que ver con el hecho de que los dos equipos estén en la misma red y no ser una ruta más corta (o eso he entendido). En realidad están en la misma red física, pero, ¿por qué no ser una ruta mejor si no están en la misma subred (que no puede ver a los demás)?

Lo que me estoy perdiendo?

Algo más de información que se desee para 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 

22voto

Mike Pennington Puntos 6056

A primera vista, parece que Debian es el estiramiento de los límites para enviar un ICMP redirect; 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:0 anterior), X es 10.1.1.0/24 y G2 es 10.1.1.12, y el origen 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, históricamente, ha sido interpretado de manera diferente en el caso de la interfaz de alias (o direcciones secundarias) en la misma interfaz, pero estrictamente hablando, no estoy seguro de que deberíamos ver Debian enviar que redirigir.

Dependiendo de sus necesidades, usted podría ser capaz de solucionar haciendo en la subred eth1 algo como 10.1.0.0/22 (direcciones de host de 10.1.0.1 - 10.1.3.254) en lugar de usar interfaz de alias para el individuo /24 bloques (eth1, eth1:0, eth1:1, eth1:2); si usted hace esto, entonces usted necesitará cambiar la máscara de red de todos los hosts conectados y usted no será capaz de utilizar 10.1.4.x a menos que se expandió a una /21.

EDITAR

Estamos aventurando un poco fuera del alcance de la pregunta original, pero voy a ayudar a trabajar a través del diseño/cuestiones de seguridad mencionado en tu comentario.

Si desea aislar a los usuarios en la oficina de cada uno de los otros, vamos un paso atrás por un segundo y mirar algunos problemas de seguridad con lo que tenemos ahora:

Actualmente tiene cuatro subredes en una ethernet dominio de difusión. Todos los usuarios de un dominio de difusión no cumple con los requisitos de seguridad que se articula en los comentarios (todos los equipos se verán las emisiones de otros máquinas y podría espontáneamente enviar el tráfico a cada uno de los otros en Layer2, independientemente de su puerta de enlace predeterminada eth1, eth1:0, eth1:1 o eth1:2). No hay nada de tu Debian firewall puede hacer para cambiar esto (o tal vez debería decir que no hay nada de tu Debian firewall debe hacer para cambiar esto :-).

  • Es necesario asignar a los usuarios en las redes Vlan, basado en la política de seguridad indicado en los comentarios. La Vlan configurada va a ir un largo camino para solucionar los problemas mencionados anteriormente. Si su conmutador ethernet no soporta Vlan, usted debe conseguir uno que lo hace.
  • Con respecto a los múltiples dominios de seguridad de acceso 10.1.1.12, usted tiene un par de opciones:
    • Opción 1: Dado el requisito de que todos los usuarios para acceder a los servicios en 10.1.1.12, podría poner todos los usuarios en una subred IP e implementar políticas de seguridad con redes Privadas (RFC 5517), suponiendo que el interruptor de ethernet soporta esto. Esta opción no requieren iptables reglas para limitar el comercio intra-oficina de tráfico de cruce de los límites de seguridad (que se logra con redes privadas).
    • Opción 2: Usted podría poner a los usuarios en diferentes subredes (correspondiente a la Vlan) y aplicar iptables reglas para implementar sus políticas de seguridad
  • Después de haber obtenido su red en la Vlan de nivel, configurar la fuente de enrutamiento basado en políticas para enviar diferentes de los usuarios de sus múltiples enlaces ascendentes.

Para su INFORMACIÓN, si usted tiene un router que soporta VRFs, algunos de esto se pone aún más fácil; si mal no recuerdo, tiene un Cisco IOS máquina local. Dependiendo del modelo y de imagen de software que ya se tiene, de que Cisco podría hacer un trabajo fantástico aislar los usuarios de cada uno de los otros y fuente de implementar el enrutamiento basado en políticas.

3voto

Khaled Puntos 21517

No es muy claro lo que estamos tratando de hacer, pero puedo decir lo siguiente.

Estas subredes están conectados a la misma interfaz física. Linux router volverá mensaje de redirección ICMP cuando la recibió un paquete debe ser enviado a través de la misma interfaz física.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: