Такой же как и l1 , Квик инишиал
Амнезия не работает если включен скрипт в запрете на квик
Примерно с 26 декабря постоянно ловлю динамический блок на OVH, DO, CDN77
Что именно триггерит блокировку, пока поймать не смог, точно не торрент, блокировка длится примерно 10-20 минут, пока похоже на то что блокировка всех подсетей, запретом подобрать особо что-то не смог. На OVH отчасти пофиг, а вот DO и CDN77 важны
Местный провайдер в Москве. Соседей которые могли “помочь в триггере” нет, так как имею белый статический ip
Из того что могу подозревать, это proton free wg с мусором от amneziawg1.5 и quic от vk, правда я брал не готовый из генераторов, а снимал сам.
Если у кого есть мысли по стратегиям для cdn77 и DO, в меньшей степени ovh напишите.
Если вы отсылаете пакеты в сторону “плохих” IP-адресов, например, различных VPN-сервисов, то сами же себе блок и включаете. Так что для начала нужно полностью отказаться от VPN, чтобы не провоцировать блок. Проверьте, чтобы в браузерах не стояло никаких расширений по обходу блокировок. Проверьте, чтобы на телефонах также не было запущено такое ПО где-нибудь в фоне.
Кроме фри протона который пробовал пускать напрямую есть только варп и xray прокси сам поднимаю и держу только для себя, ещё есть запрет.
Всё что подозрительное отключил, посмотрю как будет
Тут в чем проблема: вы обычно не в курсе об истинном трафике. Допустим, конкретно та точка VPN-входа, к которой вы подключаетесь - она не попала еще в черный список и потому установка VPN-соединения не вызывает срабатывание блока. Но при этом клиент может раз в час, например, обновлять список точек входа. А список этот он получает уже с IP, который входит в “черный список”. И вот тут-то вы и ловите блок.
Если неохота с Wireshark заморачиваться, то самое простое - это отказаться полностью от всего и вся, оставить только чистый инет от провайдера. И посмотреть. Если блоки пропадут, то включаем что-то одно. Ждем. Сутки, например. Если все ОК - еще что-то включаем. И так пока не поймаем ПО, которое вызывает срабатывание блоков.
Отключил приложухи протонвпн, возможно они триггерили блок, может ещё приложухи тора или protonmail на телефоне триггерили блок.
Все подключения у меня были подняты либо в интерфейсе netcraze роутера, либо в его же entware
Если не поможет, то видимо что-то ещё в триггерит тспу, буду вертеться и как-то по другому их маршрутизировать
может быть Zapret: обсуждение - #8574 by meadow_seed
Вкшный есть но не их того списка
Отключение всего из подозрительного для меня не дало результата, видимо остаётся вариант вертеться как могу и маршрутизировать по разным провайдерам/другим впн
Полностью ПК и роутер выключите на 10 мин, обычно блок именно на 10 мин ставится. Затем включите роутер, но не ПК. Попробуйте с телефона зайти куда надо. Если зайдет, то включите ПК, подождите и снова проверьте. Если отвалится на телефоне, то значит, оно при старте ОС запускается, какой-нибудь софт, например, который арендует сервер на каком-то хостере, чьи подсети в запрещенных списках.
Ну и да, подразумевается, что на роутере только опции от провайдера и все, никаких VPN и прочего не поднимается при старте.
Повыкидывал всех в политику с чистым впн внутри впн, подозрения имеют только 2 варианта либо один из андроид смартфонов родителей с игрушками на андроиде либо прошитая тв приставка на андроиде, там вроде всякие пиратские кинотеатры есть, точно не смотрел. Именно когда их выкинул остались только блоки на ovh
По итогу оказалась приставка виновата. Пока решил её оставить в впн, если надётся время и желание то попробую найти приложение которое триггерит тспу
Полностью заблокировали подсеть LINODE 139.162.0.0/16
Даже пинги не ходят.
ШПД РТК ПФО не наблюдаю блокировки со стороны ТСПУ по трассировке.
Заблокировали входящее направление?
По трассировке - одни звёзды, ТСПУ стоит на первом хопе. Скорее всего заблокированы оба направления. Проверить не могу.
Навскидку, до 139.162.1.81 ping ходит с looking glass РТ, со всех регионов РФ.
Сдайте проблему своему провайдеру, возможно это не блокировка, а у него что-то.
Вот ещё сообщение по этому диапазону:
https://ntc.party/t/сообщения-об-отдельных-подтверждённых-блокировках-тспу/4625/1357
UDP в полном блоке, трассировка дальше 3-го хопа не идёт, доступен только TCP и ICMP
Поделюсь наблюдением.
Приложение шлет данные на сервер (http, POST).
Сервер на Hetzner FSN1. Пинг стабильно 70.
Данных немного, за час не более 10кБ.
В каждой соединении (connection), если считать только
входящие пакеты от сервера с флагом PSH, то есть
в которых есть payload, после 12-го пакета от сервера
сервер перестает отвечать, то есть слать ACK.
Клиент после ретраев (retransmissions) шлет пакет FIN,
на который тоже никакого ответа, после чего начинает
новое соединение пакетом SYN, на который моментально
следует ответ от сервера SYN-ACK.
Неподтвержденные данные чаще всего доходят до сервера,
это проверено через другие каналы.
Впечатление полное, что ТСПУ считает пакеты от хецнера,
насчитав 12 PSH шлет хецнеру RST от имени клиента.
Об этом говорит то, что большинство пакетов клиента,
на которые клиент не получил ACK, доходят до сервера.
А также то, что на каждый SYN от клиента моментально
приходит SYN-ACK от хецнера.
Число пакетов PSH от клиента в соединении разное,
наверное ТСПУ на это плевать.
Число 12 как бы намекает на пресловутую проблему 16кБ,
или 16-20, ибо 12*MSS как раз и будет где-то так.
Способ борьбы очевиден: надо, чтобы приложение само считало
пакеты от сервера, и финализировало соединение, не дожидаясь
12-го.
А не переписывая приложение, можно как-то побороть?
Запретом, или еще чем.
Зачем они считают N пакетов? То есть если что-то в них найдут, то не закроют соединение? Белые списки доменов?
Моя версия: это не для блокирования, а для замедления.
Им пофиг, что в пакетах.
Там белые списки sni