¿Durante cuánto tiempo se observa una redirección ICMP (aceptada) y cómo puedo acortar ese tiempo?

Question

Si un host Linux recibe y acepta una redirección ICMP ( accept_redirects=1en la interfaz en cuestión), ¿durante cuánto tiempo se almacena en caché y se observa esta ruta? ¿Puedo bajar ese tiempo?

Lo pregunto porque tengo varios sistemas que están envenenados con una ruta falsa que muy probablemente se debe a una redirección ICMP desafortunada:

$ 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>

y son simplementesin olvidar la redirección, incluso >12 h después de recibir la última redirección ICMP! Tengo que hacerlo manualmente ip route flush cachepara eliminar la entrada y restablecer la ruta correcta:

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

Sé cómo y por qué se envió, recibió y aceptó la redirección ICMP en primer lugar, esta pregunta no se trata de eso.

---

Creo que no es relevante para la pregunta, pero aquí hay algunos detalles:

Tenemos una red interna, digamos 10.1.0.0/16. Una de las máquinas 10.1.1.1 es un servidor OpenVPN con clientes remotos a los que se les asignan direcciones dentro de 10.2.0.0/16. Las otras máquinas internas tienen una ruta estática 10.0.0.0/8 --> 10.1.1.1. Es deliberadamente más ancho que 10.2.0.0/16 porque el servidor VPN podría atender a más clientes en el futuro.

Desafortunadamente, nuestra administración de configuración empuja la ruta estática más amplia 10/8-->10.1.1.1 también al servidor VPN, donde se establece como 10/8-->eth0. Esta ruta innecesaria normalmente no tiene ningún efecto.

En condiciones normales, esta configuración funciona bien. Pero entonces sucedió esto:

• El servidor VPN 10.1.1.1 se reinicia
• Algún otro host interno (digamos 10.1.1.2) intenta contactar a un cliente VPN (digamos 10.2.2.2) justo cuando el servidor VPN tiene su pila de IP activa, pero antes de que OpenVPN esté activo, por lo que las rutas a 10.2.0.0/16 no están activas. aún establecido
• El servidor VPN tiene send_redirects=1en su interfaz interna eth0 y, debido a la desafortunada ruta 10/8->eth0, envía una redirección ICMP correspondiente a 10.1.1.2.
• 10.1.1.2 tiene accept_redirects=1en su interfaz interna y almacena en caché la ruta anunciada en la redirección ICMP y envía desesperadamente solicitudes ARP para 10.2.2.2 a la red interna:

Poco después, el servidor VPN establece sus rutas VPN y deja de enviar redireccionamientos, y todas las demás conexiones VPN funcionan bien.

Hasta ahora, todo bien. Creo que entiendo lo que ha sucedido y por qué, y conozco varias formas de solucionarlo a corto plazo ( ip route flush cacheen el host interno) y a largo plazo (por supuesto, deshacernos de la ruta más amplia en el servidor VPN; pero también podemos configurarla accept_redirects=0en los hosts internos). ; o configurar send_redirects=0en el servidor VPN), así esnomi pregunta.

---

Notas:

• Núcleo de Ubuntu 3.13.0-141
• El kernel de Ubuntu 4.4.0-116 parece comportarse de manera diferente: también acepta la redirección ICMP (if accept_redirects=1) en la medida en que también comienza a enviar solicitudes ARP locales para el destino. Pero al menos mientras no reciban respuesta, seguirá enviando los paquetes IP al siguiente salto original y ip route get 10.2.2.2seguirá mostrando el siguiente salto original no redirigido.
• De acuerdo ahttps://vincent.bernat.im/es/blog/2011-ipv4-route-cache-linux, net.ipv4.route.gc_intervalpodría haber gobernado esto antes del 2.6.38 (2011), pero no desde entonces.

Answer 1

Las redirecciones ICMP se almacenan en caché durante el tiempo especificado por gc_timeout ( /proc/sys/net/ipv4/gc_timeout). Sin embargo, tenga en cuenta que el tiempo de espera comienza a partir de la última actividad, por lo que en algunas situaciones la falla puede continuar para siempre.

No estoy seguro de si todas las distribuciones de Ubuntu tienen esta funcionalidad.