Zapret как прокси сервер?

[denz8028]

как идея, потому что не всегда есть возможность прошить роутер, а домашний сервер 24/7 онлайн

[bol-van]

tpws умеет
nfqws работает на уровне пакетов и несовместим с прокси
если очень надо можно сделать виртуалку с запрет и скуид

[pwd491]

hyper-v. полная виртуализация. должно работать теоретически если облако не делает что-то с трафиком должен быть внешний ip инетовский

В общем, попробовал nfqws на конфиге

MODE=nfqws
NFQWS_OPT_DESYNC="--dpi-desync=split2"
NFQWS_OPT_DESYNC_HTTP=""
NFQWS_OPT_DESYNC_HTTPS=""
NFQWS_OPT_DESYNC_HTTP6=""
NFQWS_OPT_DESYNC_HTTPS6=""
NFQWS_OPT_DESYNC_QUIC="--dpi-desync=fake --dpi-desync-repeats=6"
MODE_HTTP=0
MODE_HTTPS=1
MODE_QUIC=1
MODE_FILTER=hostlist

Делаю:
curl https://manifest.googlevideo.com/100MB | tcpdump dst manifest.googlevideo.com -w /tmp/dump.pcap

[bol-van]

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

[pwd491]

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

Подскажите пожалуйтса.

Запускаю nfqws в дебаге:
/opt/zapret/nfq/nfqws --debug=1 --user=tpws --dpi-desync-fwmark=0x40000000 --qnum=200 --dpi-desync=fake split2 --dpi-desync-ttl=5 --dpi-desync-fake-http=0x00000000 --hostlist=/opt/zapret/ipset/zapret-hosts.txt.gz --hostlist=/opt/zapret/ipset/zapret-hosts-user.txt --hostlist-exclude=/opt/zapret/ipset/zapret-hosts-user-exclude.txt

Пробую:
curl -v4s instagram.com
Получаю:

packet: id=1 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=1 pass unmodified
packet: id=2 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=2 pass unmodified
packet: id=3 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=3 pass unmodified
packet: id=4 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=4 pass unmodified
packet: id=5 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=5 pass unmodified
packet: id=6 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=6 pass unmodified
packet: id=7 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.174 proto=tcp ttl=64 sport=55192 dport=443 flags=S seq=1754026636 ack_seq=0
packet: id=7 pass unmodified

Сообственно в чём заключается вопрос, судя по логам этот IP не резолвится в хостилсте, запрет не модифицирует пакеты? Стало интересно узнать, кто стоит за адрессом, это оказался instagram-p42-shv-01-hel3.fbcdn.net чей домен 2го уровня fbcdn.net.

Пробую на прямую к fbcdn.net curl'ом

packet: id=1 len=60 mark=00000000
IP4: 45.132.17.189 => 157.240.205.35 proto=tcp ttl=64 sport=60552 dport=80 flags=S seq=1969126497 ack_seq=0
packet: id=1 pass unmodified
packet: id=2 len=60 mark=00000000
IP4: 157.240.205.35 => 45.132.17.189 proto=tcp ttl=58 sport=80 dport=60552 flags=SA seq=2434097634 ack_seq=1969126498
packet: id=2 pass unmodified
packet: id=3 len=52 mark=00000000
IP4: 45.132.17.189 => 157.240.205.35 proto=tcp ttl=64 sport=60552 dport=80 flags=A seq=1969126498 ack_seq=2434097635
packet: id=3 pass unmodified
packet: id=4 len=124 mark=00000000
IP4: 45.132.17.189 => 157.240.205.35 proto=tcp ttl=64 sport=60552 dport=80 flags=AP seq=1969126498 ack_seq=2434097635
TCP: 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 48 6F 73 74 3A 20 66 62 63 64 6E 2E 6E 65 74 0D ... : GET / HTTP/1.1..Host: fbcdn.net. ...
packet contains HTTP request
req retrans : tcp seq interval 1969126498-1969126569
hostname: fbcdn.net
Checking exclude hostlist
Hostlist check for fbcdn.net : negative
Hostlist check for net : negative
Checking include hostlist
Hostlist check for fbcdn.net : positive
dpi desync src=45.132.17.189:60552 dst=157.240.205.35:80
split pos 2
sending fake request : 00 00 00 00 : ....
reinjecting original packet. len=124 len_payload=72
packet: id=4 drop
packet: id=5 len=52 mark=00000000
IP4: 45.132.17.189 => 157.240.205.35 proto=tcp ttl=64 sport=60552 dport=80 flags=AF seq=1969126570 ack_seq=2434097636
packet: id=5 pass unmodified

