Ну вот это вообще странно. У нас 2 основных правила NAT на границе MT:
MT:- Весь трафик частных IP, покидающий внешний интерфейс ISP-1 → Маскировать
Весь трафик, покидающий внешний интерфейс ISP-2 → Маскировать
Эти правила не менялись с тех пор, как мы начали использовать MT около 2 лет назад. Недавно обновился до версии 2.8.22, никаких изменений или дополнений к правилам брандмауэра не вносил, просто обновил. Все поднялось, проблем нет, всё выглядит хорошо. Проверил нашу систему мониторинга (DeepMetrix IPMONITOR), которая в основном пингует каждого клиента раз в 60 секунд, чтобы видеть, кто онлайн, а кто нет. IPMONITOR сходит с ума, показывает несколько сотен онлайн и несколько сотен офлайн, по сравнению с обычными 15 офлайн (эти 15 – просто клиенты, которые отключают подключения, когда уезжают в отпуск…). Включается паника, пот льется рекой, пока я не позвоню нескольким известным клиентам, которых IPMONITOR сообщает как “офлайн”. "У нас все в порядке, наши каналы данных работают нормально" - Фух, все хорошо.
Но почему IPMONITOR показывает столько мусора? После запуска ethereal на каждом сегменте нашей сети мы увидели несколько интересных результатов:
Оказывается, MT бокс, который обновился (выше), периодически NAT'ит на не тех интерфейсах!!! IPMONITOR использует только ВНУТРЕННИЙ интерфейс для мониторинга клиентских каналов, и там нет правил NAT! Маскироваться должна только трафик, который должен покидать ВНЕШНИЕ интерфейсы. Проблема в том, что большая часть трафика IPMONITOR (IP 10.33.12.43), который выходит из ВНУТРЕННЕГО интерфейса, выходит из внутреннего интерфейса с NAT-адресом из ВНЕШНЕГО интерфейса номер 1, а иногда переключается на IP из внешнего интерфейса номер 2!!! (Это происходит не постоянно, примерно пополам, но всё должно выходить из внутреннего интерфейса с реальным адресом источника 10.33.12.43, а не с публичным NAT IP номером 1 или номером 2!).
Мы не видим это "Sticky Nat" нигде больше, только трафик IPmonitor затронут. Я предполагаю, что это потому, что он устанавливает примерно 700 ICMP-соединений одновременно, и 2.8.22 просто немного сбивается с толку?!
Я даже попытался добавить явное правило "НЕ МАСКИРОВАТЬ" (Accept) в начале цепочки SRC NAT для трафика IPmonitor (10.33.12.43 -> Accept). И это не помогло.
Пожалуйста, помогите! Откат невозможен в данный момент из-за SLA-соглашений. У нас есть отказоустойчивость VRRP, но я не готов рисковать. Вторичный MT VRRP в настоящее время находится в автономном режиме, чтобы это не способствовало проблеме. Кто-нибудь видел это раньше?
MT:- Весь трафик частных IP, покидающий внешний интерфейс ISP-1 → Маскировать
Весь трафик, покидающий внешний интерфейс ISP-2 → Маскировать
Эти правила не менялись с тех пор, как мы начали использовать MT около 2 лет назад. Недавно обновился до версии 2.8.22, никаких изменений или дополнений к правилам брандмауэра не вносил, просто обновил. Все поднялось, проблем нет, всё выглядит хорошо. Проверил нашу систему мониторинга (DeepMetrix IPMONITOR), которая в основном пингует каждого клиента раз в 60 секунд, чтобы видеть, кто онлайн, а кто нет. IPMONITOR сходит с ума, показывает несколько сотен онлайн и несколько сотен офлайн, по сравнению с обычными 15 офлайн (эти 15 – просто клиенты, которые отключают подключения, когда уезжают в отпуск…). Включается паника, пот льется рекой, пока я не позвоню нескольким известным клиентам, которых IPMONITOR сообщает как “офлайн”. "У нас все в порядке, наши каналы данных работают нормально" - Фух, все хорошо.
Но почему IPMONITOR показывает столько мусора? После запуска ethereal на каждом сегменте нашей сети мы увидели несколько интересных результатов:
Оказывается, MT бокс, который обновился (выше), периодически NAT'ит на не тех интерфейсах!!! IPMONITOR использует только ВНУТРЕННИЙ интерфейс для мониторинга клиентских каналов, и там нет правил NAT! Маскироваться должна только трафик, который должен покидать ВНЕШНИЕ интерфейсы. Проблема в том, что большая часть трафика IPMONITOR (IP 10.33.12.43), который выходит из ВНУТРЕННЕГО интерфейса, выходит из внутреннего интерфейса с NAT-адресом из ВНЕШНЕГО интерфейса номер 1, а иногда переключается на IP из внешнего интерфейса номер 2!!! (Это происходит не постоянно, примерно пополам, но всё должно выходить из внутреннего интерфейса с реальным адресом источника 10.33.12.43, а не с публичным NAT IP номером 1 или номером 2!).
Мы не видим это "Sticky Nat" нигде больше, только трафик IPmonitor затронут. Я предполагаю, что это потому, что он устанавливает примерно 700 ICMP-соединений одновременно, и 2.8.22 просто немного сбивается с толку?!
Я даже попытался добавить явное правило "НЕ МАСКИРОВАТЬ" (Accept) в начале цепочки SRC NAT для трафика IPmonitor (10.33.12.43 -> Accept). И это не помогло.
Пожалуйста, помогите! Откат невозможен в данный момент из-за SLA-соглашений. У нас есть отказоустойчивость VRRP, но я не готов рисковать. Вторичный MT VRRP в настоящее время находится в автономном режиме, чтобы это не способствовало проблеме. Кто-нибудь видел это раньше?
