search

bol-van / zapret

DPI bypass multi platform
5.85k stars 513 forks source link

Обход не работает в зависимости от платформы клиента #170

Closed f1amy closed 7 months ago

f1amy commented 7 months ago

Здравствуйте, не получается понять почему обход блокировок некоторых сайтов работает на Windows, но не работает на Android/iPadOS устройствах.

Применяемая стратегия для http, https и quic: nfqws --dpi-desync=fake,disorder --dpi-desync-ttl=2 --dpi-desync-fooling=badsum,md5sig --wssize 1:6

Сетап:

На всех Windows машинах открываются все интересующие меня сайты. На устройствах Android и iPadOS часть заблокированных сайтов не открываются никак. Падают ошибки SSL, ERR_CONNECTION_RESET и ERR_QUIC_PROTOCOL_ERROR.

При запуске blockcheck.sh для проблемных сайтов стратегии для tls1.2 и 1.3 скрипт найти не может. В 100% случаев ошибка curl: (35) Recv failure: Connection reset by peer.

P.S. Многократно благодарен за работу над проектом

bol-van commented 7 months ago

Некоторые ресурсы заблокированы по IP Старые мобильные ос не умеют tls 1.3 и гонят 1.2, а современные броузеры на ПК все умеют 1.3. В этом может быть и разница

Тестировать надо через curl, скомпиленным с openssl (не виндовс по умолчанию с schannel, не openwrt с mbedtls) с ключами --tlsv1.2 --tls-max 1.2 В новых версиях openwrt тестирование на 1.3 невозможно , потому что libcurl скомпилен с mbedtls, который не поддерживает 1.3.

f1amy commented 7 months ago

Оба мобильных устройства должны поддерживать tls 1.3, они не старые, а браузеры самой последней версии. Я думаю что может быть какая то другая фича есть в браузере на десктопе, но нет на мобильных, может быть ECH/ESNI? Но с другой стороны без запущенного zapret на десктопе ресурсы, с которыми проблема на мобилках не открываются.

curl проверю.

f1amy commented 7 months ago

Curl с openssl с разными версиями tls разницу не показывает, проверял с ubuntu/wsl

$ curl -X GET https://nhentai.net --tlsv1.2 --tls-max 1.2
curl: (35) OpenSSL SSL_connect: Соединение разорвано другой стороной in connection to nhentai.net:443
$ curl -X GET https://nhentai.net --tlsv1.3 --tls-max 1.3
curl: (35) OpenSSL SSL_connect: Соединение разорвано другой стороной in connection to nhentai.net:443
$ curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.16
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

Также проверил поддержку tls 1.3 на роутере, работает:

~ # curl -X GET--tlsv1.3 https://vk.com
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>kittenx</center>
</body>
</html>
~ # curl -V
curl 8.2.1 (aarch64-openwrt-linux-gnu) libcurl/8.2.1 OpenSSL/3.0.10 zlib/1.2.13
Release-Date: 2023-07-26
Protocols: file ftp ftps http https imap imaps mqtt pop3 pop3s rtsp smtp smtps tftp
Features: alt-svc HSTS HTTPS-proxy IPv6 Largefile libz SSL threadsafe
bol-van commented 7 months ago

Я думаю что может быть какая то другая фича есть в браузере на десктопе, но нет на мобильных, может быть ECH/ESNI?

DNS провайдером не подменяется ? Современные броузеры по умолчанию используют DoH. Если нет, то надо смотреть дампы SSL трафика с обоих устройств

bol-van commented 7 months ago

Еще бывает такая штука, что РКН банит по IP некоторые адреса с cloudflare. Хост может ресолвится в разные (прыгающие) IP. И когда не повезло, попало на ipban, то не будет работать. А иначе будет

bol-van commented 7 months ago

Можно попробовать переназначить IP curl -v4 --resolve nhentai.net:443:1.1.1.1 https://nhentai.net чтобы точно оно секло только по SNI, не по IP

f1amy commented 7 months ago

DNS на роутере настроен использовать только DoH от гугл и cloudflare, дампы SSL трафика попробую снять.

Варианта с прыгающими IP быть не может, не было такого чтобы на десктопе не открывалось, а на мобилках открылось хотя бы раз. Плюс попыток перепробовал уже много.

