Но я использовал wssize с листом для ютуба, и он прекрасно работал.
Он мог просто игнорировать лист, и работать по остаточному принципу, на всё, что не покрывали предыдущие стратегии, потому что стоял в последней, но как минимум наличие хост-листа в одной стратегии с ним ничего не ломало.
Ну и, собственно, стратегию с ним я прописывал последней, чтобы в неё происходил заход только если в предыдущих ничего не совпало, чисто на всякий случай именно из-за этого опасения, что он может дальше протекать. Но мне казалось логичным, что то, что нулевая фаза работает до проверки хоста, никак не мешает после её выполнения всё равно проверить хост, и если он не совпадает, просто перейти к следующей стратегии. Ну и, отменить действие нулевой фазы. Получается лишнее движение, но как минимум не вижу в этом ничего не возможного. В какой-то же момент оно должно отмениться, раз оно на весь вообще трафик после однократного залёта в стратегию не начинает модифицировать (не начинает же?).
Ну и, даже если оно действует до конца обхода всех стратегий, и с этим ничего нельзя поделать, разве не может быть двух разных стратегий для двух разных листов, но обе на одной нулевой фазе, например, тот же wssize? Опять же проверять хост-листы кажется абсолютно разумным для такого случая.
Есть тут что-нибудь, в чём я капитально не прав или что-то не правильно понимаю?
Не ломало, потому что он в этой стратегии не работал
Так и есть. После выявления новых факторов происходит новый поиск профиля и переключение. И если там нет wssize, то действие wssize заканчивается. Хотя оно заканчивается и неявно при выявлении известного протокола, так что для http/tls без разницы
wssize - длящаяся десинхронизация, до условия wssize-cutoff или до неявного cutoff при обнаружении известного протокола (тк дальше долбить смысла нет, критическая фаза обнаружения запрещенки пройдена). при неявном cutoff (forced wssize-cutoff в логе) это последний пакет, по которому проходится wssize (до перепоиска профиля), дальше срабатывает cutoff reached
Если протокол окажется неизвестный и переключение профиля не произойдет, в профиле с wssize нет --wssize-cutoff, wssize будет уродовать соединение до конца, ломая скорость до уровня модема или чуть быстрее. Потому на всякий случай стоит добавить в профиль с wssize --wssize-cutoff=d5 . Почему d4 ? Потому что может идти кибер тлс, который броузер разобьет на 2,3 или 4 части. 3 точно видел, 4 - с запасом. Тогда кибер тлс впишется в cutoff. Неважно сколько в нем пакетов. Даже если 1, то будет forced wssize-cutoff. А если протокол окажется не TLS, то сработает условие --wssize-cutoff. wssize отпустит в любом случае - либо по известному протоколу, либо с 5 пакета данных неизвестного протокола
Если используются скрипты запуска для linux или openwrt, то там даже без --wssize-cutoff проблем быть не должно, потому что работает ограничитель по connbytes. После превышения PKT_OUT nfqws перестанет получать и уродовать пакеты. Тоже самое верно и если вручную на linux прописаны connbytes в iptables/nftables
если wssize не ограничен по ip, то скорости скачивания очень сильно падают на всех ресурсах. у твича ломается поток.
последний раз пробовал год назад, с тех пор отказался.
Сплошной геморрой с этой нулевой фазой и ипсетами. Если прога умеет socks5-hostname (браузеры, например), то можно пустить её через прокси, который установит fwmark для нужных хостов (типа xray), и по этому fwmark отдельный демон nfqws уже будет дурить весь трафик, начиная с tcp хендшейка. Так можно фильтровать по хостам и для нулевой фазы. Можно сделать custom скрипт. Схема такая:
браузер –> прокси ставит fwmark для нужных хостов –> nft/iptables фильтрует трафик по fwmark –> отдельный демон nfqws для одной стратегии с нулевой фазой, в него же направлять ответные пакеты
Наверное, для улучшения качества жизни можно добавить опцию в tpws, чтобы ставил fwmark для нужных хостов, и чтобы в стратегиях nfqws можно было фильтровать по fwmark (если автору не лень). Тогда схема будет ещё проще. Надо только помнить будет, что старшие биты fwmark уже заняты.
Скажите, пожалуйста, как правильно проверять какая стратегия работает лучше, а какая хуже на примере googlevideo.com. Блокчек, как я понял, проверяет лишь есть ответ от сервера или нет, а на замедления не работает. Открывать вручную разные видео и смотреть на глаз что больше тормозит, что меньше очень неэффективно получается.
Имеет. Я вот на первое прочтение могу не понять, но чем больше вчитываюсь, тем лучше это вписывается в общую канву знаний. Существование NTC для меня это буквально радость, потому что совместными усилиями куда проще. Даже если бы я сидел и блокчекал 24/7, всё равно сложно выявить закономерности или сразу адаптироваться к новым подходам, или придумывать их самому. Ментальный ресурс не бесконечен. Мне вот уже натурально приходится устраивать себе “дни без Запрета”, потому что с одной стороны завлекает, как игра, с другой съедает много сил
Ори с гудчеком и Болван - отцы-основатели геймификации обхода блокировок
Это возможно только в одном случае. Если прокси примет соединение, не будет устанавливать исходящее , дождется запроса, проанализирует, выполнит исходящее подключение.
tpws такого не умеет. кто умеет ? xray с опцией sniff ?
Ну так пустите xray под юзером ВАСЯ, сделайте ему outbound - direct на нужные домены. Сделайте правила таблиц в OUTPUT по uid ВАСЯ для направления на nfqws, и будет счастье. Схема FILTER_MARK в скриптах запуска zapret.
А остальные можно пустить через еще одну проксю на localhost. Самую простую. Под юзером ПЕТЯ. Или наоборот - на 2ю прокси ВАСЯ, а ПЕТЯ напрямую.
Самому nfqws фильтровать mark не нужно. С этим лучше справятся таблес, не дергая лишний раз user mode.
Тормозит из всех стратегий только wsize/wssize для nfqws и mss для tpws.
Остальное, если написано адекватно, само по себе не тормозит, если не напарывается на особое поведение DPI, которое может приводит к каким-то задержкам, таймаутам, но когда проскочит в фазу “разрешено на DPI”, уже не будет тормозить
Пример недеквата - dpi-desync-any-protocol без ограничителей для nfqws, split-any-protocol без ограничителей для tpws
У меня ничего этого нет, но все равно некоторые видео подтормаживают, например при перемотке стрелками на клавиатуре есть задержка секунда - две. Другие же видео прекрасно работают. Пробовал эти два варианта, последний работает чуть лучше по ощущениям:
По TLS (TCP) вот так тестирую : curl --tls-max 1.2 -4 -o /dev/null -k --connect-to ::speedtest.selectel.ru https://test.googlevideo.com/10MB -w %{speed_download}
Причина может быть в quic. Надо по F12 смотреть, возможно шарк на предмет застреваний в quic сеансе. См тайминги пакетов
Это тоже не работает: curl --tls-max 1.2 -4 -o /dev/null -k --connect-to ::speedtest.selectel.ru ``https://test.googlevideo.com/10MB`` -w %{speed_download} % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:–:-- 0:00:19 --:–:-- 0 curl: (35) Recv failure: Connection was reset 0
@bolvan было бы полезно, если бы в zapret существовала опция применения стратегий нулевой фазы всегда независимо от --hostlist-exclude и --ipcache-hostname, потому что пробить сечение фейков с низким TTL можно лишь только модификациями TTL пакетов в начале TCP сессии(модификация SYN, ответного ACK и т.д.), а ipcache неудобен тем что zapret’y необходимо изучать адреса на протяжении всей своей работы, в итоге подключение может пройти лишь только со 2 раза.
Я вообще взял полный список айпишников гугла с bgp.tools + вторым листом сделал айпишники провайдеровских GGC - и так, если хочу попробовать нулевую фазу для видео, пользуюсь, по айписетам
Это есть, только не настолько в лоб. См выше описание как задействуется wssize для всех соединений. Дублировать логику смысла не вижу. Мультистратегии этот кейс покрывают
Корреляция чего с чем ?
Пока мы только видели попытки динамических блокировок.
Если пробежал какой-то пакет на какие-то диапазоны IP, то блокировать весь диапазон.
Или наказание юзеров. Если запустил фейки, посиди в сторонке, будет тебе везде блок
