Comments 34
Доказать абоненту, что линия в порядке и проблема в том, что у него телефон «не той модели.»
Доказать абоненту, что линия в порядке и проблема в том, что у него телефон «не той модели.»

из статьи не понял — сам абонент должен на зонд заходить? Или достаточно проверки им "качества связи при помощи ookla по вашей инструкции"?

Как я понял, если клиент жалуется на связь, то ему втыкают сей девайс на сутки и мониторят.

Интересная идея. Спасибо. Можно пойти дальше — роутеры Вы ведь клиентам сами поставляете? Можно попросту на роутер ставить такого "клиента" и оттуда удаленно тащить метрики по каналу. В любом случае, любой роутер от провайдера — это по сути бекдор. А если развить идею, то прямо на нем можно настраивать блокировки и все такое (привет, РКН!).

В роутерах слабые процессоры, они не смогут нормально тестировать гигабит.
MIPS MIPS`у рознь, как и ARM ARM`у. Есть суперкомпьютеры и с теми и с другими.
Абонентские роутеры в маленьких провайдерах обычно берутся максимально дешёвые (вроде китайских Tenda), а на софт и оборудование для TR-069 как всегда не хватает ни денег, ни квалификации персонала.
На самом деле проблема не в процессорах, а в самих роутерах. Внедрить сбор метрик напрямую с роутера не выйдет. Большинство роутеров, ввиду трендов по взломам, снаружи закрыты. Вплоть до пингов. TP-Link/D-Link/Netis/Tenda теперь даже не пингуются по WAN порту. Вторая проблема — внедрение нужного функционала в прошивку роутера. Задача на самом деле не тривиальная. Была попытка установки OpenWRT на подобные девайсы. Там проблема в отсутствии места ПЗУ. Оперативы хватает, а вот места на флэшке нет.

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


Ещё не менее занятная история с этими gpon'ами от Ростелекома и мгтса и приставками iptv. Служба поддержки 100% может их как-то перенастраивать снаружи — это же удобно (!). Я уж не говорю о том, что провайдеры вмешиваются в клиентский трафик. Поэтому в "безопасность" в принципе не верю


Поэтому не могу согласиться — безопасность безопасностью, а удаленку можно сделать.


С зондом такая же история — устройство, как я понял, по сути ставится в периметр клиента, и на нем в теории может быть что угодно от сканирования устройств клиента на уязвимости вплоть до ВПН туннелей и обратного ssh для удаленки.


Вплоть до пингов. TP-Link/D-Link/Netis/Tenda теперь даже не пингуются по WAN порту.

Ок, поверю, принято.

Взламывать удается когда админы открывают управление на wan-е. Для удобства администрирования из-дому. Мы все наши роутеры тестим на этот счет. Снаружи 22/23/80 порты по умолчанию закрыты. Я даже периодически сканер в абонентской сети запускаю. Посмотреть не нашелся ли кто-то «рисковый». Наказать как бы не могу, но вот дать совет — вполне реально.
По доп функционалу — почти все вендоры предлагают кастомные прошивки, «под оператора», в которые, за определенную денюжку, можно, что угодно встроить. Мы пока не столь крутой оператор, что-бы кастомные прошивки заказывать.
Вмешиваться же в пользовательский трафик я не имею права. Ни по закону ни по совести. Ну не занимаемся мы таким и, надеюсь, никогда не начнем.
Историю про МГТС читал. Много думал. В нешифрованном трафике можно внедрять код. В шифрованном — никакой DPI не поможет. Там нагрузки колоссальные. И чем больше трафика тем проблемнее это делать. Могу напомнить историю поиска решения для DPI Российским правительством. В требованиях был анализ ssl/tls в реальном времени. И, на сколько помню, так и не нашли. Но это не точно. Не следил за историей.

Ну, казахи сделали просто — тупо госсертификат каждому гражданину и официальный MitM.

Если это ставится как зонд на последней миле, то не совсем понятно. Пинговать можно любой маршрутизатор до клиента. А забивать каждую минуту весь канал тестом скорости — мне кажется это не правильно. В целях диагностики должна же быть статистика (потери и т.п.) на портах маршрутизатора.

Я думаю, что Вы все верно говорите. Но рассмотрите такой кейс. Маршрутизатор у провайдера покажет, что утилизация канала 10%. И не больше. Как это можно интерпретировать? То ли клиент не жмёт больше (просто потому что вторая сторона, откуда клиент качает данные больше не может), то ли что-то сломано ещё. А клиент заплатил, скажем, за 100мбит по тарифу. Значит, нам на стороне клиента нужна штуковина, которая сможет и генерировать, и забирать трафик с этой скоростью. Другой вопрос, который у менЯ и возник, почему этот "зонд" не может быть интегрирован в маршрутизатор/роутер клиента

