Bigmazy

Активный участник
  • Публикаций

    198
  • Зарегистрирован

  • Посещение

1 Подписчик

Информация о Bigmazy

  • Звание
    Студент
  • День рождения

Контакты

  • Сайт
    http://www.vasexperts.ru

Информация

  • Пол
    Мужчина

Город

  • Город
    Санкт-Петербург

Посетители профиля

889 просмотров профиля
  1. умеет.
  2. Не нужно, всего скорее перепутана ориентация или профиль с ошибками отработал, обратитесь в ТП.
  3. если списки будут пустые то блокировки не будет, с момента включения блокировка заработает. IMHO, насколько вижу "армагедон" с IP СКАТ не касается, если версия позже 5.5 стоит то все нормально отрабатывает и белые списки (которые ревизор гоняет сейчас) проходят без проблем. Закон не отменят, списки не обнулят.
  4. КЭШ (включая ретреккер) ставится по отдельной лицензии, удаленно. Обратитесь в ТП.
  5. ревизор какой аппаратный (tp-link) ?
  6. списки исключений ведутся в облаке давно (расширяем по мере необходимости), применяются в облаке, на dpi нет необходимости их отправлять.
  7. Хорошо, учтем при разработке
  8. идет разовая переадресация на информационную страницу, для этого DPI должен видеть трафик на веб сервер с этой страницей, в УРЛ передается ссылка на оригинальный запрос клиента, т.е. можно после показа информации вернуться на страницу на которую пользователь переходил.
  9. Проблема наведенная, временно уберите в black_list_redirect в конце ?, что бы исходный урл не добавлялся в параметры переадресации. Потребуется рестарт. Поправим в ближайшей версии.
  10. почему-то он у вас слишком короткий в логе, запишите дамп трафика на клиенте и отправьте SD (support)
  11. проверяйте с помощью трассировки, что трафик идет через dpi см. http://vasexperts.ru/wiki/doku.php?id=filtration_troubleshooting_serv_off с п.3 проверьте состояние байпасс и актуальность скаченного реестра в /var/lib/dpi. Если не разберетесь пишите в SD. DPI работает с фрагментированными пакетами и соответственно большими УРЛами (это уже не первый случай), еще раз повторю, что на тестовой зоне и на контрольных точках у нескольких операторов проблемы описанной не наблюдаю. Все как выше описано работает штатно с переадресацией.
  12. если в отчее ревизора нет его в пропусках, то УРЛ который запрашиваете проверьте внимательно.
  13. это не влияет, недавно подсети в отчете были какие там скиншоты ?. запрос wget это длинный урл на it-grad сети, там боевой стоит 5.6: ... %BF%D0%B5%D1%81%D0%BD%D1%8F%20-%20%D0%A1%D0%BA%D0%B8%D0%BD%D1%8B/mp3.mp3 Resolving ladious.ru... 94.23.4.28 Connecting to ladious.ru|94.23.4.28|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://www.it-grad.ru/blockpage.html [following] --2017-05-26 22:19:16-- http://www.it-grad.ru/blockpage.html Resolving www.it-grad.ru... 2a04:c900:1d00:258::3, 5.200.33.22 Connecting to www.it-grad.ru|2a04:c900:1d00:258::3|:80... connected. HTTP request sent, awaiting response... 200 OK штатно отработала переадресация. далее как придет SD будем в нем смотреть, в конкретном случае.
  14. не наблюдаю такой проблемы проверил на 6.1 и 6.2 в тестовой зоне, другие не смотрел, и у клиентов, отчеты которых смотрим, на 5.6 версии нет этого урл в отчете. Должен пропускать, ничем особенным не отличается от других протоколов
  15. Как узнали какие ревизор IP проверял, в отчете только номера записей вижу ? P.S. после доработки списков, доп. записей в отчете ревизора не появляется, поэтому не понятно зачем на роутере еще что то блочить.