Почему так? Прописал напрямую в zapret-hosts-user.txt, эффекта ноль, не действущая стратегия? Без запрета curl виснет, с запретом получаю Empty reply from server.

UPD:
Пробовал instagram.com:80/443, везде эффект тот же, ощущение будто zapret не распознаёт этот домен.
Скачал к себе zapret-hosts.txt.gz, убедился что домены там есть!!! В общем если не вписывать zapret-hosts-user.txt, то домены не распознаются

[bol-van]

идут безответные syn
сайт заблочен по ip

часть адресов инсты ип блокнута
либо в хостс неблоченые ип, либо подбирать днс, чтобы выдавал неблоченые

[pwd491]

В общем, расскажу немного о результатах.

Умный в гору не пойдёт, умный гору обойдёт.
Перенастройка DNS дала свои плоды, прыгнул с 8.8.8.8 на (1.1.1.1 1.0.0.1) и появился ping. Далее всё заработало штатно, стал тестить на своей машине из под ubuntu (подключился к proxy по http/https), о чудо, все заблокированные сайты открываются в миг (instagram, facebook, twitter и т.д.), возрадовался. Пошёл на ютуб, а там googlevideo висит, нажимаю F12 вижу closed. Смотрю логи запрета, host детектит, fake шлёт.

Пробую:
curl --connect-to ::speedtest.selectel.ru https://manifest.googlevideo.com/100MB -k -o/dev/null

Получаю:
curl: (35) OpenSSL/3.0.13: error:02000068:rsa routines::bad signature

И тут, разочарованию не было предела, для интереса попробовал подключить iphone/android к proxy. Ни один заблокированный ресурс, доступный с компьютера, не доступен на телефоне. zapret детектит, squid создаёт тунели, а приложения на мобилках не открываются..

Пробую через Safari/Google/Firefox, эффект тот же, не удалось установить безопасное соединение или ERR_SSL_PROTOCOL_ERROR.

И здесь, я прошу объяснения у компететных людей.

Если я делаю на сервере curl на HTTPS:

curl -v4s https://instagram.com

То получаю:

* Host instagram.com:443 was resolved.
* IPv6: (none)
* IPv4: 57.144.112.34
*   Trying 57.144.112.34:443...
* Connected to instagram.com (57.144.112.34) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to instagram.com:443 
* Closing connection

Тогда, каким образом, я получаю доступ к этим сайтам со своей Linux машины, но не получаю с телефонов? Моё предположение, что на компьютерах используются сертификаты из системы, а вот на телефонах видимо этих сертификатов нет или они есть, но если включён proxy, то телефон всегда будет использовать сертификат proxy сервера? Простите, если вопрос кажется глупым, это лишь мои первые шаги в сети.

Для того чтобы включить поддержку HTTPS в Squid, нужно ручками переконфигурировать, пересобирать, а самое главное, раздавать всем клиентам свои сертификаты в ручном режиме, что МЕГА неудобно. Есть ли другие варианты решения этой проблемы. Заранее спасибо.

[bol-van]

не очень понял топологию этой схемы
zapret на линухе, на нем прокси, и к прокси подключаются телефоны и прочие ?
у телефонов с компом может быть разница в доступности tls 1.3
mitm в squid нужен только для кэширлвания
для проксирования без расшифровки это лишнее

все надо начинать с курл тестирования с хоста, где работат zapret
подбирать рабочую стратегию

[pwd491]

если тлс 1.3 работает, а 1.2 нет, значит дпи сечет ответ сервера у tpws нет нормальных механизмов преодоления 1.2 в такой ситуации нужен nfqws

