Кому не интересно, можно сразу переходить к блоку «как лечить».
Симптомы:
Итак, ранним осенним утром внезапно отвалились почти все сервисы для одного из филиалов. Симптомы: один пинг проходит и дальше «тишина». Иногда может пролететь еще 1 icmp, но редко. При повторном запуске пинга даже одного пакета уже не пролетает, если не выдержать паузу в несколько минут. Отвалились не все сервисы, но большинство.
Та часть схемы сети, которая нас интересует:
Понятно по схеме, что грешить сразу стали на красный ящик WatchGuard Firebox, но на нём явно никаких блокировок в логах не обнаружено. Поэтому коллега пока пускал трафик до самых важных сервисов в обход, а я ставила WireShark на то, что не столь нужно вот-прям-щас.
Что происходит:
Итак, что показал WireShark:
А показал он нам, что после первой же пары request/reply нам прилетело от Watchguard сообщение ICMP redirect (type 5; code 1), в котором сказано примерно следующее «братюнь, да что ты мне своими реквестами отвечаешь, я тут посмотрел – у меня есть более крутой маршрут для этого хоста – шли всё на шлюз 10.77.10.254».
Вот тут и дошло до меня, что ICMP – это не только пинги, но и «Internet Control Message Protocol». Из вики: «ICMP-сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя». Далее, собственно, request по-прежнему приходит с WatchGuard, а reply уходит на D-Link. При этом, на сервере есть статический маршрут в сеть 10.97.0.0/16 (через 10.77.10.3), а системе строго срать на этот маршрут! Всё потому, что на самом деле при получении сообщения redirect, маршрут на хост (то есть более специфический) добавляется в таблицу маршрутизации на 10 минут. Но route print его не показывает. И не нужно гнать на винду: во всех debian были всё те же симптомы.
Почему это происходит:
Беда Особенность Watchguard, как и микротиков, что Site-to-Site IPSec не является интерфейсом, не участвует в таблице маршрутизации, и, соответственно, маршруты на сеть за поднятым туннелем вы в ней не увидите. На нашем ватче был маршрут 10.0.0.0/8 на 10.77.10.254, так как за D-Link находятся все остальные филиалы (агрегированные по /16 каждый), чтоб не писать маршрут на каждый филиал (их 50, а динамической маршрутизации нет). Из-за особенностей Watchguard получилось так, что на 10.97.0.0/16 маршрута он не видел. Раньше, кстати, всё было ок до последнего обновления прошивки.
Почему некоторые сервисы и все компы были доступны: на них стоял касперский с сетевым модулем, который отбрасывал эти сообщения как небезопасные.
Что было сделано и не помогло:
Попробовали задрать метрику на маршруте 10.0.0.0/8 на WatchGuard – не помогло. Попробовала сделать правило фильтрации по типу ICMP и блочить эти сообщения – не помогло, через это правило трафик с сообщением редиректа не проходил.
Ну и были перечитаны кучи мануалов по отключению редиректа на WatchGuard – ничего рабочего не нашлось.
Как лечить в итоге:
На линухе лечится тремя командами (2 чтоб прям вот сейчас, одна, чтоб прям вообще).
Запрет приёма редиректа:
/sbin/sysctl -w net.ipv4.conf.eth0.accept_redirects=0
Запрет отправки редиректа:
/sbin/sysctl -w net.ipv4.conf.eth0.send_redirects=0
И чтоб вообще:
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
Ну и может networking рестартануть, делала машинально.
При этом редиректы продолжают падать, но эффекта не оказывают:
На винде правится параметрами реестра, но эффекта до перезагрузки не оказывает (даже если выключить-включить сетевой интерфейс). Параметр в ветке
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
называется EnableICMPRedirect и выставляется в 0. По некоторым советам гугла (про Windows 2000 простихосподи), добавляла еще EnableICMPRedirects (во множественном числе). НО! После ребута сообщения redirect на машинах с исправленном параметром вообще не регистрируются WIreShark’ом, что меня несколько смутило (а вдруг вернутся?). Ну и ребутать over 100 серваков – такая себе идея.
Так что в итоге убрала маршрут 10.0.0.0/8 и добавила вместо него два:
10.0.0.0/10 и 10.64.0.0/11 – получились все сети от 10.0 до 10.95 включительно, а 97-ая, как видите, не вошла, что нас в принципе устроило. Проблема ушла.
То, что обычно пишут в начале поста:
Предыдущий мой пост на ИТ тематику был более 2 лет назад.
Чуть раньше этого я познакомилась на пикабу с классным чуваком, а полтора года назад мы поженились. Сисадмин и программист – норм сочетание оказалось =)
Я попробовала писать на хабр (мне даже одобрили аккаунт за тот пост), но мне не понравилось – на пикабушечке и аудитория поживее и можно не так цензурить текст.
А ещё наш офис вместе с серверной, которая уже стала мини-ЦОД для компании два раза за два года переехал. Если кому интересно – напишите в комментах, могу сделать пост о том, как происходит такой переезд, что мы планируем на каких этапах и т.д. На идеал не претендуем, происходит та ещё трешанина, но рассказать могу.