+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Удаление подключения брандмауэра, похоже, снова сломалось в версиях v3.15 и v3.16.

Удаление подключения брандмауэра, похоже, снова сломалось в версиях v3.15 и v3.16., RouterOS

dsdee

Guest

04.11.2008 11:58:00

В WinBox и через командную строку я больше не могу удалить активные подключения, получая ошибку: MikroTik> /ip firewall connection MikroTik> print (вывод сокращен) MikroTik> remove 120,121 действие не выполнено (6) то же самое всплывающее окно появляется, когда я пытаюсь удалить соединение в WinBox. Например: Не удалось удалить соединение <192.168.200.8:3897 -> 64.12.x.x.5190> - действие не выполнено (6) Это на новом RB493 с установленной версией 3.15. Кто-нибудь сталкивался с аналогичными проблемами? Мои скрипты, которые нормально работали в 3.13, теперь сломаны. Спасибо,

dsdee

Guest

05.12.2008 15:26:00

Я вижу, что сегодня вышла версия 3.17. Если кто-то уже обновился до 3.17, можете ли вы подтвердить, работает ли команда “/ip firewall connection remove ###” или нет? (или эквивалентная команда в Winbox – вкладка Firewall/Connection, затем щелкните правой кнопкой и удалите подключение) ?? Заранее спасибо, Дэвид

dsdee Guest	#3 0 14.01.2009 14:47:00 Я вижу, что вышла версия 3.18, но я не могу обновиться как минимум еще на неделю. Может кто-то, кто обновил RB493 до 3.18, подтвердить, исправлена ли проблема с “/ip firewall connection remove ###”, или нет? Спасибо.

normis Guest	#4 0 15.01.2009 10:12:00 Это тоже не работает, я проверю статус ошибки.

dsdee

Guest

15.01.2009 19:07:00

Превосходно. В ответ на мой третий запрос (3.15, 3.16, 3.17) в техподдержку Mikrotik в начале декабря они сказали: Здравствуйте, В настоящее время удаление подключения не работает на платформах с порядком байтов big-endian, таких как серии RB400 и RB333, RB600 и RB1000. Этот фикс будет доступен в следующем релизе RouterOS. С уважением, Марис. Я думал, что они могли бы исправить это за месяц...

macgaiver

Guest

20.01.2009 10:37:00

С моей точки зрения, это исправление настолько незначительное, что на самом деле не имеет значения. Если мой conntrack становится слишком полным, я просто уменьшаю значения таймаута для проблемных записей. И я все еще не понимаю, зачем нужно удалять одно единственное соединение. Пока у вас есть место для новых записей, не имеет значения, сколько записей там есть. А в случае, если отслеживание соединений заполнено, все можно решить уменьшением таймаута, но это очень редкая ситуация.

macgaiver

Guest

20.01.2009 10:48:00

Кстати, удаляя записи соединений в conntrack, вы не остановите поток пакетов. Единственное, что произойдёт, это то, что вместо состояния соединения = установленное, отслеживание соединений будет распознавать дальнейшие TCP-пакеты как состояние соединения = недействительное. Для всех других IP-протоколов следующий пакет воссоздаст удалённую запись обратно. Так что снова, эта функция бессмысленна. MT вообще должен избавиться от этой команды/кнопки.

dsdee

Guest

20.01.2009 12:07:00

Новые подключения действительно будут созданы по мере необходимости. Что мне нужно, так это чтобы некоторые долгосрочные соединения завершились немедленно, чтобы их можно было перенаправить. У меня есть два интернет-соединения от разных провайдеров, и когда одно из них выходит из строя или перестает отвечать, мне нужно, чтобы ориентированный на соединение трафик, который идет по неработающему каналу, перенаправлялся на резервную сеть. Неважно, считаете ли вы, что это мне нужно или нет, это функция, которая встроена в ОС, но не работает… Команды есть, кнопки в winbox тоже есть, и это явно сломано, и нужно исправить. Я попробую снова с 3.19 в эти выходные, когда вернусь в город, и надеюсь, что это исправили…

macgaiver

Guest

20.01.2009 12:28:00

Да, точно такой же сценарий - я использую netwatch и скрипт, который отключает и включает (если по-простому - перезапускает) отслеживание соединений, как только шлюз отключается (или включается). Это нужно только в случае, если вы используете NAT.

dsdee

Guest

#10

20.01.2009 13:10:00

