Речь шла о блоке РКН. Боты яндекса все прекрасно видят. Это можно проверить.
И такое случается с сайтами, которые не блокированы. Глюк яндекса.
Я прежде всего про то, что учитывая количество внереестровых ТСПУ-блокировок, надо проверять их тоже. А то люди уже привыкли что можно проверить идентификатор ресурса по реестру РКН и сделать вывод о наличии или отсутствии блокировки. Так больше не работает. Плюсом еще помними про новые динамические блокировки протоколов, которые часто работают крайне глючно и блокируют непричастных.
Просто у меня есть подозрения что яша начал использовать другого провайдера, который при попытке подключится к заблоченному сайту РКН - выдает ему заглушку. И от этого появляется ошибка SSL и теперь еще начала иногда появляться ошибка о невозможности установить соединения с сайтом
Яшка не использует провайдеров интернета.
Фактически любой ру-прокси из директа хостинг-конторы будет пускать тебя на все блокнутые РКН сайты.
Проблема исключительно у Яндекса. Проблеме не один год.
DPI-оборудование уже давно стоит не только у "домашних" интернет-провайдеров. Оно также установлено на каналах магистральных российских провайдеров. Также ставят непосредственно у хостинг-провайдеров.
И надо различать что есть ТСПУ, а есть самые разные иные системы которые ставят провайдеры, типа "сами", как СОРМ или по иным причинам.
Пока еще можно найти хостинг-провайдеров в РФ трафик которых так или иначе идет в обход блокировок, иногдя частично (ТСПУ) и которые в какой-то мере не реализуют блокировки для клиентского трафика. Но эта, скажем так, недоработка ответственных служб, она уже исправляется. В т.ч. для этого был принят нашумевший закон, налагающий всякие обязанности по плотному взаимодействию со службами на все российские хостинг-компании .
Это и наблюдается, проверяющий получает подменный невалидный сертификат.
В чем смысл такого решения, если площадки, мягко говоря, не пользуются успехом? Типа "и так сойдет"?
Именно в этом и смысл.Если бы они пользовались популярностью, можно было бы блокировать сразу без лишних прелюдий. Или не блокировать, если все сами из Youtube ушли бы 😀
Вам отечественную альтернативу предоставили? Предоставили. Никто не обещал вам, что будет качественный продукт. Массы будут пользоваться. Им не столько важно качество контента и пользовательский опыт. И так сойдет. Еще миллиардов 10 денег на производство и наполнение правильным контентом вложат и вообще конфетка будет 😀
А там замедлят Youtube так, что 480p по несколько минут грузится будут, глядишь и популярность импортозамещенных альтернатив увеличится.
Вон в Туркменестане люди как то же живут и не жалуются, "и вы не жалуйтесь" 😀
Не все домохозайки поняли типу меня, можно пояснительную бригаду?
Это сознательное замедление Youtube со стороны госорганов РФ на ТСПУ (это такой черный ящик, который насильно устанавливается провайдерам РФ, врезается в канал, он им неподконтролен, и может делать все что угодно с клиенскои трафиков), а не проблемы с кэширующими сереврами Гугла, как написали в пресс-релизе Ростелека и цитируют в новостях.
DPI анализирует трафик пользователей интернер провайдеров РФ, фильтрует пакеты в зависимости от их содержимого, если видит SNI (имя хоста) по маске *.googlevideo.com , то дропает часть пакетов этого коннекта, часть пакетов теряются, такми образом замедляя скорость доступа.
Похоже решили вместо полной одномоментной блокировки постепенно замедлять скорость, чтобы пользователи могли "постепенно и маскимально комфортно" переходить на Rutube, VK или чем там имортозамещать Ютуб будут.
В новостях же именно так сказали, там не могут врать!
Откуда вы такие наивные беретесь...
Не читайте с утра советских газет. Ну или хотя бы не верьте тому что там пишут.
Замедление на ТСПУ по SNI=*.googlevideo.com.
Замедляется не только у РТК.
Кстати можно еще проверить открыв play.google.com
На ntc уже давно все оттестировали, и вывод однозначен.
"...нашел ссылку на большой файл на удобном домене в инфраструктуре Google, к которой можно обращаться с подменой домена.
Вот более репрезентативный тест. Как и предыдущий, он тестирует скорость скачивания с IP Google с разными SNI, по HTTPS/1.1 (TCP), и не учитывает наличие кеширующих серверов YouTube у провайдера.
Google IP + GCR SNI curl -s -o/dev/null -k --connect-to ::google.com -k -L -H Host:\ mirror.gcr.io --range 0-40000000 --max-time 30 https://mirror.gcr.io/v2/cimg/android/blobs/sha256:6fd8bdac3da660bde7bd0b6f2b6a46e1b686afb74b9a4614def32532b73f5eaa -w %{speed_download} Google IP + Googlevideo SNI curl -s -o/dev/null -k --connect-to ::google.com -k -L -H Host:\ mirror.gcr.io --range 0-40000000 --max-time 30 https://test.googlevideo.com/v2/cimg/android/blobs/sha256:6fd8bdac3da660bde7bd0b6f2b6a46e1b686afb74b9a4614def32532b73f5eaa -w %{speed_download}
Кстати, на некоторых провайдерах можно обойти замедление включением QUIC.
"Проверил QUIC (HTTP/3) на нескольких каналах — не замедляется. А вот локальные IP начали замедляться.
Скорости невысокие из-за слабой производительности шифрования на тестируемых устройствах (x86 1 ГГц)
bums #:
В случае же с падением ДНС .RU произошло стечение обстоятельств(возможно - кривое или устаревшее ПО, несвоевременное обслуживание, банальное рукожопство, отключение питания, нет бэкапа и т.д. и т.п) и для решения проблемы надо было: собрать персонал в выходные, найти причину, устранить её, устранить последствия проблемы. Получается более длительный процесс.
На диагностику причины 15 минут. Максимум. И то, если автоматического мониторинга нет. Исправление да, дольше, ибо кэш.
Про "отключение питания", да именно отключение питания обычно и генерирует кривые подписи 😀
Или вы про "лампочка моргнула, и сотрудник с испугу, пролил кофе на кота, который, в совю очередь, ввел ошибочную команду лапой на клавиатуре"? 😂
Про бекапы, они тут каким боком?
Про работающий персонал в выходные, человек который генерировал подпись за персонал по вашему, не считается? Или думаете, что уборщица этим занимается? И это кстати вторник был, с каких пор в РФ вторник стал выходным днем?
То, что нет автоматической проверки подписей зоны, в очередной раз показывает отношение к стабильности критической инфраструктуры.
Вот пока вся вина будет сваливаться на "стечение обстоятельств", как вы выразились, подобные истории будут повторяться снова и снова. В подобных инцидентах есть конкретные виновные люди, всегда.
А последующие рекомендации по отключению DNSSEC и скидывание вины на некое "зарубежное ПО" намекают, о том, какие выводы были сделаны.
Доменная дона крупнейшей Державы, а управляется все наколеночным методом, как будто домена африканской страны с некомпетентными растаманами, окончившими пару классов школы, и устроенными по блату, вместо клалифицированного персонала.
Что касается HE, тоже те еще...
Даже мелкие хостеры, если не имеют собственного регистратора доменов, стараются разносить DNS на разные домены, как раз для снижения рисков подобной ситуации.
