Мелкие провайдеры самые пакостные.
И логики там нет. У меня, например, конфигурация открывает даже Твиттер и Инсту, а вот Ютуб наглухо не работает с мая. Хотя официально Ютуб в стране не заблокирован. Но глушат его сильнее, чем Инсту и X.
А вы попробовали проверить ютуб на блокировку по IP? (не знаю, можно ли через тот же nslooup это чекнуть) Думаю, что для маленьких провайдеров протестировать IP блокировку будет не сложно, в отличие от гигантов.
Или может вам тоже сделать build запрета и поиграться с новыми параметрами orig ttl и dup.
Возможно, что у вас секут вообще все (если такое возможно в рамках небольшого провайдера), как у нас на ДВ секут ttl и md5sig. Возможно, что это поможет.
Хотя, функционал то обновился для ttl и md5sig. А если у вас даже без этих ограничителей не работает, то жестко же у вас прибито все гвоздями.
Не совсем понятно какое дело провайдеру до ютуба. Для блокировок провайдерами РКН придумал выгрузки (реестр запрещенных ресурсов) и ютуба (гуглвидео) там нет. Так что скорее это тспу работает.
На мелких провайдерах рандом полный. Самая дичь на на ртк имхо. А блок ютуба лучше в другой ветке обсуждать
На многих провайдерах еще не выключены собственные шайтан-машины
у меня полный блок youtube.com , но на удивление тулза youtubeUnlock на опенврт все решает, хотя многие жалуются. в общем, и фейсбук с нею открывается и инста и ютуб. Как и сказали выше - рандом полный у провов.
Спойлер
Да. На ртк мск дичь особая , началась еще с 5-6 мая , и теперь каждый день по 2-3 раза в любое время дня и ночи крутят то-ли ТСПУ то-ли свои провайдерские приблуды. Нормально работать в нете становится затруднительно. Ни скриптом ни ручками , например , так и не удалось подобрать рабочую стратегию для ютуба на GBDPI / Однако легко сам подобрал под ByeDPI ,Запрет из коробки работает от старых версий до последней. YtBystro от KDS аналогично. Часть заблоченных в реестре ресурсов открываются без всякого обхода , а отсутствующие в реестре некоторые блокируются. Полный бардак.
Кстати, не для этого ли спрашивали про оконечные устройства абонентов ?
Да ! Для этого ! Вы совершенно правы.
Спойлер
ртк мск , где-то после 5-6 когда начались проблемы с работой обходов, и начали активно вертеть по нескольку раз в день коробку тспу или еще какую приблцдц у прова , решил я для подбора стратегий для GBDPI запустить в очередной раз чекер - проработал он минут 5 и… отрубились все соединения в сети . Я перезагрузил комп , роутер , попробовал заходить на сайты - нифига.. Где-то через минут 15 все заработало. Я радостно решил продолжить подбор стратегий через чекер и … через 5-минут все повторилось. ( Не буду утомлять , если кратко ,на следующий день я использовал по очереди два других роутера , вначале первый проработал на подборе почти 50 минут , затем соединения легли и повторялся сценарий как и с первым роутером , при подборе стратегий чекером , сеть стала отрубаться через 5 минут. При запуске третьего роутера он в первый раз проработал при подборе где-то 1 час 25 мин и далее с ним стало происходить то же , что и с предыдущими двумя. У соседа с квартиры рядом тот же провайдер , с ним попробовали у него на его роутере подбирать стратегии чекером , после 2-х часов - сценарий стал как и у меня , 5 минут где-то работает перебирая стратегии чекером , потом отвал сети на 15-минут , восстановление работы сети , но при попытка снова запустить чекер , через 5 мин. отвал - “охлаждение на 15 мин” - работоспособность сети возвращается , но если снова активно “чекать” то все повторяется по-кругу. Есть подозрение что блок идет по Ip адресу абонентского оборудования на 15 минут. Вот для чего похоже РКН нужен доступ к идентификаторам клиентского оборудования (((
Мораль сей басни держаться подальше от ростелекома.
Интересно, какое количество одновременных сессий генерирует блокчек? Другими словами, насколько увеличивается количество записей в таблице NAT-трансляций у провайдера? Дело в том, что на одном подключении к РТ несколько лет назад у меня была проблема, что если количества клиентских TCP-подключений оказывалось больше 150-200, новые просто рубились. Выглядело это именно как пишут выше (“отрубились все соединения в сети”). Хотя UDP при этом продолжал работать.
Если не задана переменная PARALLEL, то одну.
Конечно, есть таймауты в любом NAT. Они зависят от фазы tcp. SYN, ESTABLISHED, TIME_WAIT, …
Если ТСПУ рубит соединение, то мне видится тут 2 варианта.
Если ТСПУ находится до NAT, соединение застревает в фазе established, поскольку FIN/RST от клиента после блокировки до NAT уже не доходит. И эта фаза самая долгая по таймауту.
Очень долгая.
В linux вот такая : net.netfilter.nf_conntrack_tcp_timeout_established = 432000
5 суток
В провайдерском CGNAT вряд ли так долго, но все равно долго.
В отличие от UDP, где обычно за 5 минут уже все заканчивается.
Но еще шлет инфу сервер. Обычно он не может пропихнуть TLS Server Hello. Значит будут идти ретрансмиссии с прогрессивно увеличивающейся задержкой, пока tcp/ip стек серверной ОС не сдастся (а это может быть тоже очень долго), либо не настанет таймаут на уровне серверного приложения (видится намного короче, но все равно не 10 секунд). И только после FIN/RST от сервера conntrack переводится в состояние закрытия.
Если же ТСПУ после NAT, то NAT видит FIN/RST от клиента и переводит свой conntrack в состояние закрытия сразу после того, как клиент закрыл tcp сокет. ОС шлет FIN/RST, соединение уходит в закрытие, где таймаут значительно ниже
Таким образом вариант, где ТСПУ находится после NAT, склонен быстрее освобождать соединения, чем вариант ТСПУ до NAT. Но все равно не прям чтобы критически дольше. Простая проверка разных https серверов телнетом на 443 порт показывает, что обычно в течение минуты сервер уже тебя сбрасывает. Но на клиенте это происходит через 2 секунды - таймаут curl по умолчанию в блокчеке
Но есть еще 3-й вариант. ТСПУ может быть несколько на пути. 1 до NAT, другой после NAT. И если они оба резанут, то будет то самое “5 суток”. Кроме ТСПУ есть еще собственные DPI провайдера. Если оба режут TCP сеанс полностью без RST, это тоже самое.
Все мы знаем, что ТСПУ есть и на магистралах. Может на ростелеке сложились звезды именно так
Так что версия вполне реальная. Наверняка у всех тестеров не было внешнего IP. Верно ?
Я бы так это проверил. Перед тестом ставим бесконечную пингалку. Пинг создась mapping в NAT, который будет поддерживаться постоянными пингами. Посмотреть не прекратились ли пинги после “отвала инета”
Напрашивается какой-то постоянный конфиг для блокчека, с флагами, какие ветки вариаций заведомо не проверять или делать quick, а где искать force. Т.к. действительно полный перебор - это очень долго и обычно не нужно, кроме первого раза. Хотя тоже палка о двух концах, у меня он иногда выдаёт неожиданные стратегии.
Не знаю что за магия, но в zapret v71 всё летает просто с --dup-autottl. Даже когда ночью глушилки врубают - всё так же продолжает работать. Может только небольшая задержка появляется (~1 сек.) при открытии запрещёночки. Это на Ростелекоме, Ярославль.
а dup= и dup-autottl для udp применимо?
или просто показалось
мб как пример но про udp или только tcp нет инфы мб.
не знаю мож совпадение но квик завелся там где не работал
dup работает и по udp, но непонятно чего вы этим добьетесь.
1 сек для мд5 убирается подбором dup-ttl или dup-autottl, чтобы доходило до дпи, но не до сервера. только на syn, иначе можно отлететь на ттл защите
для линух клиентов нужен дроп ицмп тайм эксидед, иначе сокет закрывается системой
Спойлер
У нас 1 ТСПУ до NAT - и два после - на четвертом и шестом хопе .По крайней мере так мне объяснили. За достоверность не ручаюсь. До всей этой котовасии пробивалось с -ttl 7. ТСПУ до NAT поставили с начала мая этого года. И начались проблемы с GBDPI и работоспособностью трубы. Проходила инфа ,что до осени всех провайдеров обязательно заставят установить доп.коробку до NAT. Зачем не знаю.У вас есть версии ? За инсайд не ручаюсь, но до этого инфа от источника по срокам обновления ПО коробок нашего прова и т.д. подтверждалась.
Наверняка у всех тестеров не было внешнего IP. Верно ?
Абсолютно верно.
Посмотреть не прекратились ли пинги после “отвала инета”
Пинги идут и после отвала . И что это значит ? В свое время , пингалка помогала подключаться варпу , и псифону , и вроде open vpn так советовали на форумах линуксоидов и это работало до октября 2024. Во всей этой истории удивляет что при подключении НОВОГО (не засветившегося в тестировании чекером) оборудования , в данной ситуации роутера , тестирование может идти успешно и до часа с лишним , а потом уже всегда повторяется описанный мной выше сценарий , такое впечатление , что ТСПУ или еще что вносит адрес оборудования клиента с которого идут запросы в некий лист , типа с оборудования подменяются пакеты и на те временный бан для охлаждения , чтобы не повадно было . Может такое быть на ваш взгляд ? У меня есть еще версия ,что когда стали активно рубить фейки на тспу , для пробива в стратегиях стали использовать множественные пакеты фейков , и возможно тспу рубит соединение принимая за мощную атаку фейками ?