Por que o host de redirecionamento ICMP acontece?

25

Estou configurando uma caixa Debian como roteador para 4 sub-redes. Para isso, defini 4 interfaces virtuais na NIC em que a LAN está conectada ( 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)

Eu tenho dois outros computadores conectados a esta rede. Um tem o IP 10.1.1.12 (máscara de sub-rede 255.255.255.0) e o outro 10.1.2.20 (máscara de sub-rede 255.255.255.0). Quero poder acessar 10.1.1.12 a partir de 10.1.2.20.

Como o encaminhamento de pacotes está ativado no roteador e a política da cadeia FORWARD é ACEITAR (e não há outras regras), entendo que não deve haver nenhum problema para executar o ping entre 10.1.2.20 e 10.1.1.12 no roteador.

No entanto, é isso que recebo:

$ 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 que isso acontece?

Pelo que li, a Redirect Hostresposta tem algo a ver com o fato de os dois hosts estarem na mesma rede e de haver uma rota mais curta (ou pelo que entendi). Eles estão de fato na mesma rede física, mas por que haveria uma rota melhor se eles não estiverem na mesma sub-rede (eles não podem se ver)?

o que estou perdendo?

Algumas informações extras que você pode querer 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
fonte

Respostas:

22

À primeira vista, parece que o Debian está estendendo os limites para o envio de um redirecionamento ICMP; citando a 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.