с правилами какая-то ерунда зачем переадресовывать на tpws порт 3128 ? tpws не понимает http proxy протокол а в прозрачном режиме он вообще никакой проси протокол не понимиает tpws работает как tcp proxy и распознает http и tls, применяя к ним дурение, если указано

мне кажется надо настраивать nfqws а squid оставлять как прокси непрозрачный

Да, я тоже решил не мучаться с tpws и искать стратегию на nfqws.

Попробовал blockcheck'ом поискать TLS 1.2 HTTPS для instagram.com с 3 повторами, выдало:
ipv4 instagram.com curl_test_https_tls12 : nfqws --dpi-desync=fake,split2 --dpi-desync-ttl=1

Запустил в дебаг, пробую curl, получаю:
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to instagram.com:443

Удивительно :) Ищу дальше...

UPD:
Я заметил что использование fake всегда нарушает TLS. При этом blockcheck может выдавать (по его мнению/результатам) рабочие стратегии.
Может ли ядро системы нарушать логику работы в режиме fake ?

[pwd491]

UPD: Я заметил что использование fake всегда нарушает TLS. При этом blockcheck может выдавать (по его мнению/результатам) рабочие стратегии. Может ли ядро системы нарушать логику работы в режиме fake ?

Отвал fake был по моей глупости...

К своему стыду, запускал в ручную с таким параметром --dpi-desync=fake split2 а не --dpi-desync=fake,split2, что и приводило к * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to instagram.com:443.

Теперь fake работает отлично, доступ с TLS 1.2 к https://instagram.com есть, но на телефонах всё также молчание..

Снифф телефонного трафика показал, что к большинству поддоменов доступ есть, кроме одного star.c10r.facebook.com.

Пробую к нему curl'ом с proxy:

* Host star.c10r.facebook.com:443 was resolved.
* IPv6: 2a03:2880:f084:10d:face:b00c:0:2
* IPv4: 157.240.0.13
*   Trying 157.240.0.13:443...
* Connected to star.c10r.facebook.com (157.240.0.13) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 / prime256v1 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=Menlo Park; O=Meta Platforms, Inc.; CN=*.facebook.com
*  start date: Jun 18 00:00:00 2024 GMT
*  expire date: Sep 16 23:59:59 2024 GMT
*  subjectAltName does not match star.c10r.facebook.com
* SSL: no alternative certificate subject name matches target host name 'star.c10r.facebook.com'
* Closing connection
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'star.c10r.facebook.com'
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.

Если к нему с --insecure, то всё работает. На всякий попробовал sudo apt install ca-certificates, не помогло.

[bol-van]

star..c10r так себя ведет даже с впн
это не проблема обхода

fake без ограничителей всегда ломает tcp

[pwd491]

star..c10r так себя ведет даже с впн это не проблема обхода

fake без ограничителей всегда ломает tcp

В целом получилось обойти на телефоне всё, кроме инстаграмма, ютуб через прокси с запретом в 4к даёт 2 секунды буферизации. На инсту уже не хватает сил, попробую позже (дамп сохранил).

Потребление 96MB RAM nfqws это норма? (с использованием листов ркн), пробовал запустить два демона для HTTP и HTTPS получил oom-killed

[kagalenko-m-b]

tpws не понимает http proxy протокол

Не понятно, а как же MODE=tpws-socks?

[bol-van]

инста имеет заблоченые ип
каждый инстанс тянет свой лист
для сокращения памяти обьединять стратегии
лист в памяти занимает в несколько раз больше разжатого оригинала

[bol-van]

новый днс стал возвращать неблоченые ип
потому и завелось
эту проблему тыщу раз уже обсудили

[pwd491]

новый днс стал возвращать неблоченые ип потому и завелось эту проблему тыщу раз уже обсудили

Я понимаю, что замена ДНС решило 90% проблем, но нюансы всё ещё присутствуют..

У меня завелось всё и на всех устройствах, кроме мобильного Instagram (web морда и официальное приложение) молчат.

Посмотрел трафик iPhone при подключении к официальному приложения Instagram (трафик снял с роутера, а не с хоста где прокси стоит). Заметил, что есть какие-то отдельные UDP и QUIC пакеты, которые не попадают в прокси. Может ли быть это причиной? так как адресса там фейсбуковские и летят с ип айфона, но уходят не в прокси а напрямую в интернет.

