[saaremaa]

Ок значит остаемся на FastDPI 5.6 Katyusha (Jan 4 2017)

[snvoronkov]

Ок значит остаемся на FastDPI 5.6 Katyusha (Jan 4 2017)

Да лана. Тоже 5.6.1. Спецом сходил в ЛК посмотреть - тишина. (Тьфу-тьфу.)

[DimaM]

Блокирование не на 100% возможно в следующих случаях:

1) схема с BGP анонсом - понятно почему - IP адреса блокируемых сайтов плавают, резолв + анонс за ними не поспевают,

если адрес не анонсирован, то через dpi трафик не проходит, отсюда пропуск

Эту схему фильтрации давно не рекомендует РКН, а мы тем более

2) схема с зеркалом трафика - потери или задержки в линии (от абонента, до абонента или сайта) иногда таки делают свое дело

3) раньше были пропуски на спутниковых каналах (т.к. там много потерь и ретрансмиссий -> иногда трудно реконструировать запрос),

но давно уже нет

 

Все остальные варианты подпадают под "трафик идет мимо dpi или инкапсулирован в тоннель" выявляются на этапе внедрения, но потом

топология сети зачастую изменяется и они опять вылезают.

 

Какой ваш случай?

[YuryD]

Блокирование не на 100% возможно в следующих случаях:

Какой ваш случай?

 

Мой - простейший. В разрыв. Есть бордер на брокаде, есть два магистрала. Затем весь трафик проходит через скат - левых каналов тут не может быть, ни в одном варианте. Но я отловил у себя заглушку магистрала ТТК, через некоторое время мой скат нарисовал мою заглушку. Прошло около 3-х часов. Скат работал нормально - по загрузке компа и доступности инета. Реестр и я и ттк получили вовремя видимо, раз в час, файлы выгрузок на месте. Ссылку я уже давал, обычный http, вывод только один - пишите сразу парсер для зип-файла ркн в скат, чтобы я его мог из своей выгрузки подсунуть. Ну, не успели, бывает, но облако работать должно, а для чего я скат покупал?

[bike]

Какой ваш случай?

 

Дмитрий, подскажите, а как часто обновляется реестр блокировки в облаке?

Дефолтное время проверки наличия изменения списков, в облаке, 1 час, имеет ли смысл уменьшить его?

[DimaM]

Ну, не успели, бывает, но облако работать должно, а для чего я скат покупал?

 

В логе скат фиксируются обращения к облаку и их результат. Есть что?

 

Дефолтное время проверки наличия изменения списков, в облаке, 1 час, имеет ли смысл уменьшить его?

 

Сейчас обновляется раз в полчаса, чаще смысла нет.

Но может имеет смысл наоборот поставить время побольше :)

РКН утверждает, что проверяются сайты только через сутки после их включения в список,

а вот обратное неверно : если сайт из списка исключается, то ревизор такое не всегда корректно учитывает

и может показать в отчете уже исключенный сайт (программисты в МФИ СОФТ где-то накосячили).

Если поставить слишком частое обновление, то иногда такая глюка вылезает.

Она не критична, так как РКН за такое иски не подает - их просто нельзя выиграть, но это немного напрягает.

 

PS

Очевидно что ревизор содержит ошибки, ПО без багов вообще не бывает :)

Но он же даже не проходил сертификационного тестирования, как тот же СОРМ,

как приборы ГИБДД и т.п. Т.е. нет никаких доказательств того, что он хотя бы в целом корректно работает.

Адвокаты и правоохранители вокруг операторского бизнеса мышей не ловят.

[YuryD]

Я, конечно, старый и слепой. Но вдруг увидел чужую заглушку, вместо своей. Облако не отработало вовремя... Логи приводить уже поздно.

[Bigmazy]

Я, конечно, старый и слепой. Но вдруг увидел чужую заглушку, вместо своей. Облако не отработало вовремя... Логи приводить уже поздно.

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

нужно понимать, что они то же вмешиваются в трафик и влияют на обмен пакетами. Повторится снимите дамп и отправьте в ТП.

[YuryD]

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

нужно понимать, что они то же вмешиваются в трафик и влияют на обмен пакетами. Повторится снимите дамп и отправьте в ТП.