Ок, у меня есть (скорее всего, похожие) скрипты, которые следят за интерфейсом, следующим шлюзом и состоянием обновления DHCP, чтобы принять решение о том, когда переключаться или нет. Но для меня невозможно перезапустить всю отслеживаемую связь, потому что не все соединения, проходящие через маршрутизатор, идут через сейчас "недоступный" интерфейс — у меня есть соединения, которые проходят через маршрутизатор внутренне от одной VLAN или сети к другой, и у меня есть соединения, которые проходят через маршрутизатор к другому внешнему интерфейсу (к тому, на который я собираюсь переключаться). Если я остановлю/запущу отслеживание соединений, то все данные отслеживания соединений будут потеряны, и любые установленные соединения через неотказавший интерфейс перестанут работать. Они "удерживаются" правилами "разрешить установленные соединения", но если все данные в таблице отслеживания соединений будут утеряны из-за перезапуска отслеживателя соединений, то все эти пакеты станут "новыми соединениями" и не обязательно будут иметь предварительные условия для восстановления. Самый простой пример — это TCP-соединение, отмеченное как "установленное" — в таком случае установлен только бит ACK, очевидно. Если я очищу соединение, и пакет приходит только с установленным битом ACK, и он еще не "установлен", то он будет считаться недопустимым пакетом, потому что это соединение "новое" и не имеет установленного SYN (а также ACK). Проще говоря, нужно, чтобы '/ip firewall connection remove' работал...

macgaiver

Guest

#11

20.01.2009 13:35:00

Извини, но я думаю, что здесь произошло недоразумение: твоя настройка будет работать даже без отслеживания соединений. Отключив отслеживание соединений, ты просто отключаешь IP-файервол (nat, mangle, filter) и очереди. Это те функции, для которых используется отслеживание соединений. Поэтому, если твой файервол не имеет отношения к конкретному трафику, он все равно пройдет через роутер.

dsdee

Guest

#12

20.01.2009 13:49:00

Нет, у меня нет недопонимания. У меня есть два натированных соединения для моих внешних коммуникаций. Если я отключу отслеживание соединений, то соединение, которое "все еще" работает, больше не будет "работать", и я потеряю все эти работающие соединения... а также "нерабочие" соединения через интерфейс, которые больше не могут передавать трафик. Когда мне нужно очистить соединения, мне нужно очищать соединения только через один интерфейс.

changeip

Guest

#13

20.01.2009 19:21:00

Я согласен, проблему с удалением нужно исправить. Иногда соединение нужно удалить, потому что оно идет через неправильные шлюзы с неправильным IP. Я сам не раз это наблюдал, когда менял шлюзы. Вам нужно написать в поддержку Mikrotik по этому вопросу, никто здесь не сможет это исправить

Однако хорошо, что у нас есть эта тема, чтобы знать, когда это будет исправлено.

normis Guest	#14 0 21.01.2009 08:59:00 уже открыта заявка на исправление этой проблемы. кстати, убери [find] works

NetworkPro

Guest

#15

22.01.2009 13:06:00

Мне кажется, что MikroTik может решить все наши проблемы, улучшив балансировку нагрузки и поддержку резервирования в RouterOS. Судя по тому, что я наблюдал последние 5 лет, я начинаю думать, что MikroTik Латвия нужно нанимать больше людей, так как работы слишком много. P.S. Так что все говорят: http://wiki.mikrotik.com/wiki/Two_gateways_failover_with_load_balancing — это совершенно непригодно, поскольку у нас есть все виды проблем, которые некоторые решают скриптами, а другие пытаются решить неработающими функциями… ОК, не вся надежда потеряна, если хотя бы пример в Вики будет исправлен так, чтобы проблем больше не было.

macgaiver

Guest

#16

22.01.2009 14:59:00

Кому: NetworkPro Не знаю, почему есть такие примеры (да, все 3 примера), но это полная чепуха. Вам нужна одна строка кода, чтобы все работало: add dst-address=0.0.0.0/0 gateway=10.111.0.1,10.112.0.1 check-gateway=ping Это маршрут ECMP - это балансировка нагрузки по парам адресов (а не по подключениям). Так что если вы подключаетесь с address1 к address2 и это идет через GW1, то все остальные коммуникации с address1 к address2 будут использовать тот же шлюз. nth можно использовать для достижения балансировки нагрузки по пакетам, а не по подключению. MikroTik, пожалуйста, УДАЛИТЕ эти примеры в вики - они бесполезны!

dsdee Guest	#17 0 22.01.2009 15:14:00 macagiver, ваш пример не сработает в случаях, когда есть два разных провайдера с двумя разными адресными пространствами, и адаптации из вики будут работать. С двумя разными провайдерами вы не можете маршрутизировать пакеты с адресами источников интерфейса одного провайдера через сеть другого провайдера (и наоборот), поэтому вам нужно будет быть более конкретным в маршрутизации исходящих пакетов. Вам также нужно будет учитывать пакеты, которые приходят на один интерфейс (провайдер) и затем возвращаются через тот же интерфейс для ответных пакетов; ваш пример тоже не учитывает этот случай. Хотя каждый из различных примеров Mikrotik может не охватывать все конкретные случаи, они дают пользователям идеи о том, что может быть адаптировано к их сети для решения их индивидуальных проблем.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры