Как долго наблюдается (принятое) перенаправление ICMP и как можно сократить это время?

Question

Если хост Linux получает и принимает перенаправление ICMP ( accept_redirects=1на рассматриваемом интерфейсе), как долго этот маршрут кэшируется и наблюдается? Можно ли уменьшить это время?

Я спрашиваю, потому что у меня есть несколько систем, зараженных фиктивным маршрутом, который, скорее всего, возникает из-за неудачного перенаправления 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>

и они простоне забывая о перенаправлении, даже если прошло более 12 часов с момента получения последнего перенаправления ICMP! Мне придется вручную ip route flush cacheудалить запись и восстановить правильный маршрут:

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

Я знаю, как и почему перенаправление ICMP было отправлено, получено и принято в первую очередь, вопрос не об этом.

---

Я думаю, это не имеет отношения к вопросу, но вот некоторые подробности:

У нас есть внутренняя сеть, скажем, 10.1.0.0/16. Одна из машин 10.1.1.1 — это сервер OpenVPN с удаленными клиентами, получающими адреса в пределах 10.2.0.0/16. Другие внутренние машины имеют статический маршрут 10.0.0.0/8 --> 10.1.1.1. Он намеренно шире 10.2.0.0/16, поскольку в будущем сервер VPN может обслуживать больше клиентов.

К сожалению, наше управление конфигурациями также проталкивает более широкий статический маршрут 10/8-->10.1.1.1 на сам VPN-сервер, где он устанавливается как 10/8-->eth0. Этот ненужный маршрут обычно не имеет никакого эффекта.

В нормальных условиях эта установка работает просто отлично. Но потом случилось следующее:

• VPN-сервер 10.1.1.1 перезагружается
• Какой-то другой внутренний хост (например, 10.1.1.2) пытается связаться с VPN-клиентом (например, 10.2.2.2) как раз в тот момент, когда VPN-сервер уже запустил свой стек IP-адресов, но до того, как OpenVPN будет запущен, поэтому маршруты к 10.2.0.0/16 еще не установлены.
• VPN-сервер имеет send_redirects=1внутренний интерфейс eth0, и из-за неудачного маршрута 10/8->eth0 он отправляет соответствующее перенаправление ICMP обратно на 10.1.1.2
• 10.1.1.2 имеет accept_redirects=1свой внутренний интерфейс и кэширует маршрут, объявленный в перенаправлении ICMP, и отчаянно рассылает ARP-запросы для 10.2.2.2 во внутреннюю сеть:

Вскоре после этого VPN-сервер устанавливает свои VPN-маршруты и прекращает отправку перенаправлений, а все остальные VPN-подключения работают нормально.

Пока все хорошо. Я думаю, что понимаю, что произошло и почему, и я знаю различные способы исправления в краткосрочной перспективе ( ip route flush cacheна внутреннем хосте) и в долгосрочной перспективе (конечно, избавиться от более широкого маршрута на VPN-сервере; но также мы могли бы установить accept_redirects=0на внутренних хостах; или установить send_redirects=0на VPN-сервере), так что этонетмой вопрос.

---

Примечания:

• Ядро Ubuntu 3.13.0-141
• Ubuntu kernel 4.4.0-116, похоже, ведет себя по-другому: он также принимает перенаправление ICMP (if accept_redirects=1), поскольку он также начинает отправлять локальные запросы ARP для назначения. Но по крайней мере до тех пор, пока они остаются без ответа, он продолжает отправлять IP-пакеты на исходный следующий переход и ip route get 10.2.2.2по-прежнему показывает исходный, неперенаправленный следующий переход.
• В соответствии сhttps://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux, net.ipv4.route.gc_intervalвозможно, регулировал это до 2.6.38 (2011), но не с тех пор.

Answer 1

Перенаправления ICMP кэшируются на время, указанное gc_timeout ( /proc/sys/net/ipv4/gc_timeout). Однако следует отметить, что отсчет времени начинается с последнего действия, поэтому в некоторых ситуациях сбой может продолжаться вечно.

Я не уверен, что во всех дистрибутивах Ubuntu есть такая функция.