Por quanto tempo é observado um redirecionamento ICMP (aceito) e como posso reduzir esse tempo?

Question

Se um host Linux receber e aceitar um redirecionamento ICMP ( accept_redirects=1na interface em questão), por quanto tempo essa rota será armazenada em cache e observada? Posso diminuir esse tempo?

Estou perguntando porque tenho vários sistemas envenenados com uma rota falsa que provavelmente decorre de um infeliz redirecionamento ICMP:

$ ip route get 10.2.2.2 10.2.2.2 via 10.2.2.2 dev eth0 src 10.1.1.2 cache <redirected>

e eles são simplesmentenão esquecendo do redirecionamento, mesmo >12h após o recebimento do último redirecionamento ICMP! Tenho que fazer isso manualmente ip route flush cachepara remover a entrada e restabelecer a rota correta:

$ ip route get 10.2.2.2 10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2 cache

Eu sei como e por que o redirecionamento ICMP foi enviado, recebido e aceito em primeiro lugar, esta questão não é sobre isso.

---

Acho que não é relevante para a pergunta, mas aqui estão alguns detalhes:

Temos uma rede interna, digamos 10.1.0.0/16. Uma das máquinas 10.1.1.1 é um servidor OpenVPN com clientes remotos recebendo endereços atribuídos em 10.2.0.0/16. As demais máquinas internas possuem uma rota estática 10.0.0.0/8 --> 10.1.1.1. É deliberadamente mais amplo que 10.2.0.0/16 porque o servidor VPN poderá atender mais clientes no futuro.

Infelizmente, nosso gerenciamento de configuração empurra a rota estática mais ampla 10/8-->10.1.1.1 também para o próprio servidor VPN, onde é estabelecida como 10/8-->eth0. Essa rota desnecessária geralmente não surte efeito.

Em condições normais, esta configuração funciona perfeitamente. Mas então isso aconteceu:

• O servidor VPN 10.1.1.1 é reiniciado
• Algum outro host interno (digamos 10.1.1.2) tenta entrar em contato com um cliente VPN (digamos 10.2.2.2) assim como o servidor VPN tem sua pilha de IP, mas antes do OpenVPN estar ativo, então as rotas para 10.2.0.0/16 não são ainda estabelecido
• O servidor VPN possui send_redirects=1em sua interface interna eth0 e, devido à infeliz rota 10/8->eth0, ele envia um redirecionamento ICMP correspondente de volta para 10.1.1.2
• 10.1.1.2 possui accept_redirects=1em sua interface interna e armazena em cache a rota anunciada no redirecionamento ICMP e envia desesperadamente solicitações ARP para 10.2.2.2 para a rede interna:

Pouco depois, o servidor VPN estabelece suas rotas VPN e para de enviar redirecionamentos, e todas as outras conexões VPN funcionam perfeitamente.

Até agora tudo bem. Acho que entendo o que aconteceu e por quê, e conheço várias maneiras de remediar a curto prazo ( ip route flush cacheno host interno) e a longo prazo (é claro, livrar-se da rota mais ampla no servidor VPN; mas também poderíamos definir accept_redirects=0em hosts internos ; ou definido send_redirects=0no servidor VPN), então é isso.nãominha pergunta.

---

Notas:

• Kernel Ubuntu 3.13.0-141
• O kernel do Ubuntu 4.4.0-116 parece se comportar de maneira diferente: ele também aceita o redirecionamento ICMP (if accept_redirects=1) na medida em que também começa a enviar solicitações ARP locais para o destino. Mas pelo menos enquanto eles não forem respondidos, ele continuará enviando os pacotes IP para o próximo salto original e ip route get 10.2.2.2ainda mostrará o próximo salto original e não redirecionado.
• De acordo comhttps://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux, net.ipv4.route.gc_intervalpoderia ter regido isso antes de 2.6.38 (2011), mas não desde então.

Answer 1

Os redirecionamentos ICMP são armazenados em cache pelo tempo especificado por gc_timeout( /proc/sys/net/ipv4/gc_timeout). Observe, entretanto, que o tempo limite começa na última atividade, portanto, em algumas situações, a falha pode durar para sempre.

Não tenho certeza se todas as distribuições do Ubuntu possuem essa funcionalidade.