Вот наглядно:

• 192.168.1.224 iPhone
• 45.132.17.189 HTTP Proxy на VDS

[bol-van]

прокси автоматом исключает куик
только tcp
если приложение лезет по куик даже с прокси, то это недоработка приложения
если к тому же отсутствие куик при использовании прокси фатально, то это фатальная недоработка
значит поддержка прокси сломана

прокси открытый через инет не есть хорошо
легко заблочить внутри прокси

[pwd491]

прокси автоматом исключает куик

только tcp

если приложение лезет по куик даже с прокси, то это недоработка приложения

если к тому же отсутствие куик при использовании прокси фатально, то это фатальная недоработка

значит поддержка прокси сломана

прокси открытый через инет не есть хорошо

легко заблочить внутри прокси

Значит, фактически я никак не смогу заставить приложение отказаться от quic . Непрозрачный Прокси на Squid с фильтрацией по IP (только конкретные айпи пропускаются, остальные резет), что здесь могут внутри сломать? Может в будущем доделаю авторизацию kibernetiss, но без мобильной инсты об этом думать рано

На этом моменте думаю мне стоит рассмотреть shadowsocks

[bol-van]

открытый прокси легко сечется дпи
если даже они не блочат, то легко могут

проверить в куик проблема или нет можно через впн
если через впн работает, а через впн с блокировкой куик нет, то это проблема приложения

[pwd491]

Для тех, кто захочет сотворить zapret на VDS.

Первое, на что вы должны обратить внимание, это тип виртуализации, который применяет провайдер к серверам на своём облаке. Например, RuVDS который я использую, применяет Hyper-V, то есть полную виртуализацию. На полной виртуализации у вас заработает nfqws, что очень важно, так как большинство стратегий дурения выполнимы только под этим демоном.

Второе, это в каком количестве и где расположены дата-центры провайдера. Мой провайдер, использует множество различных ДЦ по Европе и Азии. Система балансировки странно определяет за каким ДЦ вас закрепить и если вам не повезёт, как не повезло мне, то вы будете закреплены за Саудовской Аравией и смысл в как таковом VPN или Proxy больше не будет, так как задержка станет слишком высокая, а комфорт сети опустится на уровень 2007 года. Из моих личных рекомендаций, это TimeWeb, ДЦ расположены в России и Казахстане.

Если Прокси:

Ставится Squid, корректно заработал на nfqws. Некоторые приложения на смартфонах игнорируют настройки системного прокси, засылая пакеты напрямую, как у меня было в случае с Instagram. Поэтому, если сильно не хотите мучаться, то этот вариант не для вас.

Если VPN:

Ставится WireGuard. Есть клиенты под iPhone/Android/MacOS/Windows/Linux, если роутер более менее свежий, то подключите и на него. nfqws и полёт отличный, tpws даже не пробовал. Для того, чтобы заработал nfqws, ставьте zapret, ищите подходящий DNS (у меня Yandex DNS) для того чтобы обойти блокировки ресурсов по IP, затем идёте в blockcheck.sh и пробуете искать туда, куда вам надо. В конце концов вам выдаст стратегии, который нужно будет применить в конфигурации. Я рекомендую делать /opt/zapret/blockcheck.sh | tee /tmp/blockcheck.txt. По своим наблюдениям скажу что, fake помогает обойти большинство заблокированных ресурсов, а для обхода замедления YouTube хватит и split2. Ещё также хочу сказать про листы РКН, если вы планируете определять стартегии на каждый протокол, то будьте готовы, что вам понадобится много RAM, моей системной конфигурации в размере 0.5 ram, хватает для одной общей стратегии, при попытке разделить на протоколы случается OOM KILLED.

Для того, чтобы направить трафик на nfqws, в конфигурации укажите:

IFACE_LAN=wg0
IFACE_WAN=eth0

Далее можете запустить в режиме debug и убедиться что трафик приходит. Например:

