Нет, не все нужно. Хопбайхоп можно наверняка убрать.
про tcp это или quic
Ща гляну.
Не, не гляну. От долбежки триггернулась всякая хрень и пошли выкрутасы. Пока продолжает открываться без quic, пока не могу сравнить. Понаблюдаю еще позже когда остынет.
Насчет кеша, даже не знаю. Именно гуглового хрома у меня нет, но в яндексовом, в опере вроде все ок, то есть я даже не делая Ctrl+Shift+Del (очистка выборочно или всё) и т.п. просто пастил после заглушки и всё взлетало. В IE11, однако, бывают тупняки и заглушка. Сейчас вот параллельно с написанием этого текста потыкиваюсь в опере с вырубленным квиком и открывается. Надо попробовать и файрфокс, нет его под рукой. Позже. Будет новый подопытный кролег.
речь про ssl кэш а палят именно tls так хром и иже с ними раз ssl схавав из кэша его и берёт вплоть до того что после выкл. запрета продолжает открывать
или неоткрывать
поэтому рандомность заглушки в нём не поймать. а в ie11 гут
но всё равно сама эта рандомность вымораживает… бох сним с клаудовой ошибабкой - почему пчелайн вклинивается? но не не всегда…
Когда работают всякие хитрые балансировщики, защитные сервисы, клаудфлеры как тут и т.п., возможно, несколько зеркал, и плюс к этому еще и несколько дипиаев, то может быть любая рандомность. На мой субъективный взгляд, сам zapret (nfqws) отработал по предназначению прекрасно. Будем считать что сайт модельный. Кое-что подкрутив, можно использовать такую балалайку уж как есть, через небольшую пень-колоду, и не беда лишний раз после заглушки ткнуть back и затем в номер страницы и т. п. Теоретически, можно туннелироваться с точкой выхода именно в билайне и посмотреть будет ли разница. Возможно, будет примерно как @uwu выше пишет. В бытовом смысле оно того не стоит, разве что для тестирования.
мысль что обратный маршрут какимто бесом рандомен а мудаки с пчелайну смотрят не клиентхелло (который якобы задурен) а серверхелло и т.к. тока tls1.2 то отсос. а отчего обратный маршрут рандомайз- х.з.
но уже важно что нетольколишь уменя а всех провов именно билайн вклинивается
20-21.12.24 СПб, ЭР-Телеком (Дом ру).
Отвалились видео на ютуб после дня “техработ” (начало в 0:00). Были выключения по несколько часов, однако со скрипом всё работало. После окончания работ (в 20:00 по мск) перестали загружаться видео (превью и поиск работает).
Kyber (вкл/выкл), все варианты general, а также opera/mozilla/chrome - везде результат один.
Однако при включении VPN и смене локации на любой другой регион (по России тоже) - спокойно грузит.
хмм, ктонибудь более опытный сможет объяснить?
есть некоторые сервера googlevideo , которые не пробиваются запретом. я заметил некоторые различия в wiresharke но мне не хватает навыков их интерпретировать
если например открывать ggc, который пробивается: то ситуация следующая
выполняется tcp : [syn], [syn,ack],[ack]
выполняется tls1.3 : [client>server tls 1.3 client hello], [server>client tls1.3 client hello]
если открывать ggc, который не пробивается:
выполняется tcp : [syn], [syn,ack],[ack]
выполняется пакет который называется ssl [client>server] и на этом все, с той стороны больше ничего кроме ack не приходит. пакетов с названием протокола tls впринципе нет. client hello тоже нет
не подскажете в какую сторону в настройках запрета копать? вообще имеет смысл в таком случае смотреть в сторону настройки sni?
самое забавное, что если принудительно указать ttl например =1 до тспу, то ничего не меняется (в первом случае по прежнему есть tls1.3, только блочится на уровне sni)
могу только дать подсказку, что во втором случае предположительно 2 коробки тспу разных провайдеров (в первом 1)
у меня ютуб работает, это скорее я на будущее уточняю
У меня вопрос скорее в пространство, чем к кому-то конкретно. Я часто читаю, как люди пытаются “пробить” какие-то сервера. И вот вопрос. Вы вообще в курсе как работает ггц? Не в теории, а на практике. Что настраивает провайдер, что настраивает гугл, как должны вести себя кэши при многоногом провайдере, как провайдеры могут заставлять при многоножие выбирать ггц те сервера, аплинк через которого они берутся приоритетнее, “трехуровневый бэкап”. И все вот эти вещи, которые вы не видите по кнопке ф12. Я к тому, может те сервера, которые вы пытаетесь “пробить”, прописать в хост файлах, и прочие извращения, может они вообще не должны “пробиваться” в данный момент времени, и не тспу причина, а настройки ггц? При динамическом ип каждая /24 сеть вообще может смотреть в свой ггц, и сменив ип вы можете пытаться “пробить” сервера, работающие по вайтлисту с вашим прошлым диапазоном ип. Еще до блокировок заставить ггц работать так, как нужно, было той еще задачей, с гуглом переписывались месяцами. Вы хотя бы проверяете, какой пул серверов выдает вам ггц в тот промежуток времени, в который вы пытаетесь что-то пробить? Может там вообще балансировка на три ноги, и на каждой по тспу?
Так напишите аналогичную схему для zapret, и будет тоже самое
Для надежности проверить шарк GDPI и zapret и сравнить
–dpi-desync=fake,multidisorder --dpi-desync-split-pos=1 --dpi-desync-ttl=9
Разница может быть в фейк пейлоаде. Его можно попробовать скопировать из шарка после GDPI и всунуть в --dpi-desync-fake-tls
Всегда в таких случаях надо брать шарк и разбираться. Но юзера тычат, не понимают, а потом говорят, что не работает. Поэтому я практически не реагирую на подобные вопросы типа “перестало”, а issue закрываю или перемещаю в дискуссии (зависит от степени содержательности)
На первый отсыл данных клиентом по TLS zapret никак не может влиять. Если есть 3-way handshake. Что показывает шарк - это его интерпретация. У него есть функция decode as, чтобы выбрать диссектор вручную, если автоматика не срабатывает правильно.
Что касается дальнейшего виса. Стандартная схема блокировки по исходящему пакету такова, что после него больше не приходит ничего, даже ACK в ответ на него. Полный глухарь по туплам.
Но пути блокировок неисповедимы. Разный зоопарк на разных провайдерах может что угодно преподнести. В таких случаях надо гнать тот же трафик на любой другой неблокированный сервер и сравнивать. Неважно, что будет ругань. Важно отличие что приходит
Решил еще раз поднять тему ATV youtube.
Еще раз запустил эмулятор genymotion. И схватил все ту же проблему.
На GQUIC ответа нет никакого.
Фейки не помогают.
Если заредиректить udp:443 на VPS, тоже нет ничего в ответ.
Если слать пакеты GQUIC на VPS, они приходят.
Создается впечатление, что сами сервера не отвечают на GQUIC.
Приложение выпадает в ошибку вскоре после клика на видео.
У кого оно работает можете посмотреть в шарке что там происходит ? Отвечают ли на GQUIC ?
Я это к тому, что имеет ли смысл делать поддержку GQUIC протокола, или это бессмысленно
Уже много раз писали, но ответа так и нет. Ютуб грузит только до 00:59. Инкогнито, отключение адблока не помогают. После изменения темы на светлую\тёмную грузит ещё минуту.
С впн работает без проблем. Локация - Крым.
Уже много раз писали, но ответа так и нет. Ютуб грузит только до 00:59. Инкогнито, отключение адблока не помогают. После изменения темы на светлую\тёмную грузит ещё минуту.
С впн работает без проблем. Локация - Крым.
Это с запретом скорее всего не связано, есть отдельная тема, которую пока не удалили:
Похоже, что напрямую обращение к jnn-pa.googleapis.com не работает или возвращает 403/CORS Failed, а через прокси работает, можно посмотреть разницу в инструментах разработчика в браузере.