Nesse caso, G1 é 10.1.2.1( eth1:0acima), X é 10.1.1.0/24e G2 é 10.1.1.12e a fonte é 10.1.2.20(ou seja G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Talvez isso tenha sido historicamente interpretado de maneira diferente no caso de aliases de interface (ou endereços secundários) na mesma interface, mas, estritamente falando, não tenho certeza se devemos ver o Debian enviar esse redirecionamento.

Dependendo de suas necessidades, você pode ser capaz de resolver isto fazendo a sub-rede para eth1algo como 10.1.0.0/22(endereços de host de 10.1.0.1- 10.1.3.254) em vez de usar aliases de interface para individuais /24blocos ( eth1, eth1:0, eth1:1, eth1:2); se você fez isso, precisará alterar a máscara de rede de todos os hosts conectados e não poderá usar o 10.1.4.x a menos que tenha expandido para a /21.

EDITAR

Estamos nos aventurando um pouco fora do escopo da pergunta original, mas ajudarei a resolver os problemas de design / segurança mencionados em seu comentário.

Se você deseja isolar os usuários em seu escritório, vamos voltar um pouco e analisar alguns problemas de segurança com o que você tem agora:

Atualmente, você tem quatro sub-redes em um domínio de transmissão Ethernet. Se todos os usuários de um domínio de broadcast não atender aos requisitos de segurança que você articulados nos comentários (todas as máquinas verá transmissões de outras máquinas e poderia espontaneamente enviar tráfego para o outro em Layer2, independentemente do seu ser gateway padrão eth1, eth1:0, eth1:1ou eth1:2). Não há nada o seu firewall Debian pode fazer para mudar isso (ou talvez eu deveria dizer não há nada o seu firewall Debian deve fazer para mudar isso :-).

  • Você precisa atribuir usuários ao Vlans, com base na política de segurança declarada nos comentários. Uma Vlan configurada corretamente percorrerá um longo caminho para corrigir os problemas mencionados acima. Se o seu switch ethernet não suporta Vlans, você deve obter um que suporte.
  • Com relação a vários domínios de segurança acessando 10.1.1.12, você tem algumas opções:
    • Opção 1 : Dado o requisito de todos os usuários acessarem serviços 10.1.1.12, você pode colocar todos os usuários em uma sub-rede IP e implementar políticas de segurança com Private Vlans (RFC 5517) , supondo que seu switch ethernet suporte isso. Essa opção não exigirá iptablesregras para limitar o tráfego intra-escritório de ultrapassar os limites de segurança (isso é feito com Vlans particulares).
    • Opção 2 : você pode colocar os usuários em diferentes sub-redes (correspondentes ao Vlans) e implementar iptablesregras para implantar suas políticas de segurança
  • Depois de proteger sua rede no nível da Vlan, configure políticas de roteamento baseadas na fonte para enviar a diferentes usuários seus múltiplos uplinks.

Para sua informação, se você possui um roteador que suporta VRFs , parte disso fica ainda mais fácil; IIRC, você possui uma máquina Cisco IOS no local. Dependendo do modelo e da imagem do software que você já possui, a Cisco pode fazer um trabalho fantástico isolando seus usuários um do outro e implementar políticas de roteamento baseadas na origem.

Mike Pennington
fonte
Basicamente, o que eu preciso é ter 4 sub-redes para diferentes áreas de um escritório. Algumas sub-redes vão para a Internet usando um ISP e outras usam outro. Máquinas de sub-redes diferentes não devem poder ver ou se conectar. EXCETO para o host 10.1.1.12, que oferece alguns serviços que devem estar disponíveis para todos. Atualmente, não configurei as regras FORWARD apropriadas para isso. No entanto, como todos os encaminhamentos são aceitos, pensei que deveria poder executar o ping de 10.1.2.20 a 10.1.1.12.
El Barto
Hmm ... ok, obrigado Mike. Vou examinar as VLANs mais profundamente. Eu tinha pensado nisso antes de começar tudo isso, e pensei que não precisaria disso. Os comutadores que temos suportam VLANs, embora sejam comutadores não gerenciados, portanto, se não estiver errado, acho que terei que fazer a marcação no roteador Debian, certo? O isolamento de sub-redes, na verdade, não é um problema crítico neste escritório, mas acho que seria bom ter isso se não exigir muito trabalho extra. Eu vou olhar para ele e ver o que posso fazer :)
El Barto
@ElBarto, se seus switches não suportam a marcação Vlan (e é improvável que não sejam gerenciados), apenas a marcação no Debian não ajudaria. Se o isolamento de sub-rede dentro do escritório não for um problema crítico, coloque todos em duas sub-redes diferentes e facilite as coisas (duas sub-redes garantem que você possa rotear políticas no Debian). Eu diria que o esquema atual com quatro aliases de interface Debian não oferece isolamento real de sub-rede e adiciona muito mais complicação.
Mike Pennington
É isso mesmo, pelo que entendi no manual do usuário, os switches suportam "manter a etiqueta", mas não "fazer a marcação real". Obrigado pelo esclarecimento sobre o Debian. O fato é que, mesmo que eu mantenha duas sub-redes, ainda precisarei de máquinas da sub-rede 10.1.2.0/24 para acessar a 10.1.1.12.
El Barto 25/06
As máquinas em uma sub-rede diferente ainda devem poder acessar 10.1.1.12. Se você impedir que o linux envie ICMP inacessível iptables, você ainda queima a CPU enviando as mensagens ICMP, mas pelo menos elas não serão instaladas nas tabelas de host. Dito isto, se você adicionar outra interface Ethernet no Debian (ou seja, dedicar uma interface por usuário 'classe'), o Debian não deverá mais enviar ICMP inacessíveis; isso implica que você tem dois comutadores Ethernet diferentes: um para cada 'classe' de usuário. Seus técnicos de cabeamento não gostariam, mas ele faz o trabalho #
Mike Pennington
3

Não está realmente claro o que você está tentando fazer, mas posso dizer o seguinte.

Essas sub-redes estão conectadas à mesma interface física. O roteador Linux retornará uma mensagem de redirecionamento ICMP quando o pacote recebido deve ser encaminhado pela mesma interface física.

Khaled
fonte
Preciso lidar com essas 4 sub-redes, todas conectadas através da mesma NIC. A idéia é que os hosts das diferentes sub-redes não possam se conectar, exceto o host 10.1.1.12, que deve estar disponível para todos. Ainda não defini as regras de encaminhamento para isso, então pensei que qualquer host de qualquer uma dessas sub-redes deveria ser capaz de atingir 10.1.1.12. Existe alguma maneira de evitar o redirecionamento do ICMP?
El Barto
1
@ElBarto, um método é adicionar uma iptablesregra que cai redirecionamentos saireth1
Mike Pennington
1

Concordo com os comentários de Khaled e também acrescentaria ao final de sua frase:

"Essas sub-redes estão conectadas à mesma interface física. O roteador Linux retornará a mensagem de redirecionamento ICMP quando o pacote recebido for encaminhado pela mesma interface física" para a mesma sub - rede de destino e, em seguida, redirecionará a solicitação para o próximo salto. Isso aconteceu comigo hoje usando um roteador Mikrotik linux e um 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
user352048
fonte