Комментарии 34
Интересная идея. Спасибо. Можно пойти дальше — роутеры Вы ведь клиентам сами поставляете? Можно попросту на роутер ставить такого "клиента" и оттуда удаленно тащить метрики по каналу. В любом случае, любой роутер от провайдера — это по сути бекдор. А если развить идею, то прямо на нем можно настраивать блокировки и все такое (привет, РКН!).
Закрыты снаружи, только тем не менее как-то удается их взламывать. В частности, меня просто добила атака, когда злоумышленник подменяет днс, делает фейковую страницу и получает доступ к роутеру из внутренней сети с устройства самого клиента, где, получается, запускается вредоносный js.
Ещё не менее занятная история с этими gpon'ами от Ростелекома и мгтса и приставками iptv. Служба поддержки 100% может их как-то перенастраивать снаружи — это же удобно (!). Я уж не говорю о том, что провайдеры вмешиваются в клиентский трафик. Поэтому в "безопасность" в принципе не верю
Поэтому не могу согласиться — безопасность безопасностью, а удаленку можно сделать.
С зондом такая же история — устройство, как я понял, по сути ставится в периметр клиента, и на нем в теории может быть что угодно от сканирования устройств клиента на уязвимости вплоть до ВПН туннелей и обратного ssh для удаленки.
Вплоть до пингов. TP-Link/D-Link/Netis/Tenda теперь даже не пингуются по WAN порту.
Ок, поверю, принято.
По доп функционалу — почти все вендоры предлагают кастомные прошивки, «под оператора», в которые, за определенную денюжку, можно, что угодно встроить. Мы пока не столь крутой оператор, что-бы кастомные прошивки заказывать.
Вмешиваться же в пользовательский трафик я не имею права. Ни по закону ни по совести. Ну не занимаемся мы таким и, надеюсь, никогда не начнем.
Историю про МГТС читал. Много думал. В нешифрованном трафике можно внедрять код. В шифрованном — никакой DPI не поможет. Там нагрузки колоссальные. И чем больше трафика тем проблемнее это делать. Могу напомнить историю поиска решения для DPI Российским правительством. В требованиях был анализ ssl/tls в реальном времени. И, на сколько помню, так и не нашли. Но это не точно. Не следил за историей.
Я думаю, что Вы все верно говорите. Но рассмотрите такой кейс. Маршрутизатор у провайдера покажет, что утилизация канала 10%. И не больше. Как это можно интерпретировать? То ли клиент не жмёт больше (просто потому что вторая сторона, откуда клиент качает данные больше не может), то ли что-то сломано ещё. А клиент заплатил, скажем, за 100мбит по тарифу. Значит, нам на стороне клиента нужна штуковина, которая сможет и генерировать, и забирать трафик с этой скоростью. Другой вопрос, который у менЯ и возник, почему этот "зонд" не может быть интегрирован в маршрутизатор/роутер клиента
утилизация канала 10%. И не больше. Как это можно интерпретировать?Вам надо посмотреть в толковом словаре слово «утилизация», и станет понятно: как интерпретировать это выражение ;-)
Если CPE однотипные, можно разработать сбор статистики wifi с CPE. Средние сигналы устройств, количество клиентов, ретрансмиты, etc.
От измерения скорости мы ушли. Оно, как оказалось, вообще никак не кореллирует с жалобами на сервис.
Вы какие-то странные выводы из наблюдений делаете. В случае с ютубом надо как минимум изучить маршрут до сервера, откуда видеопотока получается. С торрентами у вас банально роутер может с ума сходить от большого числа подключений — попробуйте качать через впн.
Количество соединений в торрент клиенте у меня ограничено, проседают даже поставленные днём на паузу закачки с тех же ip.
Т.е. на лицо перегруженная последняя миля, но speedtest.net говорит что всё в порядке. Это как электрики, которым жалуешься на пониженное вечером напряжение, но они приезжают измерять его днём, когда всё в порядке.
Пока сидел через РТ такого не было, не смотря на скорость в десять раз большую.
Но спидтест(который .net) вечером показывает что с последней милей всё в порядке, замер в другие города показывает аналогично красивую, но бесполезную картинку.
Т.е. на лицо перегруженная последняя миля, но speedtest.net говорит что всё в порядке.А дальше страны вы пробовали измерять? Если мне не изменяет память, власти в России запретили кеширующие сервера Гугла, поэтому весь Ютуб тянется из соседних стран. Ну а торренты и так с любой точки могут грузиться, не обязательно из соседних городов.
А у Йоты ютуб вечером может проседать даже до 500-700кб/с. Аналогично с ним проседают и другие соединения, но там это не так критично. Т.е. проблема с последней милей есть, но её как то маскируют.
Есть более комплексные решения. 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/
Разработка zond-а для замера скорости интернета