Спасибо Вам огромное за помощь. Все работает, сайты открываются. Замечательный скрипт.
* SUMMARY
ipv4 instagram.com curl_test_https_tls12 : tpws not working
ipv4 instagram.com curl_test_https_tls12 : nfqws not working
ipv4 instagram.com curl_test_https_tls13 : tpws not working
ipv4 instagram.com curl_test_https_tls13 : nfqws not working
не то чтобы он мне сильно нужон, просто интересно как такойе возможно, другие сайты открывает норм
а может быть такойе что например дпи оно пробивает но сам ихний веб-сервер дропает видоизменённые несоответствующие не одному стандарту пакеты?
У таких сайтов обычно прыгающие IP, и часть из них может быть заблокирована по IP
У меня норм обходит
Заметил интересную особенность, сайт windscribe.com на 99% провайдеров не имеет рабочей стратегии обхода блокировки. Блокировки по ip нет нигде, но стратегию все равно найти не удалось.
Заработало только на AS12695 DINET-AS, причем для всех заблокированных сайтов достаточно обычного fake на TCP TLS 1.2, а для windscribe.com нужен
–dpi-desync=fake,split2 --dpi-desync-split-pos=1
И заработало на NAT64 мобильного мегафона через fake,split2. На том же мегафоне без NAT64 стратегии обхода нет
Как выше описал, на магафоне NAT64 и небольшом провайдере в Москве zapret срабатывает на windcribe.com, на остальных провайдерах где тестировал - нет
Видимо блок по v4 именно на порт 443 на большинстве провайдеров. Хотя просто пинги до сайта ходят. Если необходимо могу поднять ВПН и дать Вам временный доступ для теста к этой точке которую выше описывал (AS12695 DINET-AS) 85.192.51.Х
блокируется по ip только порт 443
на 80 http работает даже без обхода
del
Добрый день.
Настроил на роутере keenetic zapret c nfqws и wireguard сервер
Нужно чтобы через zapret проходил только трафик с wireguard
Откажитесь от скриптов, сделайте все руками
а через /opt/zapret/init.d/sysv/custom никак?
Можно через custom script
Переписать логику nfqws и добавить фильтр -s 192.168.5.0/24 (подсеть wireguard)
Можно взять за основу это, только избавиться от tpws и заменить его на nfqws. nftables можно не писать.
А как. Зайти. Через Google Chrome По http Я пытался. Ну что-то не получается Автоматом. Заходит. По https
К слову. Я недавно проверял возможность запутыванию с помощью TFO. Если засунуть запрос в SYN, то можно пробить некоторые DPI, однако ТСПУ (под ним имею ввиду то, что замораживает соединение, даже если пробит первый DPI), может собрать такой запрос и заблокировать, но и он пробивается, если размер данных в SYN < 3 байт, притом split на тех же позициях не работает. Похоже, что он либо учитывает расширение tfo, либо грубо сканирует все первые пакеты, размер которых превышает некоторое число.
Сплит через TFO может работать только на серверах, поддерживающих TFO. А чтобы это узнать, придется отправить тестовый запрос, и если нет, то придется заново переподключаться, держа при этом клиента на связи
Действительно, я тоже замечал замораживание на http, но не на https. Под замораживанием я понимаю такое состояние, когда DPI в процессе своей грязной работы задерживает пакеты и правит sequence numbers, и в случае десинхронизации соединение ломается. Обычно это видно на disorder. Зависание. syndata так же может вызывать слом. На некоторых провайдерах норм, на других ломается.
На https TFO не пробовали ?
Смотря на результат, мы видим работу произвольного количества DPI на пути. Обычно их не один там, и разные могут вести себя по-разному
Да, а серверов поддерживающих TFO не так уж и много, но rutracker, например, поддерживает.
Не придется, ядро делает это прозрачно. Если у ядра есть сохранённый cookie, то он отправит данные в первом SYN, если же нет, то он отправит обычный SYN с расширением TFO, для получения первого cookie от сайта. Затем просто отправит запрос после рукопожатия. Если сервер прислал в ответ TFO, то впредь данные ему будут отправляться в первом SYN.
Как раз на нем и пробовал (несколько недель назад у меня перестал блокироваться HTTP на всех DPI). На обычных сайтах замораживания не было, только на заблокированных. Т.е. DPI умеет собирать такие запросы при условии, что полезной нагрузки > 2 байт.
Вот это и вводит неопределенность. Нельзя сделать обычными средствами так, чтобы всегда были данные в SYN. Или можно, сделав предварительный конект. Но можно ли узнать потом действительно ли сервер поддерживает TFO ?
Прозрачность удобна, но для наших целей засунуть данные в SYN может быть не очень удобна
Гуглится вот что :
The case that you are sure fast open was used is when you have a non-blocking socket, you already have a fast open cookie and sendto() does not return EINPROGRESS:
For non-blocking socket, it returns the number of bytes queued (and transmitted in the SYN-data packet) if cookie is available. If cookie is not available, it transmits a data-less SYN packet with Fast Open cookie request option and returns -EINPROGRESS like connect().
Если имеется ввиду и случаи, когда на сервере нет TFO, то похоже, что это невозможно. В Linux (начиная вроде с 4.11) есть такая опция - TCP_FASTOPEN_CONNECT. Если cookie у ядра есть, то connect мнгновенно вернет 0, если нет, то EINPROGRESS. Т.е. можно сделать предварительное подключение, не отправляя данные.
Возможно ли как-нибудь посредством zapretа реализовать блокировку quic (блокировка от провайдера то есть, то нет)? Максимально криво работает и единственным способом избежать проблем становится принудительное отключение quic в браузерах. Но хотелось бы найти способ заблокировать quic на домашних устройствах полностью
Закройте порт udp 443 на выход из домашней сети и никакого quic не будет