http://mikrotik.moscow Новое в теме 2.8.22 СЛИПКИ НАТ! форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sun, 02 Aug 2026 14:26:43 -0400 2.8.22 СЛИПКИ НАТ! RouterOS в форуме RouterOS.
Мы обновили руководство по маршрутизации: обратите внимание, что если у вас больше одной публичной интерфейсной карты и более одного адреса на любой из них, то policy-routing и маршрутизация с многопутевым равномерным стоимостным маршрутом могут работать некорректно при использовании маскирования. Чтобы избежать этой проблемы, используйте action=nat вместо action=masquerade. Не могли бы вы прислать нам файл с результатами работы поддержки с вашего роутера?
04.01.2005 12:12:00, uldis.]]> http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220641 http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220641 Tue, 04 Jan 2005 12:12:00 -0500 RouterOS 2.8.22 СЛИПКИ НАТ! RouterOS в форуме RouterOS.
Спасибо, я уже думал, что схожу с ума. Я тоже откатился (вернулся к версии) 2.8.19, и теперь все работает отлично.
04.01.2005 03:54:00, workshop.]]> http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220640 http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220640 Tue, 04 Jan 2005 03:54:00 -0500 RouterOS 2.8.22 СЛИПКИ НАТ! RouterOS в форуме RouterOS.
У нас точно такая же проблема: когда система переключилась на резервный канал с использованием двух сетевых подключений после обновления до версии 2.8.22, все пришлось откатить обратно на 2.8.16.

Lee
04.01.2005 02:42:00, lquince.]]> http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220639 http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220639 Tue, 04 Jan 2005 02:42:00 -0500 RouterOS 2.8.22 СЛИПКИ НАТ! RouterOS в форуме RouterOS.
Ну вот это вообще странно. У нас 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 в настоящее время находится в автономном режиме, чтобы это не способствовало проблеме. Кто-нибудь видел это раньше?
02.01.2005 00:20:00, workshop.]]> http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220638 http://mikrotik.moscow/forum/forum57/58317-2.8.22-slipki-nat/message220638 Sun, 02 Jan 2005 00:20:00 -0500 RouterOS