curl -v4 --resolve nhentai.net:443:1.1.1.1 https://nhentai.net
* Added nhentai.net:443:1.1.1.1 to DNS cache
* Hostname nhentai.net was found in DNS cache
*   Trying 1.1.1.1:443...
* Connected to nhentai.net (1.1.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
*  start date: Apr 17 00:00:00 2023 GMT
*  expire date: Apr 16 23:59:59 2024 GMT
*  subjectAltName: host "nhentai.net" matched cert's "nhentai.net"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x558429fb0e90)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: nhentai.net
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 403
< date: Thu, 01 Feb 2024 08:17:02 GMT
< content-type: text/plain; charset=UTF-8
< content-length: 16
< x-frame-options: SAMEORIGIN
< referrer-policy: same-origin
< cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< expires: Thu, 01 Jan 1970 00:00:01 GMT
< server: cloudflare
< cf-ray: 84e8c17699e53a89-DME
<
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host nhentai.net left intact
error code: 1034
bol-van commented 7 months ago

error code: 1034

это как раз означает, что на 1.1.1.1 сброса не было а если на другом идет сброс, то значит по IP забанено

попробуйте взять оригинальный IP домена и попрыгать вокруг него младшим октетом

f1amy commented 7 months ago

Не совсем понимаю что это означает. Десктопы сохранили в DNS кеше IP адрес ресурса, который не заблокирован по IP, и по этому работает, а на мобильных устройствах не повезло?

Попробовал сделать резолв также через гугловский DNS с роутера:

~ # curl -v4 --resolve nhentai.net:443:8.8.8.8 https://nhentai.net
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL: no alternative certificate subject name matches target host name 'nhentai.net'
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'nhentai.net'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

С компа (???):

curl -v4 --resolve nhentai.net:443:8.8.8.8 https://nhentai.net
* Added nhentai.net:443:8.8.8.8 to DNS cache
* Hostname nhentai.net was found in DNS cache
*   Trying 8.8.8.8:443...
* connect to 8.8.8.8 port 443 failed: Нет маршрута до узла
* Failed to connect to nhentai.net port 443 after 2 ms: Нет маршрута до узла
* Closing connection 0
curl: (7) Failed to connect to nhentai.net port 443 after 2 ms: Нет маршрута до узла

Такое ощущение что cloudflare или google dns заблокированы, в логах роутера также вижу постоянные ошибки DoH с cloudflare:

"https://cloudflare-dns.com/dns-query": curl error message: Connection timed out after 3000 milliseconds

Помимо DoH на роутере также настроены DoT сервера, от тех же гугл и cloudflare

bol-van commented 7 months ago

вы не поняли значение ключа --resolve. он не задает DNS сервер, а задает ресолвинг домена на конкретном порту в конкретный IP. то есть обход DNS, прямое указание, что nhentai находится по такому-то IP

берете tcpdump на роутере. заходите с телефона и с компа. запоминаете IP. вписываете по очереди эти IP в ключ resolve курла. сравниваете эффект

на разных устройствах могут быть разные doh/dot ресолверы, которые выдают различные IP

f1amy commented 7 months ago

Проанализировал tcpdump при помощи wireshark. Не на 100% уверен в том что скажу.

Снял пакеты с мобильного устройства Android в браузере хром и ПК Windows для двух сайтов с которым проблемы.

Разницы в том на какие IP приходят запросы нет. Есть разница в том, по какому протоколу проходит TLC Client Hello, с ПК запрос сразу идет с TLCv1.3, когда с мобильного устройства с TLCv1.

Мобильное устройство после чего получает ответ от (как я понимаю DPI, хотя IP от того же сайта) TCP RST пакет.

Манипулируя версией TLS в curl успешно запрос послать не получается:

curl --tlsv1.3 --tls-max 1.3 -v4 --resolve nhentai.net:443:172.67.159.231 https://nhentai.net
* Added nhentai.net:443:172.67.159.231 to DNS cache
* Hostname nhentai.net was found in DNS cache
*   Trying 172.67.159.231:443...
* Connected to nhentai.net (172.67.159.231) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Соединение разорвано другой стороной in connection to nhentai.net:443
* Closing connection 0
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, decode error (562):
curl: (35) OpenSSL SSL_connect: Соединение разорвано другой стороной in connection to nhentai.net:443
bol-van commented 7 months ago

curl --tlsv1.3 --tls-max 1.3 -v4 --resolve nhentai.net:443:172.67.159.231 https://nhentai.net curl: (35) OpenSSL SSL_connect: Соединение разорвано другой стороной in connection to nhentai.net:443

zapret при этом запущен ? игра последним октетом IP адреса что-то меняет ? работало же 1.1.1.1

f1amy commented 7 months ago

zapret запущен, игра с ip адресом дала результат на 172.67.159.255, на 172.67.159.1, 172.67.159.50, 172.67.159.100, 172.67.159.150, 172.67.159.200 ответ такой же как при оригинальном IP, т.е. разрыв соединения.

На 172.67.159.255 отвечает cloudflare страничкой. На 1.1.1.1 также работает.

При тесте блокировок я видел как минимум две разные заглушки, от провайдера и от mts, т.е. полагаю что балансировка DPI какая то есть.

В браузере на винде сайт по прежнему открывается без проблем. ip = 172.67.159.231, т.е. такой же

bol-van commented 7 months ago

это очень похоже на зоопарк DPI, часть из которых может не пробиваться при определенных условиях гадать можно долго без возможности воспроизвести у себя

мы выяснили, что некий DPI из зоопарка реагирует на некоторые IP адреса cloudflare и по особому что-то там проверяет, но его проверка почему-то не срабатывает на запросах от десктопных броузеров (гадать почему)

не знаю. если дадите VPN доступ без zapret, могу посмотреть, а так гадать смысла особого не вижу

f1amy commented 7 months ago

Можем попробовать. На настройку vpn потребуется время, open vpn подойдет? Ну и для реквов перейдем, например, в телегу?

bol-van commented 7 months ago

https://rutracker.org/forum/viewtopic.php?t=5171734\

на рутрекере есть приватные месаджи, тут нет

f1amy commented 7 months ago

@bol-van прошу прощения за задержку. Написал в личку kx77, понял что это вы.

f1amy commented 7 months ago

@bol-van отправил реквизиты, пожалуйста отпишитесь тут, поскольку без zapret я не могу открыть rutracker.org

bol-van commented 7 months ago

ikev2 плохой вариант для linux. его сложно настраивать, nfqws почему-то лепит ошибки при отправке пакетов через raw sockets под ipsec. надо поднимать xfrm/vti, может так сработает но это все бестолковая трата кучи времени ни на что

openvpn лучший вариант

f1amy commented 7 months ago

Понял, настрою OpenVPN. Было проще всего настроить IKEv2

f1amy commented 7 months ago

@bol-van отправил реквизиты, пожалуйста проверьте

bol-van commented 7 months ago

Не хватает секции CA в конфиг файле. + еще пришлось править косяки Вообщем либо делайте нормально, чтобы я не тратил время на хаки-выверты для исправления ваших косяков, либо я на это просто забью

f1amy commented 7 months ago

Прошу прощения, это первый раз как я настраивал open vpn. Конфигурацию я проверял на Android с официальном клиентом, по этому не знал что нужно CA.

Смотрел следующий гайд для настройки https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst.

Отправил новый конфиг с CA без peer-fingerprint, также проверил что он работает Zapret отключен

bol-van commented 7 months ago

У вас большинство блокировок обходятся с такой стратегией : --dpi-desync=fake,split2 --dpi-desync-ttl=3 (TTL через VPN, значит с роутера будет 2) Все, что не обходится таким образом, заблокировано по IP адресу. На cloudflare заблокированы некоторые IP и диапазоны IP. Внутри них сброс идет на любой домен. nhentai.net - один из таких вариантов. Если после обхода zapret направить nhentai на любой IP адрес вне блокированного диапазона, то он работает. Если взять cloudflare и немного попрыгать по его разным диапазонам, то nhentai прекрасно работает. Блокировки по IP адресу обойти невозможно, поэтому без стороннего хоста ситуацию не поправить (см ipban и policy routing). Однако, отдельные сайты на cloudflare типа хентая можно обойти просто добавив незаблокированный IP в hosts на клиентской системе или на роутере (если прошивка позволяет, openwrt - да)

$ ps xau | grep nfqws
tpws       17639  0.0  0.0   3028  2080 ?        S    11:40   0:00 /opt/zapret/nfq/nfqws --user=tpws --dpi-desync-fwmark=0x40000000 --qnum=200 --dpi-desync=fake,split2 --dpi-desync-ttl=3

$ curl -I4k --resolve nhentai.net:443:188.114.97.1 https://nhentai.net
HTTP/2 403 
date: Thu, 08 Feb 2024 08:41:52 GMT
..........

$ curl -I4k  https://nhentai.net
curl: (35) Recv failure: Connection reset by peer

$ sudo systemctl stop zapret

$ curl -I4k --resolve nhentai.net:443:188.114.97.1 https://nhentai.net
curl: (35) Recv failure: Connection reset by peer
bol-van commented 7 months ago

Сюда следует добавить, что некоторые блокировщики более, а некоторые менее строго подходят к блокировкам. У меня, например, на нескольких провайдерах нет такого блока по IP на nhentai. Я беру DNS с вашего подключения, и он работает с zapret :+1: 

 $ curl -I4k --resolve nhentai.net:443:172.67.159.231 https://nhentai.net
 HTTP/2 403

Особенно когда много ТСПУ усердно пытаются нас оградить от неправославных материалов, какой-нибудь окажется более дотошный. Или еще со старых времен осталась провайдерская отсебятина

bol-van commented 7 months ago

Еще 1 момент. На некоторых диапазонах cloudflare видимо они изобрели какую-то защиту от "странных запросов" Если zapret убрать, то фильтрация идет нормально.

$ sudo systemctl stop zapret
$ curl -4k --resolve bred.com:443:172.67.159.231 https://bred.com
curl: (35) OpenSSL/3.0.9: error:0A000410:SSL routines::sslv3 alert handshake failure
(ЭТО ОШИБКА СО СТОРОНЫ CLOUDFLARE, НЕ БЛОКИРАТОР)
$ curl -4k --resolve nhentai.net:443:172.67.159.231 https://nhentai.net
curl: (35) Recv failure: Connection reset by peer
$ curl -4k --resolve rutracker.org:443:172.67.159.231 https://rutracker.org
curl: (35) Recv failure: Connection reset by peer

Однако, при любой фрагментации запроса идет сброс вне зависимости от домена :

$ ps xau | grep nfqws
tpws       21245  0.0  0.0   3028  2080 ?        S    12:07   0:00 /opt/zapret/nfq/nfqws --user=tpws --dpi-desync-fwmark=0x40000000 --qnum=200 --dpi-desync=split2

$ curl -4k --resolve kremlin.ru:443:172.67.159.231 https://kremlin.ru
curl: (35) Recv failure: Connection reset by peer

$ curl -4k --resolve lenta.ru:443:172.67.159.231 https://lenta.ru
curl: (35) Recv failure: Connection reset by peer

Отсюда можно сделать какой вывод. У них есть особый более строгий фильтр для CDN типа cloudflare, который zapret пробить не в состоянии. По той причине, что он сечет попытки обхода (например, через split запроса) и полностью блокирует IP в этом случае Я бы в таком случае занес в ipban весь cloudflare, например полностью весь диапазон ASN, который легко получить через whois. Но нужен policy routing, свой хост, и заводская прошивка на роутере не подойдет Либо менять IP на те адреса cloudflare, которые не подпадают под блок строгой фильтрации с защитой от обхода (как показывает опыт, не весь cloudflare так заблокирован)

/etc/hosts 104.21.97.11 nhentai.net 104.21.97.11 rutracker.org

помогает с zapret-ом обойти блокировку

Как вариант, можно нащупать "строгие" диапазоны cloudflare и завернуть с них трафик через iptables на "мягкий" IP. Но тут надо будет тестировать хорошо не поломало ли это что-то, и в будущем IP могут поменяться, что может поломать тему

bol-van commented 7 months ago

На эмуляторе android установил Iron Browser (вариант chromium). В нем нормально открывается rutracker и nhentai, если есть zapret и изменен hosts

f1amy commented 7 months ago

Спасибо вам большое! Буду вникать и пробовать вариант с hosts.

Остался вопрос, получилось ли понять почему обход работает без проблем в браузере на windows с zapret?

bol-van commented 7 months ago

Обнаружилась еще одна дырка, которая все упрощает.

--dpi-desync-split-pos=1

Если режется так, что в первом пакете только 1 байт, а во 2-м - все остальное, то "строгость" не срабатывает

bol-van commented 7 months ago

Остался вопрос, получилось ли понять почему обход работает без проблем в браузере на windows с zapret?

Скорее всего это просто кэш. У меня под linux и в фоксе, и в хромиуме ресет, если zapret не помогает

bol-van commented 7 months ago

такая стратегия у меня обходит и http, и https на роутере ттл=6

--dpi-desync=fake,split2 --dpi-desync-ttl=7 --dpi-desync-fooling=md5sig --dpi-desync-split-pos=1 --hostspell=hoSt

обнаружился 3-й DPI по пути, на этот раз от ростелекома. он срабатывает 50/50, очевидно лоад балансинг по разным каналам видно, что ТСПУ стоят у магистралов потому пришлось увеличить TTL, чтобы он достигал и ростелековского DPI md5sig - на всякий случай, чтобы не порушить близкие сайты

bol-van commented 7 months ago

В blockcheck.sh добавил вариант с split-pos=1 Теперь он находит стратегии на этом провайдере без манипуляций из коробки

f1amy commented 7 months ago

Проверил --dpi-desync=fake,split2 --dpi-desync-ttl=6 --dpi-desync-fooling=md5sig --dpi-desync-split-pos=1 --hostspell=hoSt, работает везде, спасибо!

Насколько я знаю, мой провайдер использует инфраструктуру у Ростелекома как раз, по этому не удивительно. Хотел предложить помощь в улучшении blockcheck, но вы уже это сделали)

Я вам очень благодарен!

f1amy commented 7 months ago

Жаль конечно что не удалось определить причину по которой на винде обход работал и без split-pos=1, потому что я не верю в то что это мог быть какой то кеш, так как это работало на трех ПК на разных браузерах, chrome, edge, firefox.

f1amy commented 7 months ago

Спасибо вам еще раз!