утилизация канала 10%. И не больше. Как это можно интерпретировать?
Вам надо посмотреть в толковом словаре слово «утилизация», и станет понятно: как интерпретировать это выражение ;-)
Да просто не подумали об этом, возможно. Или модели роутеров используются такие, куда особо не наинтегрируешь. Однако, сейчас можно взять такой роутер, который может, интегрировать в прошивку управляемый удаленно спидтест и при нужде просто менять у клиента роутер, возможно, навсегда.
Если есть деньги — внедряйте сбор так называемых параметров QoE. Я так понимаю, определенных стандартов нет, но, обычно, хватает элементарных: Количество потребителей во внутренней сети клиента, задержки, всякие tcp метрики. Удобно вылавливать проблемы, клиенты будут благодарны. Плюсы — не зависит от типа CPE.
Если CPE однотипные, можно разработать сбор статистики wifi с CPE. Средние сигналы устройств, количество клиентов, ретрансмиты, etc.
От измерения скорости мы ушли. Оно, как оказалось, вообще никак не кореллирует с жалобами на сервис.
Давно заметил что Speedtest брешет, т.к. даже популярный торрент порой не может выдать и половину измеренной скорости. Или ютуб показывает 2-3мб/с(и соотв. не тянет 1080р), а Speedtest 20-30мб/с. Но ТП требует скринов именно из него и игнорирует альтернативные способы измерения.

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

Что ютуб, что торрент(и все другие варианты где можно максимально нагрузить канал и измерить скорость) проседают вечером в час пик, каждый день, показывая примерно одинаковую скорость. В остальное время используются вся ширина канала. Но спидтест(который .net) вечером показывает что с последней милей всё в порядке, замер в другие города показывает аналогично красивую, но бесполезную картинку.
Количество соединений в торрент клиенте у меня ограничено, проседают даже поставленные днём на паузу закачки с тех же ip.
Т.е. на лицо перегруженная последняя миля, но speedtest.net говорит что всё в порядке. Это как электрики, которым жалуешься на пониженное вечером напряжение, но они приезжают измерять его днём, когда всё в порядке.
Пока сидел через РТ такого не было, не смотря на скорость в десять раз большую.
Но спидтест(который .net) вечером показывает что с последней милей всё в порядке, замер в другие города показывает аналогично красивую, но бесполезную картинку.
Т.е. на лицо перегруженная последняя миля, но speedtest.net говорит что всё в порядке.
А дальше страны вы пробовали измерять? Если мне не изменяет память, власти в России запретили кеширующие сервера Гугла, поэтому весь Ютуб тянется из соседних стран. Ну а торренты и так с любой точки могут грузиться, не обязательно из соседних городов.
Когда Сидел на РТ Gpon(а это было всего несколько месяцев назад), скорость соединения с ютубом меньше 50мб/с не показывало, даже вечером(торренты все доступные 300мб/с использовали, а если были локальные пиры, то до 1гб/с скорость могла подниматься). Ранее сидел на ADSL и там всегда показывало максимальную скорость канала 6-9мб/с.
А у Йоты ютуб вечером может проседать даже до 500-700кб/с. Аналогично с ним проседают и другие соединения, но там это не так критично. Т.е. проблема с последней милей есть, но её как то маскируют.
У операторов, зачастую, несколько аплинков. Например, у кого-то имеется google cache сервер. И он его внаглую продает. Операторы подключаются к такому «владельцу» и покупают у него канал. Через какое-то время весь трафик на гугл начинает литься по данному линку а не по внешке. И оператору это очень выгодно.
Есть более комплексные решения. Data-IX, если не ошибаюсь. Они предлагают кэш vk/facebook/google/twitter/tiktok. И все в одном флаконе.
Вот отсюда и появляется перекос скоростей. Когда внешка у вас быстрая, а ютуб медленный. Оператор просто не рассчитал нагрузку и кэш слишком сильно загружен. Если оператора пнуть — есть вариант, что кэш расширят. И тогда ситуация выравняется.
Ну так тормозит то не только ютуб. Торрент, клиенты онлайн игр, стим, онлайн кинотеатры.
Судя по комментариям к этой публикации, я далеко не один заметил такое поведение. И это не вчера началось.
Тормозят даже ролики в ВК(как и любой другой тяжёлый контент внутри страны, судя по IP), который по идее локальный.

Использованный Вами (и широко используемый большинством) опенсорсный speedtest-cli на Python работает по устаревшему механизму и выдает замеры скорости достаточно сильно расходящиеся с реальным speedtest.net. Замеры ping у этого клиента вообще не адекватны. Сам автор на GitHub делает оговорку о зависимости замеров от версии Python, CPU, Memory, etc.
Поэтому рекомендую попробовать использовать Speedtest CLI от самой Ookla, который был опубликован в октябре 2019.
Если будете делать контейнер, то нужно использовать опции --accept-license --accept-gdpr для принятия лицензионного соглашения в не интерактивном режиме.

Потому, что я о нем от вас узнал. Большое спасибо, «буду посмотреть». Беглый гугл ранее мне выдавал только коммерческие решения. За много тысяч килобакосв. А это я больше «по-фану» писал. Накатывает иногда, что-то для души сделать. По-своему. Пусть и через грабли.

Если хотите отслеживать что-то большее, чем просто скорость и пинг в отдельности, то воспользуйтесь профессиональной утилитой flent
https://flent.org/

Only those users with full accounts are able to leave comments. Log in, please.