/opt/zapret/nfq/nfqws --debug=1 --user=tpws --dpi-desync-fwmark=0x40000000 --qnum=200 --dpi-desync=fake,split2 --dpi-desync-fooling=datanoack --wssize 1:6 --hostlist=/opt/zapret/ipset/zapret-hosts.txt.gz --hostlist=/opt/zapret/ipset/zapret-hosts-user.txt --hostlist-exclude=/opt/zapret/ipset/zapret-hosts-user-exclude.txt

Остаётся только настроить WireGuard, гайдов по тому как поставить сервер и как настроить клиент в интернете полно. Ну и если кому интересно, то вот моя конфигурация:

MODE=nfqws
MODE_HTTP=1
MODE_HTTP_KEEPALIVE=1
MODE_HTTPS=1
MODE_QUIC=1
MODE_FILTER=hostlist
NFQWS_OPT_DESYNC="--dpi-desync=fake --dpi-desync-ttl=0 --dpi-desync-ttl6=0 --dpi-desync-fooling=badsum"

[Interface]
PrivateKey = 000
Address = 10.0.0.1/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820

[Peer]
PublicKey = 000
AllowedIPs = 10.0.0.2/32

nonexistent.domain
youtube.com
youtu.be
ggpht.com
ytimg.com
i9.ytimg.com
yt3.ggpht.com
l.google.com
play.google.com
youtubei.googleapis.com
wide-youtube.l.google.com
nhacmp3youtube.com
googleusercontent.com
googleapis.com
googlevideo.com
1e100.net
instagram.com
cdninstagram.com
static.cdninstagram.com
edge-chat.instagram.com
scontent.cdninstagram.com
instagram.c10r.instagram.com
content-arn2-1.cdninstagram.com
facebook.com
xx.fbcdn.net
fbsbx.com
twimg.com
x.com
twitter.com
rutracker.org
rutracker.cc
rutrk.org
medium.com

[pwd491]

не верю, что листы ркн не влезут в 0.5 гб рам обьем памяти на инстанс примерно в 3-4 раза больше разжатого листа может быть 20 мб на инстанс. вряд ли сильно больше проблемы могут быть при загрузке ип листов в нфтаблес своп может помочь и чистка от ненужного софта по умолчанию от хостера

Возможно вы правы. Стоит Ubuntu 24 Server Minimized, там даже vim'a нет по умолчанию. Из коробки система кушает около ~150MB, не знаю много это или мало. nfqws на общей стратегии в пике кушает 90MB. В конфигурации 500MB RAM а по факту 450MB из которых 150MB съедает система, 400 - 150 = 300MB, в теории на три протокола может и влезет.

Назрел такой вопрос. Насколько сильно метод фильтрации ipset выйгрывает по скорости и по объёму потребления в работе у hostlist и autohostlist? Какому из методов вы сами отдаёте предпочтение? Должно быть без резолвинга доменов скорость работы должна значительно увеличиться?

[bol-van]

autohostlist ест ровно в обьеме аутолиста и юзерлиста
только от обьема листов зависит
ипсеты не спасают от прыгающих ип на цдн
там надо делать ипсет хук и скриптом загонять целые АСки

[trinibi01]

Если Прокси:

Ставится Squid, корректно заработал на nfqws. Некоторые приложения на смартфонах игнорируют настройки системного прокси, засылая пакеты напрямую, как у меня было в случае с Instagram. Поэтому, если сильно не хотите мучаться, то этот вариант не для вас.

Вы могли бы написать краткую инструкцию как настроить на режим прокси? Хочу установить в lxc контейнер. Прокси без проблем настроил. А с zapretom не смог разрбраться.

[kagalenko-m-b]

Если Прокси:
Ставится Squid, корректно заработал на nfqws. Некоторые приложения на смартфонах игнорируют настройки системного прокси, засылая пакеты напрямую, как у меня было в случае с Instagram. Поэтому, если сильно не хотите мучаться, то этот вариант не для вас.

Вы могли бы написать краткую инструкцию как настроить на режим прокси? Хочу установить в lxc контейнер. Прокси без проблем настроил. А с zapretom не смог разрбраться.

Присоединяюсь к просьбе.

[jastden]

Присоединяюсь к просьбе.