Jump to content

Le ecureuil

Forum Members
  • Posts

    9,559
  • Joined

  • Last visited

  • Days Won

    552

Posts posted by Le ecureuil

  1. 1 час назад, dexter сказал:

    Есть у меня удаленный кинетик на котором запущен OVPN клиент. Раньше там snmp был из пакетов и интерфейс tun0 попадал в мониторинг. Теперь используется snmp из прошивки и tun интерфейс в список не попал.

    Возможно ли добавление подобных интерфейсов в мониторинг?

    Если кратко - нет.

  2. 6 часов назад, Roman_Petrov сказал:

    Сейчас 12.08.2016, с обновлением в v2.08(AAUX.1)A3 увидел, что вы пошли дальше и сделали расписание через веб интерфейс по ограничению выхода в интернет. Это большой шаг вперед. Вопрос - а можно ли туда же как то приделать и ограничение скорости, как мы с вами выше обсудили и что уже есть из командной строки, тогда уже по расписанию заодно, было бы вообще замечательно ? Там может тоже можно как выпадающее окошко под шейпером сделать, по типу доступа в интернет. Вот примерно как это могло бы выглядеть:

    Traffic Shaping.jpg

    Еще вопрос, а кроме 2.08 это попадет еще в 2.06, как и IntelliQos ? Хочется это на Ultre тоже...

    Управление шейпером по расписанию из CLI уже попало в 2.06, а вот web - там вообще не я решаю.

  3. Здесь все довольно плохо из-за существования ppe hardware и ppe software, а также fastnat с которых снимать статистику довольно проблематично.

    Можем добавить сам модуль ядра ip-netflow в пакет opkg-kmod-netfilter, при этом вы сами отключите абсолютно все ускорители (подскажем как, но максимальные скорости будут конечно на порядок ниже) и настроите userspace через entware или debian - так вас устроит?

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

  4. 10 часов назад, iskatel' сказал:

    Но, ведь при мониторинге через UPnP график был нормальным.

    Да, и при использовании того же P660HTN EE, который у меня был раннее, графики нормальными были...

    Ну так и используйте P660 или UPnP.

    У нас другая реализация SNMP, скорее всего просто плохо подходящая вам или вашей утилите для сбора статистики. Попробуйте в ней увеличить интервал опроса, а мы пока подумаем над решением вашей проблемы.

  5. Цитата

    Первая проблема (не знаю должно так быть, или нет): при настройках указанных выше, при заходе в WEB-интерфейс роутера наблюдается повышенная загрузка процессора:

    Да, это так и должно быть при непрерывном опросе по snmp.

    Ну и собственно вам автор утилиты все ответил про причину такого графика.

    • Thanks 1
  6. 3 часа назад, iocsha сказал:

    Добрый день, Le ecureuil , netflow  на  2.08 нет ни каких планов ? Понятно , что это не всем надо , но было бы здорово. Разумеется статистику не на роутере собирать. У микротиков это работает на отлично.

    Пока нет, но создайте отдельную тему и подумаем вместе над реализацией.

    • Thanks 1
  7. 1 час назад, Goblin сказал:

    @pachalia, но нужно для этого сначала научить transmission последовательной загрузке. хотя, есть патч. но все равно "смотреть не загружая" я даже не знаю. это, имхо, невозможно. все равно нужно хоть в кэш грузить. да и потом весь принцип p2p теряется. если все будут не загружать, а значит потом не раздавать. а значит раздача мертвая. с кого бум "смотреть не загружая"?

    Наш transmission 2.92 это уже давно умеет (последовательная загрузка), патч для него применен.

  8. 3 часа назад, vasek00 сказал:

    Потерял один интерфейс - имеем провайдер PPTP и подключен клиент по VPN для доступа (как раз этого интерфейса и не видно, ведь он должен же быть как например ppp1), к каждому  LAN порту подключен клиент плюс wi-fi клиенты.

    Съем идет через клиента который подключился к VPN, так же что-то датчиков в данном подключении маловато будет видно в отличие от локального.

    SNMP-rem-3.jpg

    SNMP-rem-1.jpg

    Пока интерфейсы, которые являются концами VPN-подключений у VPN-сервера, никак не обрабатываются в прошивке, потому управлять и снимать с них статистику невозможно.

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

  9. 5 часов назад, Rezdbic сказал:

    Заранее прощу прощения за оффтоп, чтобы не создавать новую тему, спрошу тут.

    Какой VPN безопаснее IPSec VPN или PPTP VPN?

    По скорости работы какой будет быстрее?

    На Ultra II с аппаратным шифрованием IPsec показал 350 Мбит/сек, PPTP же в аналогичных условиях на этой железке - 70..80 Мбит/сек ;)

    • Thanks 2
  10. 4 часа назад, vadimbn сказал:

    IPsec, так как применяется стойкое шифрование (AES), а не MPPE.

     

    В старших кинетиках есть блок аппаратного шифрования, если он работает - то шифрование никак не влияет на процессор, им производится только инкапсуляция/декапсуляция пакетов. Если блока аппаратного шифрования нет - то PPTP будет быстрее.

    В некоторых младших тоже - Start II, Lite III rev B и 4G rev B (устройства на MT7628) тоже умеют аппаратное шифрование AES.

    • Thanks 1
  11. 5 часов назад, iocsha сказал:

    Так и есть , с  PRTG работает. Спасибо всем за совет.

    Куча логов в роутере , это можно как то отключить ?  v2.08(AAUW.1)A2

    Aug 11 13:17:03mini_snmpd
    (linux.c:420) ndm response is invalid
    Aug 11 13:17:48ndm
    Network::Interface::Switch: "GigabitEthernet0/0": unable to fetch port couters overflow info.
    Aug 11 13:17:48ndm
    Network::Interface::Switch: "GigabitEthernet0/0": unable to parse port overflow data.
    Aug 11 13:17:48mini_snmpd
    (linux.c:420) ndm response is invalid
    Aug 11 13:17:53ndm
    Network::Interface::Switch: "GigabitEthernet0/0": unable to fetch port couters overflow info.
    Aug 11 13:17:53ndm
    Network::Interface::Switch: "GigabitEthernet0/0": unable to parse port overflow data.
    Aug 11 13:17:53mini_snmpd
    (linux.c:420) ndm response is invalid
    Aug 11 13:17:58ndm
    Network::Interface::Switch: "GigabitEthernet0/0": unable to fetch port couters overflow info.
    Aug 11 13:17:58ndm
    Network::Interface::Switch: "GigabitEthernet0/0": unable to parse port overflow data.
    Aug 11 13:17:58mini_snmpd
    (linux.c:420) ndm response is invalid

    Спасибо за репорт, баг исправлен, все будет нормально в следующей пятничной сборке.

    • Thanks 1
  12. Используйте команду schedule по описанию: 

    Вам нужно создать schedule со временем, которое вы желаете для работы основного канала (там, где ip global выше), и применить его к этому интерфейсу.

    В таком случае интерфейс с большим приоритетом будет "гаситься" согласно расписанию, и все будет работать по резервному каналу, по приходу времени все опять будет возвращаться на основной канал.

     

    • Thanks 1
  13. 10 часов назад, Phaeton сказал:

    Добрый день! Буквально только что проверил журнал и обнаружил:

    Aug 10 05:12:11keenetic_ultra nginx
    (conn: *49321) user "ZXDSL" was not found in config, client: 89.163.242.91
    Aug 10 05:12:15keenetic_ultra nginx
    (conn: *49322) user "Cisco" was not found in config, client: 89.163.242.91
    Aug 10 05:12:18keenetic_ultra nginx
    (conn: *49323) user "cisco" was not found in config, client: 89.163.242.91
    Aug 10 05:12:21keenetic_ultra nginx
    (conn: *49324) user "admin": password mismatch, client: 89.163.242.91

     

    Aug 10 08:13:49keenetic_ultra nginx
    (conn: *49369) user "airlive" was not found in config, client: 5.141.8.81
    Aug 10 08:13:52keenetic_ultra nginx
    (conn: *49370) user "support" was not found in config, client: 5.141.8.81
    Aug 10 08:13:55keenetic_ultra nginx
    (conn: *49371) user "support" was not found in config, client: 5.141.8.81
    Aug 10 08:13:58keenetic_ultra nginx
    (conn: *49372) user "super" was not found in config, client: 5.141.8.81

    И таких записей около сотни.

    Вас брутфорсят.

    Эти записи мы специально не скрываем, чтобы вы знали о факте перебора паролей и о том, насколько упорно это делается.

    Однако вы сами можете их скрыть через system log suppress nginx или же забанив эти IP в межсетевом экране.

  14. Сейчас на 2.07 и 2.08 такие настройки: 
     - между любыми запросами при ответе HTTP/401 - интервал 300 мс, которые выдерживает nginx и не отдает данные. Это для защиты от тупого refresh страницы с 401 ответом и DоS в результате.
     - если учетные даннные неверны, или такого юзера вообще нет в системе - то задержка перед выдачей HTTP/401 составляет 3000 мс, что достаточно, чтобы защитить от брутфорса, если у вас стоит нормальный пароль. Такими темпами (0,33 в секунду максимум) их будут перебирать дооооолго.

     

    Еще можно попробовать включить ограничение на число коннектов с одного IP на nginx, но тут нужно быть аккуратным, чтобы не зарезать случаем нормальную пользовательскую активность.

    • Thanks 1
  15. В 8/9/2016 в 02:20, curiosity сказал:

    Подскажите, пожалуйста, где может быть ошибка:

    IPsec-тунель поднят между Ultra (v2.06(AAGJ.9)B4) и Giga III (v2.06(AAUW.8)B0) по статье БЗ Zyxel https://zyxel.ru/kb/4857/

    Сервер - Giga III, клиент - Ultra. Единственное отличие от мануала - DES -> 3DES.

    Из соответствующих сетей пингуются "потусторонние" маршрутизаторы, также есть доступ к их Web и CLI, но нет доступа к хостам за ними (адресация сетей не перекрывается, все как по статье БЗ)

    В  какую сторону копать?

    Если сами маршрутизаторы пингуются - значит все отлично и должно работать без всяких дополнительных прописываний маршрутизаций.

    Единственной проблемой может быть то, что на хостах за маршрутизаторами в качестве шлюза по умолчанию не указаны именно эти маршрутизаторы, которые соединены IPsec VPN. Проверьте это.

  16. 2 часа назад, dexter сказал:

    Заходим на кинетик по телнету. Вбиваем "snmp community public", snmp contact, location - это по желанию, можно и не заполнять. Затем "service snmp", и "system configuration save". На кинетике все настройки выполнены. На компе придется Вам самому настраивать. Вопросы будут - пишите, но перед этим гуглим, гуглим, практикуем, гуглим......

    В теории кроме service snmp можно вообще ничего не делать. Community по умолчанию - и так public.

    • Thanks 2
×
×
  • Create New...