Еще раз повторяю, весь трафик идёт через скат, не зеркало. И вопрос простой, отчего http запись в реестре пролезла сквозь мой скат, хотя присутствовала в моей-же выгрузке, ну и соотв и ТТК. Скат - работал, древние блокировки отрабатывал. Но 3хчасовая задержка в облаке - это заоблачно :( и печально.

[uk2558]

По поводу неблокировки 11 ресурсов - косяк бы на нашей стороне - трафик на те 11 ресурсов (местный IX) шёл мимо СКАТ по резервному линку из-за проблемы с кабелем между роутером и СКАТ. Так что, "Рафик совсем не виновный".

[Желающий]

По поводу неблокировки 11 ресурсов - косяк бы на нашей стороне - трафик на те 11 ресурсов (местный IX) шёл мимо СКАТ по резервному линку из-за проблемы с кабелем между роутером и СКАТ. Так что, "Рафик совсем не виновный".

 

спасибо, что написали, а то я уж взволновался.

[AlexBT]

Чего то я нифига не понял.

Сам оператор блокирует и плюс перед ним оба магистрала блокируют те же урлы и ИП?

Или магистралы на БГП линках не фильтруют трафик?

[YuryD]

Чего то я нифига не понял.

Сам оператор блокирует и плюс перед ним оба магистрала блокируют те же урлы и ИП?

Или магистралы на БГП линках не фильтруют трафик?

Магистралы для меня не должны, но блокируют :( Хотя я и сам справлюсь. Готовлю разборки с ртк по поводу заворачивания трафика до кинозал в /dev/null

[Alex_Sor]

Коллеги, подскажите было у кого такое в отчете ревизора за 5-е число? Чет не пойму как прилетело, тем более это по http.

05 Апр, 2017 02:07:22 475089 http://uapok...org,'>http://uapok...org, 104.18.62.148, GET, HTTP status 530

05 Апр, 2017 02:07:22 475089 http://uapok...org,'>http://uapok...org, 104.18.63.148, GET, HTTP status 530

05 Апр, 2017 02:07:29 475089 http://uapok...org/,'>http://uapok...org/, 184.168.221.54, GET, HTTP status 200, перенаправление С: http://uapok...org (184.168.221.54)

СКАТ стоит "в разрыв".

Изменено 6 апреля, 2017 пользователем Alex_Sor

[bike]

Коллеги, подскажите было у кого такое в отчете ревизора за 5-е число? Чет не пойму как прилетело, тем более это по http

Было, но Вы их в реестре на 5 число видели?

[snvoronkov]

Коллеги, подскажите было у кого такое в отчете ревизора за 5-е число? Чет не пойму как прилетело, тем более это по http.

05 Апр, 2017 02:07:22 475089 http://uapok...org,'>http://uapok...org, 104.18.62.148, GET, HTTP status 530

05 Апр, 2017 02:07:22 475089 http://uapok...org,'>http://uapok...org, 104.18.63.148, GET, HTTP status 530

05 Апр, 2017 02:07:29 475089 http://uapok...org/,'>http://uapok...org/, 184.168.221.54, GET, HTTP status 200, перенаправление С: http://uapok...org (184.168.221.54)

СКАТ стоит "в разрыв".

Та-же фигня +еще два URL:

05 Апр, 2017  03:09:18;334439;http://bukmekery-online.ru, 46.105.135.216, GET;ФНС;15 Авг, 2016  08:37:08;200;
05 Апр, 2017  03:54:50;346191;http://football.sport.ua, 194.0.131.59, GET;ФНС;15 Фев, 2017  18:59:28;200;
05 Апр, 2017  04:15:31;475089;http://uapoker.org, 104.18.63.148, GET;ФНС;28 Мар, 2017  19:04:44;530;
05 Апр, 2017  04:15:32;475089;http://uapoker.org, 104.18.62.148, GET;ФНС;28 Мар, 2017  19:04:44;530;
05 Апр, 2017  04:15:32;475089;http://uapoker.org/, 184.168.221.54, GET;ФНС;28 Мар, 2017  19:04:44;200;С: http://uapoker.org (184.168.221.54), http://uapoker.org/ (184.168.221.54) 

Самое интересное, что в выгрузке от 00:38 они были, а от 08:37 их уже небыло!

 

СКАТ бежит попередь паровоза?

 

Поправочка: В выгрузке от 03:00 (MSK+2) их уже тоже небыло. Вот теперь придется ежечасные выгрузки для РКН сохранять. Использованные презервативы, мня...

Изменено 6 апреля, 2017 пользователем snvoronkov

[Alex_Sor]

Коллеги, подскажите было у кого такое в отчете ревизора за 5-е число? Чет не пойму как прилетело, тем более это по http

Было, но Вы их в реестре на 5 число видели?

 

Дык, вот сижу ковыряюсь и думаю откуда прилетело ни id записи ни домена в реестре нету, правда смотрю в выгрузке на 23:00 от 4-го числа,

а в отчете указано что "Время включения записи в реестр (UTC) 28 Мар, 2017 19:04:44"

Вот и не пойму что за подстава...

[bike]

СКАТ бежит попередь паровоза?

У меня в выгрузке от 3.00 05.04.2017 этих ссылок нет.

"Пропуски" в 3.50+.

[snvoronkov]

У меня в выгрузке от 3.00 05.04.2017 этих ссылок нет.

"Пропуски" в 3.50+.

Да исправился уже. :-) Посмотрел чужие выгрузки.

 

Я просто выгружал по изменению LastDumpDateEx, но не реже раза в 8 часов.

Теперь, бл..ь, буду три раза в час выгружать! Пусть зае..тся отдавать.

[YuryD]

Я просто выгружал по изменению LastDumpDateEx, но не реже раза в 8 часов.

Теперь, бл..ь, буду три раза в час выгружать! Пусть зае..тся отдавать.

 

Ну мне хватает 1 раз в час. Обязательно храню полгода все архивы выгрузок. Обязательно храню письма от своей самописной заборки про неудачность-ошибки. Ну и принудительно раз в день, несмотря на LastDumpDateEx. Ибо не забирал - можно получить за невыгрузку.

 

Хотя к скату это отношения не очень имеет. Это к наказанию за невыгрузки, а Скат в облаке вполне корректно обновляет свои базы.

[snvoronkov]

Опять не блокирует!

 

<content id="517769" includeTime="2017-04-18T21:36:52" entryType="4" blockType="ip" hash="23559FB02A5D61CFE96D66A26F1DDEF7"><decision date="2017-04-18" number="5-Restricting" org="Роскомнадзор"/><ipSubnet>192.12.31.0/24</ipSubnet></content>

 

$ lynx -dump http://192.12.31.64

#[1]publisher

 

[2]get imo apk

 

imo free video calls and chat

on Android and iPhone

[3]get imo from the iTunes store

Download on the

iPhone App Store

[4]get imo for Android from Google Play

Download on the

Android Play Store

[5]get imo for Windows Desktop

Download imo for

Windows Desktop

[6]Download imo apk now

 

[7]Home[8]Download[9]Careers[10]Policy

 

Ссылки

 

1. https://plus.google.com/108102764218883471843

2. http://192.12.31.64/

3. https://itunes.apple.com/us/app/imo-free-video-calls-and-chat/id336435697

4. https://play.google.com/store/apps/details?id=com.imo.android.imoim

5. https://imo.im/winapp/current/ImoSetup.msi

6. http://192.12.31.64/download/imo.im-latest.apk

7. http://192.12.31.64/

8. http://192.12.31.64/download/

9. http://192.12.31.64/careers

10. http://192.12.31.64/policy

 

Открыл инцедент. Но что-то мне кажется, что опять проволынят до "послепраздников". :-( Как ни странно, состояние уже "В работе".

Изменено 5 мая, 2017 пользователем snvoronkov

[snvoronkov]

Опять не блокирует!

 

...

 

Открыл инцедент. Но что-то мне кажется, что опять проволынят до "послепраздников". :-( Как ни странно, состояние уже "В работе".

Ежели кому интересно - есть "partial fix" в обновлении баз. К сожалению, даже не все проверенные утром "Ревизором" IP туда попали.

Фильтруйте покамест на роутере.

[Bigmazy]

... К сожалению, даже не все проверенные утром "Ревизором" IP туда попали.

...

Как узнали какие ревизор IP проверял, в отчете только номера записей вижу ?

 

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

[snvoronkov]

Как узнали какие ревизор IP проверял, в отчете только номера записей вижу ?

Посмотрел Netflow, вестимо. Собирается с ближайшей кошки.

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

Обещали "доработать тестировщик". А вдруг и вправду все праздники не покладая рук работать будут? От греха подальше поставил дроп всех ipSubnet (благо таковых всего ЧЕТЫРЕ).

Для особых нелюбителей лишних блокировок - можно этот фильтр вообще ТОЛЬКО на интерфейс Ревизора повесить. :-) И волки сыты, и овцы целы.

[YuryD]

Обещали "доработать тестировщик". А вдруг и вправду все праздники не покладая рук работать будут? От греха подальше поставил дроп всех ipSubnet (благо таковых всего ЧЕТЫРЕ).

 

Ну 192.12.31.0/24 а остальные 3 ? Из дома неудобно в xml лазить...