zapret
v69.8
Zapret은 무료이며 오픈 소스입니다. 리소스에서 Zapret을 다운로드하도록 강요하는 사람은 링크, 비디오, 파일을 삭제하고 저작권의 이러한 요구 사항을 정당화해야하며 자체가 라이센스를 위반해야합니다.
자율 대응 DPI. 타사 서버를 연결할 필요가 없습니다. 예를 들어 VPN을 차단하기위한 목적으로 TCP 및 UDP 프로토콜의 자연 분석 인 HTTP (S)의 잠금 또는 감속을 우회하는 데 도움이 될 수 있습니다.
이 프로젝트는 주로 OpenWrt에서 작동하는 라우터가 저하 임베드 장치를 목표로합니다. 기존 Linux 시스템, FreeBSD, OpenBSD, 부분적으로 MACOS가 지원됩니다. 경우에 따라 독립적 인 솔루션을 다양한 펌웨어로 조이고 나사가 가능합니다.
대부분의 기능은 Windows에서 작동합니다.
가장 간단한 경우 수동 DPI를 다루고 있습니다. 패시브 DPI는 스트림에서 트래픽을 읽고 패키지를 주입 할 수 있지만 전달 패키지를 차단할 수는 없습니다. 요청이 "불량"인 경우, RST 패키지의 수동 DPI 주입은 선택적으로 HTTP 리디렉션 패키지로 보충합니다. 가짜 패키지가 클라이언트에 대해서만 주입 된 경우,이 경우 각 제공자에 대해 개별적으로 선택 해야하는 특정 조건에 따라 RST 낙하 및/또는 플러그로 리디렉션 할 수 있습니다. 그래서 우리는 방아쇠의 운영 결과를 해결합니다. 수동 DPI가 서버를 포함한 RST 패키지를 지시하면 아무것도 할 수 없습니다. 당신의 임무는 트리거의 트리거 트리거를 방지하는 것입니다. iptables만으로는 안됩니다. 이 프로젝트는 정확하게 금지를 방지하고 그 결과를 제거하지 않기위한 것입니다.
활성 DPI는 와이어의 절개에 배치되며 TCP 흐름을 인식하고 흐름에 속하는 패키지를 차단하는 것을 포함하여 임의의 기준에 따라 패키지를 떨어 뜨릴 수 있습니다.
금지 금지를위한 방아쇠를 방지하는 방법은 무엇입니까? DPI가 중요하지 않은 것을 보내고 요청을 인식하고 그들의 차단을 인식하기위한 알고리즘이 그를 깨뜨립니다.
일부 DPI는 HTTP 요청이 TCP 세그먼트로 나뉘어있는 경우 인식 할 수 없습니다. 예를 들어, 유형 GET / HTTP/1.1rnHost: kinozal.tv...... 우리는 두 부분을 보냅니다. 먼저 GET , / HTTP/1.1rnHost: kinozal.tv..... 헤더가 다른 레지스터로 작성 Host: 때 다른 DPI 스터블 : 호스트 : host: . 어떤 곳에서는 방법 : GET / = GET / 호스트 이름의 끝에서 포인트를 추가하는 방법 : Host: kinozal.tv.
패키지 수준에서 DPI를 극복하기위한 더 고급 마법도 있습니다.
DPI에 대한 자세한 내용 :
https://habr.com/en/post/335436 또는 https://web.archive.org/web/2023033123644/https://habr.com/en/post/335436/
https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf
이전에는 범용 TSPU 시스템이 도입되기 전에 제공자를위한 다양한 DPI 동물원이 사용되었습니다. 일부는 활동적이고 수동적이었습니다. 이제 간단한 iptables의 시간이 마침내 사라졌습니다. 모든 곳에는 능동적 인 DPI TSPU가 있지만 일부 지역에서는 동물원의 추가 오래된 DPI가 불필요하게 남아있을 수 있습니다. 이 경우 여러 DPI를 한 번에 가야합니다. 점점 더 맡겨진 자물쇠가되고 있으며, 당신은 무언가의 접근 불가능한 사실에 의해서만 배울 것입니다. 이것은 목록에 없습니다. 일부 IP 주소의 클로트는 사용됩니다 (자율 우회는 불가능) 및 프로토콜 (VPN)이 사용됩니다. 일부 IP 범위는 세분화를 통해 속임수를 인식하는보다 엄격한 필터를 사용합니다. 이런 식으로 DPI를 속이려고하는 일부 서비스 때문입니다.
요컨대, 옵션은 다음 체계에 따라 분류 될 수 있습니다.
옵션 2 및 3의 경우 TPW 및 NFQWS 프로그램이 각각 구현됩니다. 그들이 작동하기 위해서는 원하는 매개 변수로 실행하고 iptables 또는 nftabals로 특정 트래픽을 리디렉션해야합니다.
이 프로그램은 패키지 수정 자 및 NFqueue 큐 핸들러입니다. BSD 시스템의 경우 동일한 소스에서 수집 된 적응 된 버전 인 DVTW가 있습니다 (BSD 문서 참조).
@<config_file>|$<config_file> ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются.
--debug=0|1 ; 1=выводить отладочные сообщения
--dry-run ; проверить опции командной строки и выйти. код 0 - успешная проверка.
--comment ; любой текст (игнорируется)
--daemon ; демонизировать прогу
--pidfile=<file> ; сохранить PID в файл
--user=<username> ; менять uid процесса
--uid=uid[:gid] ; менять uid процесса
--qnum=N ; номер очереди N
--bind-fix4 ; пытаться решить проблему неверного выбора исходящего интерфейса для сгенерированных ipv4 пакетов
--bind-fix6 ; пытаться решить проблему неверного выбора исходящего интерфейса для сгенерированных ipv6 пакетов
--wsize=<winsize>[:<scale_factor>] ; менять tcp window size на указанный размер в SYN,ACK. если не задан scale_factor, то он не меняется (устарело !)
--wssize=<winsize>[:<scale_factor>] ; менять tcp window size на указанный размер в исходящих пакетах. scale_factor по умолчанию 0. (см. conntrack !)
--wssize-cutoff=[n|d|s]N ; изменять server window size в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N
--ctrack-timeouts=S:E:F[:U] ; таймауты внутреннего conntrack в состояниях SYN, ESTABLISHED, FIN, таймаут udp. по умолчанию 60:300:60:60
--hostcase ; менять регистр заголовка "Host:" по умолчанию на "host:".
--hostnospace ; убрать пробел после "Host:" и переместить его в конец значения "User-Agent:" для сохранения длины пакета
--methodeol ; добавить перевод строки в unix стиле ('n') перед методом и убрать пробел из Host: : "GET / ... Host: domain.com" => "nGET / ... Host:domain.com"
--hostspell=HoST ; точное написание заголовка Host (можно "HOST" или "HoSt"). автоматом включает --hostcase
--domcase ; домен после Host: сделать таким : TeSt.cOm
--dpi-desync=[<mode0>,]<mode>[,<mode2] ; атака по десинхронизации DPI. mode : synack syndata fake fakeknown rst rstack hopbyhop destopt ipfrag1 multisplit multidisorder fakedsplit fakeddisorder ipfrag2 udplen tamper
--dpi-desync-fwmark=<int|0xHEX> ; бит fwmark для пометки десинхронизирующих пакетов, чтобы они повторно не падали в очередь. default = 0x40000000
--dpi-desync-ttl=<int> ; установить ttl для десинхронизирующих пакетов
--dpi-desync-ttl6=<int> ; установить ipv6 hop limit для десинхронизирующих пакетов. если не указано, используется значение ttl
--dpi-desync-autottl=[<delta>[:<min>[-<max>]]] ; режим auto ttl для ipv4 и ipv6. по умолчанию: 1:3-20. delta=0 отключает функцию.
--dpi-desync-autottl6=[<delta>[:<min>[-<max>]]] ; переопределение предыдущего параметра для ipv6
--dpi-desync-fooling=<fooling> ; дополнительные методики как сделать, чтобы фейковый пакет не дошел до сервера. none md5sig badseq badsum datanoack hopbyhop hopbyhop2
--dpi-desync-repeats=<N> ; посылать каждый генерируемый в nfqws пакет N раз (не влияет на остальные пакеты)
--dpi-desync-skip-nosni=0|1 ; 1(default)=не применять dpi desync для запросов без hostname в SNI, в частности для ESNI
--dpi-desync-split-pos=N|-N|marker+N|marker-N ; список через запятую маркеров для tcp сегментации в режимах split и disorder
--dpi-desync-split-seqovl=N|-N|marker+N|marker-N ; единичный маркер, определяющий величину перекрытия sequence в режимах split и disorder. для split поддерживается только положительное число.
--dpi-desync-split-seqovl-pattern=<filename>|0xHEX ; чем заполнять фейковую часть overlap
--dpi-desync-fakedsplit-pattern=<filename>|0xHEX ; чем заполнять фейки в fakedsplit/fakeddisorder
--dpi-desync-badseq-increment=<int|0xHEX> ; инкремент sequence number для badseq. по умолчанию -10000
--dpi-desync-badack-increment=<int|0xHEX> ; инкремент ack sequence number для badseq. по умолчанию -66000
--dpi-desync-any-protocol=0|1 ; 0(default)=работать только по http request и tls clienthello 1=по всем непустым пакетам данных
--dpi-desync-fake-http=<filename>|0xHEX ; файл, содержащий фейковый http запрос для dpi-desync=fake, на замену стандартному www.iana.org
--dpi-desync-fake-tls=<filename>|0xHEX ; файл, содержащий фейковый tls clienthello для dpi-desync=fake, на замену стандартному
--dpi-desync-fake-unknown=<filename>|0xHEX ; файл, содержащий фейковый пейлоад неизвестного протокола для dpi-desync=fake, на замену стандартным нулям 256 байт
--dpi-desync-fake-syndata=<filename>|0xHEX ; файл, содержащий фейковый пейлоад пакета SYN для режима десинхронизации syndata
--dpi-desync-fake-quic=<filename>|0xHEX ; файл, содержащий фейковый QUIC Initial
--dpi-desync-fake-dht=<filename>|0xHEX ; файл, содержащий фейковый пейлоад DHT протокола для dpi-desync=fake, на замену стандартным нулям 64 байт
--dpi-desync-fake-unknown-udp=<filename>|0xHEX ; файл, содержащий фейковый пейлоад неизвестного udp протокола для dpi-desync=fake, на замену стандартным нулям 64 байт
--dpi-desync-udplen-increment=<int> ; насколько увеличивать длину udp пейлоада в режиме udplen
--dpi-desync-udplen-pattern=<filename>|0xHEX ; чем добивать udp пакет в режиме udplen. по умолчанию - нули
--dpi-desync-start=[n|d|s]N ; применять dpi desync только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру больше или равно N
--dpi-desync-cutoff=[n|d|s]N ; применять dpi desync только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N
--hostlist=<filename> ; действовать только над доменами, входящими в список из filename. поддомены автоматически учитываются.
; в файле должен быть хост на каждой строке.
; список читается при старте и хранится в памяти в виде иерархической структуры для быстрого поиска.
; при изменении времени модификации файла он перечитывается автоматически по необходимости
; список может быть запакован в gzip. формат автоматически распознается и разжимается
; списков может быть множество. пустой общий лист = его отсутствие
; хосты извлекаются из Host: хедера обычных http запросов и из SNI в TLS ClientHello.
--hostlist-domains=<domain_list> ; фиксированный список доменов через зяпятую. можно использовать # в начале для комментирования отдельных доменов.
--hostlist-exclude=<filename> ; не применять дурение к доменам из листа. может быть множество листов. схема аналогична include листам.
--hostlist-exclude-domains=<domain_list> ; фиксированный список доменов через зяпятую. можно использовать # в начале для комментирования отдельных доменов.
--hostlist-auto=<filename> ; обнаруживать автоматически блокировки и заполнять автоматический hostlist (требует перенаправления входящего трафика)
--hostlist-auto-fail-threshold=<int> ; сколько раз нужно обнаружить ситуацию, похожую на блокировку, чтобы добавить хост в лист (по умолчанию: 3)
--hostlist-auto-fail-time=<int> ; все эти ситуации должны быть в пределах указанного количества секунд (по умолчанию: 60)
--hostlist-auto-retrans-threshold=<int> ; сколько ретрансмиссий запроса считать блокировкой (по умолчанию: 3)
--hostlist-auto-debug=<logfile> ; лог положительных решений по autohostlist. позволяет разобраться почему там появляются хосты.
--new ; начало новой стратегии (новый профиль)
--skip ; не использовать этот профиль . полезно для временной деактивации профиля без удаления параметров.
--filter-l3=ipv4|ipv6 ; фильтр версии ip для текущей стратегии
--filter-tcp=[~]port1[-port2]|* ; фильтр портов tcp для текущей стратегии. ~ означает инверсию. установка фильтра tcp и неустановка фильтра udp запрещает udp. поддерживается список через запятую.
--filter-udp=[~]port1[-port2]|* ; фильтр портов udp для текущей стратегии. ~ означает инверсию. установка фильтра udp и неустановка фильтра tcp запрещает tcp. поддерживается список через запятую.
--filter-l7=[http|tls|quic|wireguard|dht|unknown] ; фильтр протокола L6-L7. поддерживается несколько значений через запятую.
--ipset=<filename> ; включающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip. перечитка автоматическая.
--ipset-ip=<ip_list> ; фиксированный список подсетей через запятую. можно использовать # в начале для комментирования отдельных подсетей.
--ipset-exclude=<filename> ; исключающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip. перечитка автоматическая.
--ipset-exclude-ip=<ip_list> ; фиксированный список подсетей через запятую. можно использовать # в начале для комментирования отдельных подсетей.
--debug 사용하면 콘솔, Syslog 또는 파일에 자세한 작업 로그를 표시 할 수 있습니다. 옵션을 따르는 절차가 중요 할 수 있습니다. --debug 처음에 가장 잘 표시됩니다. 옵션은 순차적으로 분석됩니다. 오류가 옵션을 확인하고 케이스가 아직 --debug 에 도달하지 못하면 메시지가 파일 또는 Syslog에 표시되지 않습니다. 파일에 로그인하면 프로세스가 파일을 열지 않습니다. 각 녹화를 위해 파일이 열리고 닫힙니다. 따라서 파일은 언제든지 삭제할 수 있으며 로그의 첫 번째 메시지에서 다시 생성됩니다. 그러나 루트 아래에서 프로세스를 시작하면 UID로 교체됩니다. 처음에는 로그에서 파일이 변경되면 녹화가 불가능합니다. 그런 다음 파일을 삭제하면 프로세스에 디렉토리에 파일을 생성 할 권리가 없으면 로그가 더 이상 수행되지 않습니다. 제거하는 대신 Truncate를 사용하는 것이 좋습니다. 쉘에서 이것은 ":> filename"명령을 통해 수행 할 수 있습니다.
본질은 다음과 같습니다. 서버 OS가 원래 요청을 서버 프로세스로 전송하지 않도록 원래의 요청이 작성되고 수정 된 가짜 정보 (가짜)가 추가되고 DPI가 다른 것을 보았습니다. 그가 막지 않을 것이라는 사실. 서버는 한 가지, DPI는 또 다른 것을 본다. DPI는 금지 된 요청이 전송되었으며이를 차단하지 않는다는 것을 이해하지 못합니다.
그러한 결과를 달성 할 수있는 기회가 있습니다. 이것은 가짜 패키지를 전송하여 DPI에 도달 할 수 있지만 서버에 도달하지는 않습니다. TCP 수준 (세분화) 또는 IP 수준에서의 조각화를 사용할 수 있습니다. TCP 시퀀스 번호 또는 혼란스러운 TCP 세그먼트가있는 게임을 기반으로 한 공격이 있습니다. 메소드는 다양한 버전으로 결합 할 수 있습니다.
가짜는 DPI에 대한 잘못된 정보를 가지고있는 별도의 NFQW 생성 패키지입니다. 그들은 서버에 도달하지 않아야하거나 도달 할 수는 없지만 그들에게 버려야합니다. 그렇지 않으면, TCP 연결의 분류 또는 전송 된 흐름의 무결성 위반으로 자원을 깨뜨릴 수 있습니다. 이 문제를 해결하는 방법에는 여러 가지가 있습니다.
md5sig TCP MD5 서명 옵션을 추가합니다. 모든 서버에서 작동하지는 않습니다. MD5 패키지는 일반적으로 Linux 만 폐기됩니다.badsum TCP의 제어량을 망칩니다. 장치가 NAT 용 인 경우 작동하지 않습니다. 휠체어로 가방을 놓치지 않습니다. Linux에서 라우터 NAT를 설정하는 것은이를 놓치지 않습니다. 대부분의 홈 라우터는 Linux에 구축됩니다. Nesting은 다음과 같이 보장됩니다. syssctl 튜닝 기본적으로 net.netfilter.nf_conntrack_checksum=1 으로 Conntrack은 들어오는 패키지의 TCP 및 UDP 체크 아웃을 확인하고 휠체어로 패키지에 대한 State Invalid를 설정합니다. 일반적으로 iptables 규칙에서, 전방 체인에서 유효하지 않은 상태가있는 패키지 방울에 대한 규칙이 삽입됩니다. 이러한 요인들의 공동 조합은 그러한 라우터를 통해 배설물이 부족하게됩니다. Gearbox net.netfilter.nf_conntrack_checksum=0 의 OpenWrt에서는 종종 다른 라우터가 없으며 항상 변경할 수는 없습니다. NFQWS가 라우터를 통해 작동하려면 로컬에서 생성 된 패키지의 chexumma를 확인하지 않기 때문에 지정된 SysCTL 값을 0으로 설정해야합니다. 라우터 자체의 NFQW는이 구성없이 작동합니다. 예를 들어 공급자와 같은 다른 NAT 후 라우터가 유효하지 않은 패킷을 놓치지 않으면 그것에 대해 아무것도 할 수 없습니다. 그러나 일반적으로 제공자는 여전히 Badsum을 놓치고 있습니다. 일부 어댑터/스웨트 셔츠/드라이버의 경우 RX-Checksum Offload에서는 OS에서 수신하기 전에 Badsum 패키지를 제거해야합니다. 이 경우 무언가를 수행 할 수있는 경우 드라이버 만 수정하여 매우 사소한 것으로 보입니다. Mediatek을 기반으로 일부 라우터가 이런 식으로 행동한다는 것이 확립되었습니다. Badsum 패키지는 클라이언트 OS를 떠나지 만 라우터는 TCPDUMP를 통해 BR-LAN에서 볼 수 없습니다. 또한, NFQWS가 라우터 자체에서 수행되는 경우 바이 패스가 작동 할 수 있습니다. Badsum은 일반적으로 외부 인터페이스를 남깁니다.badseq TCP 시퀀스 번호를 특정 값으로 증가시켜 TCP 창에서 인출합니다. 이러한 패키지는 수신 노드에 의해 폐기 될 수 있지만 시퀀스 번호에 중점을 둔 경우 DPI도 폐기 할 것입니다. 기본적으로 SEQ 변위는 -10000으로 선택됩니다. 연습에 따르면 일부 DPI는 특정 창 밖에서 SEQ를 놓치지 않는 것으로 나타났습니다. 그러나 이러한 작은 변위는 상당한 스트리밍 및 패키지 손실로 문제를 일으킬 수 있습니다. --dpi-desync-any-protocol 사용하는 경우 Badeq 증분 0x80000000을 설치해야 할 수도 있습니다. 이렇게하면 가짜 패키지가 서버의 TCP 창에 쐐기가되지 않는다는 신뢰할만한 보증이 제공됩니다. 또한 Badeq는 HTTP 분석 중에 일부 DPI의 논리를 깨뜨려 연결이 동결을 일으킨다는 점도 언급되었습니다. 또한 Badeq와 동일한 DPI TLS에서는 잘 작동합니다.TTL 최선의 선택 인 것처럼 보였지만 각 공급자에 대한 개별 튜닝이 필요합니다. DPI가 제공자의 로컬 사이트보다 더 많은 경우, 이들에 대한 액세스를 차단할 수 있습니다. 고속도로에 TSPU가 있으면 상황이 악화되어 TTL이 TTL을 상당히 높게 만들어 서버로의 가짜 고장 위험을 증가시킵니다. IP 제외 목록이 필요하며 수동으로 채워집니다. TTL과 함께 MD5SIG를 사용할 수 있습니다. 이것은 아무것도 망치지 않지만 "나쁜"백이 TTL에 도달 할 사이트에서 작동 할 가능성이 높습니다. 자동 솔루션을 찾을 수없는 경우 zapret-hosts-user-exclude.txt 파일을 사용하십시오. 라우터의 일부 스톡 펌웨어는 나가는 TTL을 수정하지만이 옵션을 분리하지 않고이를 통해 작동하지 않습니다. TTL을 선택할 가치가있는 것은 무엇입니까? 바이 패스가 여전히 작동하는 최소 값을 찾으십시오. 이것은 DPI 홉의 수입니다.hopbyhop IPv6만을 나타냅니다. IPv6 Extens 헤더 hop-by-hop options 추가됩니다. hopbyhop2 버전에서는 2 개의 헤더가 추가되어 표준을 위반하고 모든 OS의 프로토콜 스택에 의해 폐기됩니다. 하나의 헤더 홉 별 하나는 모든 OS에서 허용되지만 일부 채널/제공 업체에서는 그러한 패키지를 필터링하고 도달하지 못할 수 있습니다. 계산은 DPI가 Hop-By-Hop으로 패키지를 분석하지만 공급자 필터의 주소에 도달하지 않거나 두 개의 헤드가 있기 때문에 서버가 다시 던져 질 것입니다.datanoack ACK TCP 플래그로 가짜를 보냅니다. 서버는 허용되지 않으며 DPI는 수락 할 수 있습니다. 이 기술은 NAT를 깨뜨릴 수 있으며 현지 시스템 (거의 항상 IPv4 라우터에서)에서도 가장 무도회가 사용되는 경우 IPTables와 항상 작동하지는 않습니다. 가장 무도회와 nftables가없는 시스템에서는 제한없이 작동합니다. 실험적으로 많은 공급자 NAT가 이러한 패키지를 폐기하지 않으므로 내부 공급자 IP에서도 작동합니다. 그러나 Linux NAT를 통과하지는 않으므로이 기술은 홈 라우터 뒤에서 작동하지 않을 가능성이 높지만 그로부터 작동 할 수 있습니다. 연결이 연결된 경우 라우터를 통해 작동 할 수 있고 라우터에서 하드웨어 가속도가 켜집니다.autottl . TTL의 자동 정의에서 정권의 본질은 거의 확실하게 DPI를 통과하고 서버에 약간 도달하지 않도록합니다. TTL 64.128,255의 기본 값은 들어오고 들어오는 패키지 모양 (예, 첫 번째 수신 패키지를 NFQWS로 지시해야합니다!). 트랙의 길이가 계산되고 delta 취해집니다 (기본적으로 1). TTL이 범위를 벗어난 경우 (기본적으로 Min, Max -3.20) Min, 최대 값은 범위에 맞게 가져옵니다. 결과 TTL이 경로의 길이보다 크면 자동화가 작동하지 않았으며 공격에 대한 고정 TTL 값이 취해집니다. 이 기술을 사용하면 전체 네트워크가 고속도로를 포함하여 가능한 한 Barriers (DPI, TSPU)에 의해 차단되면 질문을 해결할 수 있습니다. 그러나 잠재적으로 실패 할 수 있습니다. 예를 들어, 특정 서버에 대한 수신 및 나가는 채널의 비대칭으로. 일부 제공 업체의 경우이 기술은 잘 작동하며 다른 기술은 잘 작동합니다. 어딘가에 매개 변수 조정이 필요할 수 있습니다. 추가 리미터와 함께 사용하는 것이 좋습니다. 학군 모드는 모든 조합으로 결합 할 수 있습니다. --dpi-desync-fooling 쉼표를 통해 많은 값을 취합니다.
multisplit . 우리는 --dpi-desync-split-pos 에 표시된 위치로 요청을 줄였습니다.multidisorder . 우리는 요청을 --dpi-desync-split-pos 에 표시된 위치로 삭감하고 역 순서로 보냅니다.fakedsplit . 우리는 두 부분에 대한 요청을 삭감하고, 각 부분을 가짜로 프레임 : 첫 번째 부분의 가짜, 1 부의 가짜, 첫 번째 부분의 가짜, 2 부의 가짜, 2 부의 가짜, 두 번째 부분의 가짜fakeddisorder . fakedsplit 과 마찬가지로 리버스 순서 : 2 부의 가짜, 2 부분, 2 부의 가짜, 첫 번째 부분의 가짜, 1 부, 가짜 1 부분. fakedsplit / fakeddisorder 에서 가짜의 내용은 매개 변수 --dpi-desync-fakedsplit-pattern (default 0x00)에 의해 결정됩니다. 이 가짜는 참조 부품의 변위에 해당하는 변위가있는 패턴에서 가져옵니다. 가짜 크기는 전송 된 부품의 길이에 해당합니다. 이 모드의 목적은 가짜 사이의 원본 데이터를 식별하는 것입니다.
절단 위치를 결정하기 위해 마커가 사용됩니다.
상대적 위치 :
--methodeol 로 인해 이동할 수 있습니다. 위치는 1 또는 2 일 수 있습니다. 마커 목록의 예 : 100,midsld,sniext+1,endhost-2,-10 .
패키지를 깨뜨릴 때 가장 먼저 한 것은 분해 된 마커입니다. 이러한 모든 상대 위치를 찾고 변위를 사용합니다. 현재 프로토콜에 상대 위치가 없으면 그러한 위치는 적용되고 폐기되지 않습니다. 그런 다음 패키지 그룹에서 현재 패키지의 변위에 관한 위치의 정규화가 있습니다 (예 : Kyber를 사용한 TLS 멀티 패킷 요청). 현재 패키지의 한계를 넘어 확장되는 모든 위치가 버려집니다. 나머지는 중복 증가의 증가로 분류됩니다. multisplit 및 multidisorder 의 변형에서 단일 위치가 남지 않으면 고장이 발생하지 않습니다.
fakedsplit 및 fakeddisorder 옵션은 하나의 분할 위치 만 사용합니다. 목록 --dpi-desync-split-pos 사이의 그녀의 검색은 특별한 방식으로 수행됩니다. 먼저 모든 상대 마커가 확인됩니다. 그들 중에 적합한 것을 발견하면 사용됩니다. 그렇지 않으면 모든 절대 마커가 확인됩니다. 그 중에서 아무것도 발견되지 않으면 위치 1이 적용됩니다.
예를 들어 --dpi-desync-split-pos=method+2,midsld,5 쓸 수 있습니다. HTTP 프로토콜이 있으면 분류는 method+2 의 위치에 있습니다. TLS 프로토콜이 midsld 에있는 경우. 프로토콜이 알려지지 않았고 포괄적 인 --dpi-desync-any-protocol 있는 경우, 분류는 위치 5에 있습니다. 모든 것을 명확하게 만들려면 다른 프로토콜에 다른 프로파일을 사용할 수 있으며이 프로토콜에 확실히 하나의 위치 만 표시 할 수 있습니다.
seqovl TCP 세그먼트 중 하나의 시작 부분에 시퀀스 번호가 seqovl 로 변위되는 시작으로 seqovl 추가합니다. split 의 경우 - 첫 번째 세그먼트의 시작 부분에서, disorder 의 경우 - 두 번째 세그먼트의 시작 부분 (원본 다음 순서에서 두 번째).
split 계산은 이전의 참조가 이미 서버 응용 프로그램의 코켓에 들어갔다는 사실에 있습니다. 앞쪽에는 가짜 부분이 폐기되고 나머지 부분에는 원본이 포함되어 있으며 창의 시작부터 시작하여 소켓이 들어갑니다. 서버 애플리케이션은 클라이언트가 실제로 보내는 모든 것을 수신하여 가짜 창 밖 부분을 버립니다. 그러나 DPI는 이것을 이해할 수 없으므로 시퀀스 desinchronization을 가지고 있습니다. seqovl 갖는 첫 번째 세그먼트는 MTU의 길이를 초과하지 않는 것이 필수적이다. 이 상황은 Linux에서 자동으로 인식되며 seqovl 취소됩니다. 다른 시스템에서는 상황이 인식되지 않으며 이는 연결의 고장으로 이어질 것입니다. 따라서 첫 번째 분할 위치와 seqovl 선택하여 MTU가 어떤 경우에도 초과되지 않도록하십시오. 그렇지 않으면, 영성이 효과가 없거나 무작위로 작동하지 않을 수 있습니다.
disorder 중복의 경우 패키지의 두 번째 부분으로갑니다. 간단하게하기 위해, 우리는 부서가 2 개의 부분으로 들어가고 원래 순서 "1 2"로 "2"순서가 될 것이라고 가정합니다. seqovl 첫 번째 분할의 위치보다 작아야합니다. 그렇지 않으면 전송 된 모든 것이 가짜를 포함하여 즉시 소켓으로 전송되어 적용된 레벨의 프로토콜을 깨뜨립니다. 이 상황은 프로그램에 의해 쉽게 감지되며 seqovl 취소됩니다. 패키지 크기의 증가는 원칙적으로 불가능합니다. 패키지의 두 번째 부분의 조건에 따라는 완전히 독창적이므로 서버 OS는 가짜를 포함하여 완전히 수락합니다. 그러나 1 팩 1 팩 데이터의 초기 부분은 아직 채택되지 않았으므로 가짜 및 실제 데이터는 서버 응용 프로그램에 가지 않고 핵 메모리에 남아 있습니다. 패키지의 첫 번째 부분이 오자마자 Nucleus 메모리에서 가짜 부분을 다시 작성합니다. 핵은 1과 2 부품의 데이터를 수신하므로 응용 프로그램은 애플리케이션 소켓으로 전송됩니다. Solaris를 제외한 모든 UNIX OS의 동작은 마지막 데이터를 채택하여 남겨 두는 것입니다. Windows는 오래된 데이터를 남기므로 SEQOVL을 사용한 장애는 Windows 서버에서 작업 할 때 강화로 이어질 것입니다. Solaris는 거의 죽었고 Windows 서버는 거의 없습니다. 필요한 경우 시트를 사용할 수 있습니다. 이 방법을 사용하면 속지 않고 TTL없이 수행 할 수 있습니다. 가짜는 실제 데이터와 혼합되어 있습니다. fakedsplit/fakeddisorder 여전히 별도의 가짜를 추가합니다.
split 버전의 seqovl 첫 번째 패키지에서만 사용되므로 절대적인 양수 값 일 수 있습니다. disorder 버전에서는 모든 마커 옵션이 허용됩니다. 시리즈의 현재 패키지로 자동 정규화됩니다. midsld 에서 직조하고 midsld-1 에서 seqovl을 만들 수 있습니다.
hopbyhop , destopt 및 ipfrag1 DesingHronization 모드 (Fololing과 혼동하지 않음)는 IPv6과 관련이 있으며 hop-by-hop options , destination options 또는 fragment 추가로 추가하는 데있어 해독에 해당하는 모든 패키지에 포함됩니다. 여기서 헤더를 추가하면 패키지의 크기가 증가하므로 최대 크기의 패킷에는 적용 할 수 없습니다. 큰 메시지를 전송할 때 발생합니다. 패키지를 보내는 것이 불가능하다면, 정신의 정신이 취소되고, 패키지는 원본으로 추방됩니다. 계산은 DPI가 기본 ipv6 제목의 다음 헤더 필드에서 0을 볼 수 있으며 전송 헤더를 찾아 확장자 헤더에서 점프하지 않을 것입니다. 따라서 TCP 또는 UDP라는 것을 이해하지 못하고 분석없이 패키지를 놓칠 것입니다. 아마도 일부 DPI는 그것을 살 것입니다. ipfrag1+ipfrag2 옵션을 제외하고 2 단계의 모든 모드와 결합 할 수 있습니다. 예를 들어, hopbyhop,multisplit TCP 패키지를 여러 세그먼트로 나누는 것을 의미합니다. hopbyhop,ipfrag2 사용하면 헤더 시퀀스가 다음과 같습니다. ipv6,hop-by-hop , fragment , tcp/udp . ipfrag1 모드가 특별한 준비 없이는 항상 작동하지 않을 수 있습니다. 섹션 IP фрагментация 참조하십시오.
DPI-Desync 매개 변수에서 쉼표를 통해 최대 3 개의 모드를 지정할 수 있습니다.
synack , syndata , --wsize , --wssize . 호스트 목록의 필터는이 단계에서 작동하지 않습니다.fake , rst , rstack .fakedsplit 또는 ipfrag2 )의 참조.모드는 위상 수가 증가하는 순서로 표시해야합니다.
서버의 답변을 분석하는 DPI, 특히 도메인이 등록되는 ServerHello의 인증서를 분석합니다. ClientHello 배송 확인은 ClientHello+1의 길이에 해당하는 ACK 시퀀스가있는 ACK 서버 패키지입니다. 장애 버전에서는 부분 확인 (자루)이 일반적으로 먼저옵니다. ACK 또는 자루 대신 최소 지연이있는 RST 패키지가 있으면 DPI가 요청 단계에서 삭감됩니다. RST가 서버에 대한 핑과 동일한 지연 후 완전한 ACK 후에 진행되면 DPI는 서버 응답에 반응 할 수 있습니다. ClientHello가 그를 만족시키고 ServerHello를 점검하지 않으면 DPI가 스트림 뒤에 지연 될 수 있습니다. 그럼 당신은 운이 좋다. 가짜 옵션이 작동 할 수 있습니다. 그가 뒤쳐지지 않고 완고하게 ServerHello를 점검하는 경우, 서버가 매개 변수 --wssize (Conntrack 참조)를 통해 ServerHello를 파트로 보내도록 강요 할 수 있습니다. 이것이 도움이되지 않으면 서버의 도움 없이는 무언가를하지 않을 것입니다. 가장 좋은 솔루션은 서버에서 TLS 1.3 지원을 가능하게하는 것입니다. 그것에서 서버 인증서는 암호화 된 양식으로 전송됩니다. 이것은 차단 된 사이트의 모든 관리자에게 권장 사항입니다. TLS 1.3을 켭니다. 따라서 DPI를 극복 할 수있는 더 많은 기회를 제공 할 것입니다.
제네바 문서에서 이것을 "TCB Turnaround"라고합니다. 클라이언트와 서버의 역할과 관련하여 DPI를 오도하려는 시도.
모드는 NAT의 작업을 위반하므로 장비는 공격 장치와 DPI 사이에 NAT가없는 경우에만 작동 할 수 있습니다. 공격은 Nat A 라우터를 통해 작동하지 않지만 그로부터 작동 할 수 있습니다. 전달 트래픽에 대한 공격을 구현하려면 NFTABLE 및 POSTNAT 체계가 필요합니다.
모든 것이 간단합니다. 데이터가 SYN 패키지에 추가됩니다. TFO (TCP Fast Open)가 사용되지 않으면 모든 OS는 이들을 무시하며 DPI는 TFO를 먹는 것인지 이해하지 않고 인식 할 수 있습니다. TFO와의 원래 연결은 터치하지 않습니다. 명확한 매개 변수가 없으면 16 바이트가 추가됩니다.
NAT의 VirtualBox 및 VMware의 VM 내부에서 많은 NFQWS 패키지 기술은 NAT 모드에서 작동하지 않습니다. TTL은 강제로 교체되며 가짜 패키지가 통과되지 않습니다. 브리지 모드에서 네트워크를 구성해야합니다.
NFQWS에는 추적 TCP 화합물의 제한된 구현이 장착되어 있습니다. DPI에 대응하는 일부 방법의 구현을 위해 켜져 있습니다. Connetrack은 연결 단계를 모니터링 할 수 있습니다 : SYN, SPEALL, FIN, 각 방향의 패키지 수, 시퀀스 번호. Connetrack은 하나의 웨이 백 또는 한 방향으로 만 "피드"할 수 있습니다. Syn 또는 Syn, ACK가 설정 한 플래그가있는 패키지를 찾으면 연결이 테이블에 들어갑니다. 따라서 Conntrack이 필요한 경우 iPtables 리디렉션 규칙에서 연결은 첫 번째 패키지에서 NFQWS로 이동해야하지만 Connbytes 필터를 뚫을 수 있습니다. UDP의 경우 테이블에 들어가는 개시자가 첫 번째 UDP 패키지입니다. 또한 흐름의 방향을 결정합니다. 첫 번째 UDP 패키지는 클라이언트에서 서버로 제공되는 것으로 여겨집니다. 다음으로, src_ip,src_port,dst_ip,dst_port 가있는 모든 패키지는 비 활동 시간이 만료되기 전에이 흐름에 속하는 것으로 간주됩니다. Conntrack은 간단하며 연결에 대한 모든 종류의 공격을 고려하여 작성되지 않았으며 시퀀스 번호 또는 Chekumm의 유효성을 확인하지 않습니다. 그 작업은 NFQW의 요구를 유지하는 것입니다. 일반적으로 나가는 트래픽에만 공급되므로 외부 네트워크의 대체에 민감하지 않습니다. 연결이 추적 해야하는 즉시 또는 비활성 동시 경력이 사라지 자마자 연결이 제거됩니다. 연결의 각 단계마다 별도의 시간 초과가 있습니다. 매개 변수 --ctrack-timeouts 에 의해 변경 될 수 있습니다.
--wssize 사용하면 클라이언트에서 서버의 TCP 창의 크기를 변경하여 다음 답변을 조각으로 보낼 수 있습니다. 이를 위해서는 모든 서버 OS에 영향을 미치려면 메시지를 보내기 전에 클라이언트에서 오는 각 패키지의 창 크기를 변경해야합니다.이 답은 나누어야합니다 (예 : TLS ClientHello). 그렇기 때문에 언제 중지 해야하는지 알아야합니다. 낮은 WSSS 크기를 멈추고 설치하지 않으면 속도가 치명적으로 떨어집니다. Linux에서는 Connbytes를 통해 중지 될 수 있지만 BSD 시스템에는 그러한 가능성이 없습니다. HTTP의 경우 첫 번째 HTTP 요청 또는 TLS ClientHello를 전송 한 직후 중지됩니다. http (들)를 다루는 경우 매개 변수 --wssize-cutoff 필요합니다. WSSIZE 액션이 중지되는 한도를 설정합니다. 숫자 이전의 접두사 D는 데이터 페이로드, 접두사 S- 상대 시퀀스 번호, 즉 클라이언트 + 1에 의해 전송 된 바이트 수를 가진 패키지만을 의미합니다. HTTP 요청 또는 TLS ClientLol이있는 패키지가 WSSize Cutoff 대기없이 대기하지 않고 대기하지 않고 즉시 중지됩니다. 프로토콜이 오랫동안 무 활동이 발생하기 쉬운 경우 --ctrack-timeouts 매개 변수를 통해 확립 된 단계가 증가합니다. 기본값은 5 분 밖에 걸리지 않습니다. NFQWS는 패키지를 제공함으로써 패키지를 먹는다는 것을 잊지 마십시오. Connbytes를 통해 패키지 섭취를 제한하면 테이블은 확립 된 단계에서 매달린 화합물을 유지할 수 있으며, 이는 Timout에 의해서만 떨어질 것입니다. Conntrack을 진단하려면 SigusR1 신호를 NFQWS : killall -SIGUSR1 nfqws 로 보내십시오. 현재 테이블은 Stdout의 NFQWS에 의해 표시됩니다.
일반적으로 SYN 패키지에서 클라이언트는 창 크기 외에도 TCP 확장 scaling factor 나타냅니다. 스케일링 팩터 는 듀스의 정도이며, 창 크기에 곱합니다. 스케일링 계수 만 감소 할 수 있으며, 서버의 창 크기를 초과하지 않도록 증가가 차단됩니다. DPI의 서버 인증서에서 서버 이름을 지우는 것을 피하기 위해 서버가 ServerHello의 조각화를 강제하려면 --wssize=1:6 사용하는 것이 가장 좋습니다. 주요 규칙은 창 크기를 복원 한 후 창의 최종 크기가 가능한 한 가능한 한 scale_factor 가능한 한 많이 만드는 것입니다. 64 : 0을 만들면 매우 느립니다. 반면에 DPI가 원하는 것을 찾을 수있을만큼 서버의 응답이 커지는 것은 불가능합니다.
--wssize 호스트리스트와의 프로파일에서 작동하지 않습니다. 연결 시작부터 시트에 들어가기를 결정하는 것이 불가능한 경우 연결의 시작부터 작용하기 때문입니다. 그러나 자동 호스트리스트가있는 프로파일에는 -wssize가 포함될 수 있습니다. --wssize 속도 속도를 늦추거나 사이트의 응답 시간을 증가시킬 수 있으므로 DPI를 우회하는 다른 작업 방법이있는 경우 사용하는 것이 좋습니다.
--dpi-desync-cutoff 사용하면 dpi-desync에 도달 할 때 한계를 설정할 수 있습니다. 접두사 n, d, s는 유추 C- --wssize-cutoff 로 사용할 수 있습니다. --dpi-desync-any-protocol=1 과 함께 유용합니다. 무 활동이 발생하기 쉬운 화합물에서는 Conntrack 타임 아웃을 변경해야합니다. 연결이 Conntrack에서 떨어지고 옵션이 설정되어 있으면 --dpi-desync-cutoff 설정되면 dpi desync 적용되지 않습니다.
NFQWS는 일부 유형의 요청의 재 조립을 지원합니다. 현재 이것은 TLS 및 Quic ClientHello입니다. Chrome에 TLS-Kyber의 Quantum 후 암호화를 포함하고 일반적으로 2 또는 3 패키지를 차지하면 길다. Chyber는 Chromium 124로 시작하여 기본적으로 켜집니다. Chrome은 TLS Puchprinnt에 의해 무작위 배정됩니다. SNI는 처음과 끝에있을 수 있습니다. 즉, 모든 패키지에 들어갈 수 있습니다. Stateful DPI는 일반적으로 요청을 완전히 재 조립 한 다음 차단에 대한 결정을 내립니다. In the case of obtaining a TLS or QUIC package with a partial Clienthello, the assembly process begins, and the packages are delayed and are not sent until its end. At the end of the assembly, the package passes through the desynchronization on the basis of the fully collected Clienthello. In case of any error during the assembly process, the detained packages are immediately sent to the network, and the desinchronization is canceled.
Есть специальная поддержка всех вариантов tcp сплита для многосегментного TLS. Если указать позицию сплита больше длины первого пакета, то разбивка происходит не обязательно первого пакета, а того, на который пришлась итоговая позиция. Если, допустим, клиент послал TLS ClientHello длиной 2000, SNI начинается с 1700, и заданы опции fake,multisplit , то перед первым пакетом идет fake, затем первый пакет в оригинале, а последний пакет разбивается на 2 сегмента. В итоге имеем фейк в начале и 3 реальных сегмента.
Атаки на udp более ограничены в возможностях. udp нельзя фрагментировать иначе, чем на уровне ip. Для UDP действуют только режимы десинхронизации fake , hopbyhop , destopt , ipfrag1 , ipfrag2 , udplen , tamper . Возможно сочетание fake , hopbyhop , destopt с ipfrag2 , fake , fakeknown с udplen и tamper. udplen увеличивает размер udp пакета на указанное в --dpi-desync-udplen-increment количество байтов. Паддинг заполняется нулями по умолчанию, но можно задать свой паттерн. Предназначено для обмана DPI, ориентирующегося на размеры пакетов. Может сработать, если пользовательский протокол не привязан жестко к размеру udp пейлоада. Режим tamper означает модификацию пакетов известных протоколов особенным для протокола образом. На текущий момент работает только с DHT. Поддерживается определение пакетов QUIC Initial с расшифровкой содержимого и имени хоста, то есть параметр --hostlist будет работать. Определяются пакеты wireguard handshake initiation и DHT (начинается с 'd1', кончается 'e'). Для десинхронизации других протоколов обязательно указывать --dpi-desync-any-protocol . Реализован conntrack для udp. Можно пользоваться --dpi-desync-cutoff. Таймаут conntrack для udp можно изменить 4-м параметром в --ctrack-timeouts . Атака fake полезна только для stateful DPI, она бесполезна для анализа на уровне отдельных пакетов. По умолчанию fake наполнение - 64 нуля. Можно указать файл в --dpi-desync-fake-unknown-udp .
Современная сеть практически не пропускает фрагментированные tcp на уровне ip. На udp с этим дело получше, поскольку некоторые udp протоколы могут опираться на этот механизм (IKE старых версий). Однако, кое-где бывает, что режут и фрагментированный udp. Роутеры на базе linux могут самопроизвольно собирать или перефрагментировать пакеты. Позиция фрагментации задается отдельно для tcp и udp. По умолчанию 24 и 8 соответственно, должна быть кратна 8. Смещение считается с транспортного заголовка.
Существует ряд моментов вокруг работы с фрагментами на Linux, без понимания которых может ничего не получиться.
ipv4 : Linux дает отсылать ipv4 фрагменты, но стандартные настройки iptables в цепочке OUTPUT могут вызывать ошибки отправки.
ipv6 : Нет способа для приложения гарантированно отослать фрагменты без дефрагментации в conntrack. На разных системах получается по-разному. Где-то нормально уходят, где-то пакеты дефрагментируются. Для ядер <4.16 похоже, что нет иного способа решить эту проблему, кроме как выгрузить модуль nf_conntrack , который подтягивает зависимость nf_defrag_ipv6 . Он то как раз и выполняет дефрагментацию. Для ядер 4.16+ ситуация чуть лучше. Из дефрагментации исключаются пакеты в состоянии NOTRACK. Чтобы не загромождать описание, смотрите пример решения этой проблемы в blockcheck.sh .
Иногда требуется подгружать модуль ip6table_raw с параметром raw_before_defrag=1 . В openwrt параметры модулей указываются через пробел после их названий в файлах /etc/modules.d . В традиционных системах посмотрите используется ли iptables-legacy или iptables-nft . Если legacy, то нужно создать файл /etc/modprobe.d/ip6table_raw.conf с содержимым :
options ip6table_raw raw_before_defrag=1
В некоторых традиционных дистрибутивах можно изменить текущий ip6tables через : update-alternatives --config ip6tables Если вы хотите оставаться на iptables-nft, вам придется пересобрать патченную версию. Патч совсем небольшой. В nft.c найдите фрагмент:
{
.name = "PREROUTING",
.type = "filter",
.prio = -300, /* NF_IP_PRI_RAW */
.hook = NF_INET_PRE_ROUTING,
},
{
.name = "OUTPUT",
.type = "filter",
.prio = -300, /* NF_IP_PRI_RAW */
.hook = NF_INET_LOCAL_OUT,
},
и замените везде -300 на -450.
Это нужно сделать вручную, никакой автоматики в blockcheck.sh нет.
Либо можно раз и навсегда избавиться от этой проблемы, используя nftables . Там можно создать netfilter hook с любым приоритетом. Используйте приоритет -401 и ниже.
При использовании iptables и NAT, похоже, что нет способа прицепить обработчик очереди после NAT. Пакет попадает в nfqws с source адресом внутренней сети, затем фрагментируется и уже не обрабатывается NAT. Так и уходит во внешюю сеть с src ip 192.168.xx Следовательно, метод не срабатывает. Видимо единственный рабочий метод - отказаться от iptables и использовать nftables. Хук должен быть с приоритетом 101 или выше.
nfqws способен по-разному реагировать на различные запросы и применять разные стратегии дурения. Это реализовано посредством поддержки множества профилей дурения. Профили разделяются в командной строке параметром --new . Первый профиль создается автоматически. Для него не нужно --new . Каждый профиль имеет фильтр. По умолчанию он пуст, то есть профиль удовлетворяет любым условиям. Фильтр может содержать жесткие параметры: версия ip протокола, ipset и порты tcp/udp. Они всегда однозначно идентифицируются даже на нулевой фазе десинхронизации, когда еще хост и L7 неизвестны. В качестве мягкого фильтра могут выступать хост-листы и протокол прикладного уровня (l7). L7 протокол становится известен обычно после первого пакета с данными. При поступлении запроса идет проверка профилей в порядке от первого до последнего до достижения первого совпадения с фильтром. Жесткие параметры фильтра сверяются первыми. При несовпадении идет сразу же переход к следующему профилю. Если какой-то профиль удовлетворяет жесткому фильтру и L7 фильтру и содержит авто-хостлист, он выбирается сразу. Если профиль удовлетворяет жесткому фильтру и L7 фильтру, для него задан хостлист, и у нас еще нет имени хоста, идет переход к следующему профилю. В противном случае идет проверка по хостлистам этого профиля. Если имя хоста удовлетворяет листам, выбирается этот профиль. Иначе идет переход к следующему. Может так случиться, что до получения имени хоста или узнавания L7 протокола соединение идет по одному профилю, а при выяснении этих параметров профиль меняется на лету. Это может произойти даже дважды - при выяснении L7 и имени хоста. Чаще всего это выяснение совмещается в одно действие, поскольку по одному пакету как правило узнается и L7, и хост. Поэтому если у вас есть параметры дурения нулевой фазы, тщательно продумывайте что может произойти при переключении стратегии. Смотрите debug log, чтобы лучше понять что делает nfqws. Нумерация профилей идет с 1 до N. Последним в цепочке создается пустой профиль с номером 0. Он используется, когда никакие условия фильтров не совпали.
중요한
Множественные стратегии создавались только для случаев, когда невозможно обьединить имеющиеся стратегии для разных ресурсов. Копирование стратегий из blockcheck для разных сайтов во множество профилей без понимания как они работают приведет к нагромождению параметров, которые все равно не покроют все возможные заблокированные ресурсы. Вы только увязните в этой каше.
중요한
user-mode реализация ipset создавалась не как удобная замена *nix версии, реализованной в ядре. Вариант в ядре работает гораздо эффективнее. Это создавалось для систем без подержки ipset в ядре. Конкретно - Windows и ядра Linux, собранные без nftables и ipset модулей ядра. Например, в android нет ipset.
iptables для задействования атаки на первые пакеты данных в tcp соединении :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp -m multiport --dports 80,443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
Этот вариант применяем, когда DPI не следит за всеми запросами http внутри keep-alive сессии. Если следит, направляем только первый пакет от https и все пакеты от http :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
mark нужен, чтобы сгенерированный поддельный пакет не попал опять к нам на обработку. nfqws выставляет fwmark при его отсылке. хотя nfqws способен самостоятельно различать помеченные пакеты, фильтр в iptables по mark нужен при использовании connbytes, чтобы не допустить изменения порядка следования пакетов. Процессинг очереди - процесс отложенный. Если ядро имеет пакеты на отсылку вне очереди - оно их отправляет незамедлительно. Изменение правильного порядка следования пакетов при десинхронизации ломает всю идею. Так же были замечены дедлоки при достаточно большой отсылке пакетов из nfqws и отсутствии mark фильтра. Процесс может зависнуть. Поэтому наличие фильтра по mark в ip/nf tables можно считать обязательным.
Почему --connbytes 1:6 :
Для режима autottl необходимо перенаправление входящего SYN,ACK пакета или первого пакета соединения (что обычно есть тоже самое). Для режима autohostlist необходимы входящие RST и http redirect. Можно построить фильтр на tcp flags для выделения SYN,ACK и модуле u32 для поиска характерных паттернов http redirect, но проще использовать connbytes для выделения нескольких начальных входящих пакетов.
iptables -t mangle -I PREROUTING -i <внешний интерфейс> -p tcp -m multiport --sports 80,443 -m connbytes --connbytes-dir=reply --connbytes-mode=packets --connbytes 1:3 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
Для quic :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
6 пакетов берется, чтобы покрыть случаи возможных ретрансмиссий quic initial в случае плохой связи или если сервер плохо себя чувствует, а приложение настаивает именно на quic, не переходя на tcp. А так же для работы autohostlist по quic. Однако, autohostlist для quic не рекомендуется.
Можно начать с базовой конфигурации.
IFACE_WAN=wan
nft create table inet ztest
nft add chain inet ztest post "{type filter hook postrouting priority mangle;}"
nft add rule inet ztest post oifname $IFACE_WAN meta mark and 0x40000000 == 0 tcp dport "{80,443}" ct original packets 1-6 queue num 200 bypass
nft add rule inet ztest post oifname $IFACE_WAN meta mark and 0x40000000 == 0 udp dport 443 ct original packets 1-6 queue num 200 bypass
# auto hostlist with avoiding wrong ACK numbers in RST,ACK packets sent by russian DPI
sysctl net.netfilter.nf_conntrack_tcp_be_liberal=1
nft add chain inet ztest pre "{type filter hook prerouting priority filter;}"
nft add rule inet ztest pre iifname $IFACE_WAN tcp sport "{80,443}" ct reply packets 1-3 queue num 200 bypass
Для задействования IP фрагментации и datanoack на проходящие пакеты требуется особая конфигурация цепочек, перенаправляющая пакеты после NAT. В скриптах zapret эта схема называется POSTNAT , и она возможна только на nftables. Сгенерированные nfqws пакеты требуется на раннем этапе помечать как notrack , чтобы они не были испорчены NAT.
IFACE_WAN=wan
nft create table inet ztest
nft add chain inet ztest postnat "{type filter hook postrouting priority srcnat+1;}"
nft add rule inet ztest postnat oifname $IFACE_WAN meta mark and 0x40000000 == 0 tcp dport "{80,443}" ct original packets 1-6 queue num 200 bypass
nft add rule inet ztest postnat oifname $IFACE_WAN meta mark and 0x40000000 == 0 udp dport 443 ct original packets 1-6 queue num 200 bypass
nft add chain inet ztest predefrag "{type filter hook output priority -401;}"
nft add rule inet ztest predefrag "mark & 0x40000000 != 0x00000000 notrack"
Удаление тестовой таблицы :
nft delete table inet ztest
Если ваше устройство поддерживает аппаратное ускорение (flow offloading, hardware nat, hardware acceleration), то iptables могут не работать. При включенном offloading пакет не проходит по обычному пути netfilter. Необходимо или его отключить, или выборочно им управлять.
В новых ядрах присутствует software flow offloading (SFO). Пакеты, проходящие через SFO, так же проходят мимо большей части механизмов iptables. При включенном SFO работает DNAT/REDIRECT (tpws). Эти соединения исключаются из offloading. Однако, остальные соединения идут через SFO, потому NFQUEUE будет срабатывать только до помещения соединения в flowtable. Практически это означает, что почти весь функционал nfqws работать не будет. Offload включается через специальный target в iptables FLOWOFFLOAD . Не обязательно пропускать весь трафик через offload. Можно исключить из offload соединения, которые должны попасть на tpws или nfqws. openwrt не предусматривает выборочного управления offload. Поэтому скрипты zapret поддерживают свою систему выборочного управления offload в openwrt.
iptables target FLOWOFFLOAD - это проприетарное изобретение openwrt. Управление offload в nftables реализовано в базовом ядре linux без патчей.
tpws - это transparent proxy.
@<config_file>|$<config_file> ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются.
--debug=0|1|2|syslog|@<filename> ; 0,1,2 = логирование на косоль : 0=тихо, 1(default)=подробно, 2=отладка.
--debug-level=0|1|2 ; указать уровень логирования для syslog и @<filename>
--dry-run ; проверить опции командной строки и выйти. код 0 - успешная проверка.
--daemon ; демонизировать прогу
--pidfile=<file> ; сохранить PID в файл
--user=<username> ; менять uid процесса
--uid=uid[:gid] ; менять uid процесса
--bind-addr ; на каком адресе слушать. может быть ipv4 или ipv6 адрес
; если указан ipv6 link local, то требуется указать с какого он интерфейса : fe80::1%br-lan
--bind-linklocal=no|unwanted|prefer|force ; no : биндаться только на global ipv6
; unwanted (default) : предпочтительно global, если нет - LL
; prefer : предпочтительно LL, если нет - global
; force : биндаться только на LL
--bind-iface4=<iface> ; слушать на первом ipv4 интерфейса iface
--bind-iface6=<iface> ; слушать на первом ipv6 интерфейса iface
--bind-wait-ifup=<sec> ; ждать до N секунд появления и поднятия интерфейса
--bind-wait-ip=<sec> ; ждать до N секунд получения IP адреса (если задан --bind-wait-ifup - время идет после поднятия интерфейса)
--bind-wait-ip-linklocal=<sec>
; имеет смысл только при задании --bind-wait-ip
; --bind-linklocal=unwanted : согласиться на LL после N секунд
; --bind-linklocal=prefer : согласиться на global address после N секунд
--bind-wait-only ; подождать все бинды и выйти. результат 0 в случае успеха, иначе не 0.
--connect-bind-addr ; с какого адреса подключаться во внешнюю сеть. может быть ipv4 или ipv6 адрес
; если указан ipv6 link local, то требуется указать с какого он интерфейса : fe80::1%br-lan
; опция может повторяться для v4 и v6 адресов
; опция не отменяет правил маршрутизации ! выбор интерфейса определяется лишь правилами маршрутизации, кроме случая v6 link local.
--socks ; вместо прозрачного прокси реализовать socks4/5 proxy
--no-resolve ; запретить ресолвинг имен через socks5
--resolve-threads ; количество потоков ресолвера
--port=<port> ; на каком порту слушать
--maxconn=<max_connections> ; максимальное количество соединений от клиентов к прокси
--maxfiles=<max_open_files> ; макс количество файловых дескрипторов (setrlimit). мин требование (X*connections+16), где X=6 в tcp proxy mode, X=4 в режиме тамперинга.
; стоит сделать запас с коэффициентом как минимум 1.5. по умолчанию maxfiles (X*connections)*1.5+16
--max-orphan-time=<sec> ; если вы запускаете через tpws торрент-клиент с множеством раздач, он пытается установить очень много исходящих соединений,
; большая часть из которых отваливается по таймауту (юзера сидят за NAT, firewall, ...)
; установление соединения в linux может длиться очень долго. локальный конец отвалился, перед этим послав блок данных,
; tpws ждет подключения удаленного конца, чтобы отослать ему этот блок, и зависает надолго.
; настройка позволяет сбрасывать такие подключения через N секунд, теряя блок данных. по умолчанию 5 сек. 0 означает отключить функцию
; эта функция не действует на успешно подключенные ранее соединения
--local-rcvbuf=<bytes> ; SO_RCVBUF для соединений client-proxy
--local-sndbuf=<bytes> ; SO_SNDBUF для соединений client-proxy
--remote-rcvbuf=<bytes> ; SO_RCVBUF для соединений proxy-target
--remote-sndbuf=<bytes> ; SO_SNDBUF для соединений proxy-target
--nosplice ; не использовать splice на linux системах
--skip-nodelay ; не устанавливать в исходящих соединения TCP_NODELAY. несовместимо со split.
--local-tcp-user-timeout=<seconds> ; таймаут соединений client-proxy (по умолчанию : 10 сек, 0 = оставить системное значение)
--remote-tcp-user-timeout=<seconds> ; таймаут соединений proxy-target (по умолчанию : 20 сек, 0 = оставить системное значение)
--fix-seg=<int> ; исправлять неудачи tcp сегментации ценой задержек для всех клиентов и замедления. ждать до N мс. по умолчанию 30 мс.
--split-pos=N|-N|marker+N|marker-N ; список через запятую маркеров для tcp сегментации
--split-any-protocol ; применять сегментацию к любым пакетам. по умолчанию - только к известным протоколам (http, TLS)
--disorder[=http|tls] ; путем манипуляций с сокетом вынуждает отправлять первым второй сегмент разделенного запроса
--oob[=http|tls] ; отправить байт out-of-band data (OOB) в конце первой части сплита
--oob-data=<char>|0xHEX ; переопределить байт OOB. по умолчанию 0x00.
--hostcase ; менять регистр заголовка "Host:". по умолчанию на "host:".
--hostspell=HoST ; точное написание заголовка Host (можно "HOST" или "HoSt"). автоматом включает --hostcase
--hostdot ; добавление точки после имени хоста : "Host: kinozal.tv."
--hosttab ; добавление табуляции после имени хоста : "Host: kinozal.tvt"
--hostnospace ; убрать пробел после "Host:"
--hostpad=<bytes> ; добавить паддинг-хедеров общей длиной <bytes> перед Host:
--domcase ; домен после Host: сделать таким : TeSt.cOm
--methodspace ; добавить пробел после метода : "GET /" => "GET /"
--methodeol ; добавить перевод строки перед методом : "GET /" => "rnGET /"
--unixeol ; конвертировать 0D0A в 0A и использовать везде 0A
--tlsrec=N|-N|marker+N|marker-N ; разбивка TLS ClientHello на 2 TLS records на указанной позиции. Минимальное смещение - 6.
--mss=<int> ; установить MSS для клиента. может заставить сервер разбивать ответы, но существенно снижает скорость
--tamper-start=[n]<pos> ; начинать дурение только с указанной байтовой позиции или номера блока исходяшего потока (считается позиция начала принятого блока)
--tamper-cutoff=[n]<pos> ; закончить дурение на указанной байтовой позиции или номере блока исходящего потока (считается позиция начала принятого блока)
--hostlist=<filename> ; действовать только над доменами, входящими в список из filename. поддомены автоматически учитываются.
; в файле должен быть хост на каждой строке.
; список читается при старте и хранится в памяти в виде иерархической структуры для быстрого поиска.
; при изменении времени модификации файла он перечитывается автоматически по необходимости
; список может быть запакован в gzip. формат автоматически распознается и разжимается
; списков может быть множество. пустой общий лист = его отсутствие
; хосты извлекаются из Host: хедера обычных http запросов и из SNI в TLS ClientHello.
--hostlist-domains=<domain_list> ; фиксированный список доменов через зяпятую. можно использовать # в начале для комментирования отдельных доменов.
--hostlist-exclude=<filename> ; не применять дурение к доменам из листа. может быть множество листов. схема аналогична include листам.
--hostlist-exclude-domains=<domain_list> ; фиксированный список доменов через зяпятую. можно использовать # в начале для комментирования отдельных доменов.
--hostlist-auto=<filename> ; обнаруживать автоматически блокировки и заполнять автоматический hostlist (требует перенаправления входящего трафика)
--hostlist-auto-fail-threshold=<int> ; сколько раз нужно обнаружить ситуацию, похожую на блокировку, чтобы добавить хост в лист (по умолчанию: 3)
--hostlist-auto-fail-time=<int> ; все эти ситуации должны быть в пределах указанного количества секунд (по умолчанию: 60)
--hostlist-auto-debug=<logfile> ; лог положительных решений по autohostlist. позволяет разобраться почему там появляются хосты.
--new ; начало новой стратегии (новый профиль)
--skip ; не использовать этот профиль . полезно для временной деактивации профиля без удаления параметров.
--filter-l3=ipv4|ipv6 ; фильтр версии ip для текущей стратегии
--filter-tcp=[~]port1[-port2]|* ; фильтр портов tcp для текущей стратегии. ~ означает инверсию. поддерживается список через запятую.
--filter-l7=[http|tls|quic|wireguard|dht|unknown] ; фильтр протокола L6-L7. поддерживается несколько значений через запятую.
--ipset=<filename> ; включающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip. перечитка автоматическая.
--ipset-ip=<ip_list> ; фиксированный список подсетей через запятую. можно использовать # в начале для комментирования отдельных подсетей.
--ipset-exclude=<filename> ; исключающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip. перечитка автоматическая.
--ipset-exclude-ip=<ip_list> ; фиксированный список подсетей через запятую. можно использовать # в начале для комментирования отдельных подсетей.
tpws, как и nfqws, поддерживает множественную сегментацию запросов. Сплит позиции задаются в --split-pos . Указываются маркеры через запятую. Описание маркеров см в разделе nfqws.
На прикладном уровне в общем случае нет гарантированного средства заставить ядро выплюнуть блок данных, порезанным в определенном месте. ОС держит буфер отсылки (SNDBUF) у каждого сокета. Если у сокета включена опция TCP_NODELAY и буфер пуст, то каждый send приводит к отсылке отдельного ip пакета или группы пакетов, если блок не вмещается в один ip пакет. Однако, если в момент send уже имеется неотосланный буфер, то ОС присоединит данные к нему, никакой отсылки отдельным пакетом не будет. Но в этом случае и так нет никакой гарантии, что какой-то блок сообщения пойдет в начале пакета, на что собственно и заточены DPI. Разбиение будет производится согласно MSS, который зависит от MTU исходящего интерфейса. Таким образом DPI, смотрящие в начало поля данных TCP пакета, будут поломаны в любом случае. Протокол http относится к запрос-ответным протоколам. Новое сообщение посылается только тогда, когда сервер получил запрос и полностью вернул ответ. Значит запрос фактически был не только отослан, но и принят другой стороной, а следовательно буфер отсылки пуст, и следующие 2 send приведут к отсылке сегментов данных разными ip пакетами.
Таким образом tpws обеспечивает сплит только за счет раздельных вызовов send, и это обычно работает надежно, если разбивать не на слишком много частей и не на слишком мелкие подряд следующие части. В последнем случае Linux все же может обьединить некоторые части, что приведет к несоответствию реальной сегментации указанным сплит позициям. Другие ОС в этом вопросе ведут себя более предсказуемо. Спонтанного обьединения замечено не было. Поэтому не стоит злоупотреблять сплитами и в особенности мелкими соседними пакетами.
Как показывается практика, проблемы могут начаться , если количество сплит позиций превышает 8. При неудаче сегментации будет выводиться сообщение WARNING ! segmentation failed . Если вы его видите, это повод снизить количество сплит позиций. Если это не вариант, для ядер Linux >=4.6 есть параметр --fix-seg . Он позволяет подождать завершение отсылки перед отправкой следующей части. Но этот вариант ломает модель асинхронной обработки событий. Пока идет ожидание, все остальные соединения не обрабатываются и кратковременно подвисают. На практике это может быть совсем небольшое ожидание - менее 10 мс. И производится оно только , если происходит split, и в ожидании есть реальная необходимость. В высоконагруженных системах данный вариант не рекомендуется. Но для домашнего использования может подойти, и вы эти задержки даже не заметите.
Если вы пытаетесь сплитнуть массивную передачу с --split-any-protocol , когда информация поступает быстрее отсылки, то без --fix-seg ошибки сегментации будут сыпаться сплошным потоком. Работа по массивному потоку без ограничителей --tamper-start и --tamper-cutoff обычно лишена смысла.
tpws работает на уровне сокетов, поэтому длинный запрос, не вмещающийся в 1 пакет (TLS с kyber), он получает целым блоком. На каждую сплит часть он делает отдельный вызов send() . Но ОС не сможет отослать данные в одном пакете, если размер превысит MTU. В случае слишком большого сегмента ОС дополнительно его порежет на более мелкие. Результат должен быть аналогичен nfqws.
--disorder заставляет слать каждый 2-й пакет с TTL=1, начиная с первого. К серверу приходят все четные пакеты сразу. На остальные ОС делает ретрансмиссию, и они приходят потом. Это само по себе создает дополнительную задержку (200 мс в linux для первой ретрансмиссии). Иным способом сделать disorder в сокет варианте не представляется возможным. Итоговый порядок для 6 сегментов получается 2 4 6 1 3 5 .
--oob высылает 1 байт out-of-band data после первого сплит сегмента. oob в каждом сегменте сплита показал себя ненадежным. Сервер получает oob в сокет.
Сочетание oob и disorder возможно только в Linux. Остальные ОС не умеют с таким справляться. Флаг URG теряется при ретрансмиссиях. Сервер получает oob в сокет. Сочетание этих параметров в ос, кроме Linux, вызывает ошибку на этапе запуска.
--tlsrec позволяют внутри одного tcp сегмента разрезать TLS ClientHello на 2 TLS records. Можно использовать стандартный механизм маркеров для задания относительных позиций.
--tlsrec ломает значительное количество сайтов. Криптобиблиотеки (openssl, ...) на оконечных http серверах без проблем принимают разделенные tls сегменты, но мидлбоксы - не всегда. К мидлбоксам можно отнести CDN или системы ddos-защиты. Поэтому применение --tlsrec без ограничителей вряд ли целесообразно. В РФ --tlsrec обычно не работает с TLS 1.2, потому что цензор парсит сертификат сервера из ServerHello. Работает только с TLS 1.3, поскольку там эта информация шифруется. Впрочем, сейчас сайтов, не поддерживающих TLS 1.3, осталось немного.
--mss устанавливает опцию сокета TCP_MAXSEG. Клиент выдает это значение в tcp опциях SYN пакета. Сервер в ответ в SYN,ACK выдает свой MSS. На практике сервера обычно снижают размеры отсылаемых ими пакетов, но они все равно не вписываются в низкий MSS, указанный клиентом. Обычно чем больше указал клиент, тем больше шлет сервер. На TLS 1.2 если сервер разбил заброс так, чтобы домен из сертификата не попал в первый пакет, это может обмануть DPI, секущий ответ сервера. Схема может значительно снизить скорость и сработать не на всех сайтах. С фильтром по hostlist совместимо только в режиме socks при включенном удаленном ресолвинге хостов. (firefox network.proxy.socks_remote_dns). Это единственный вариант, когда tpws может узнать имя хоста еще на этапе установления соединения. Применяя данную опцию к сайтам TLS1.3, если броузер тоже поддерживает TLS1.3, то вы делаете только хуже. Но нет способа автоматически узнать когда надо применять, когда нет, поскольку MSS идет только в 3-way handshake еще до обмена данными, а версию TLS можно узнать только по ответу сервера, который может привести к реакции DPI. Использовать только когда нет ничего лучше или для отдельных ресурсов. Для http использовать смысла нет, поэтому заводите отдельный desync profile с фильтром по порту 443. Работает только на Linux, не работает на BSD и MacOS.
Параметр --hostpad=<bytes> добавляет паддинг-хедеров перед Host: на указанное количество байтов. Если размер <bytes> слишком большой, то идет разбивка на разные хедеры по 2K. Общий буфер приема http запроса - 64K, больший паддинг не поддерживается, да и http сервера такое уже не принимают. Полезно против DPI, выполняющих реассемблинг TCP с ограниченным буфером. Если техника работает, то после некоторого количества bytes http запрос начнет проходить до сайта. Если при этом критический размер padding около MTU, значит скорее всего DPI не выполняет реассемблинг пакетов, и лучше будет использовать обычные опции TCP сегментации. Если все же реассемблинг выполняется, то критический размер будет около размера буфера DPI. Он может быть 4K или 8K, возможны и другие значения.
Работают аналогично nfqws , кроме некоторых моментов. Нет параметра --filter-udp , поскольку tpws udp не поддерживает. Методы нулевой фазы ( --mss ) могут работать по хостлисту в одном единственном случае: если используется режим socks и удаленный ресолвинг хостов через прокси. То есть работоспособность вашей настройки в одном и том же режиме может зависеть от того, применяет ли клиент удаленный ресолвинг. Это может быть неочевидно. В одной программе работает, в другой - нет. Если вы используете профиль с хостлистом , и вам нужен mss, укажите mss в профиле с хостлистом, создайте еще один профиль без хостлиста, если его еще нет, и в нем еще раз укажите mss. Тогда при любом раскладе будет выполняться mss. Используйте curl --socks5 и curl --socks5-hostname для проверки вашей стратегии. Смотрите вывод --debug , чтобы убедиться в правильности настроек.
--debug позволяет выводить подробный лог действий на консоль, в syslog или в файл. Может быть важен порядок следования опций. --debug лучше всего указывать в самом начале. Опции анализируются последовательно. Если ошибка будет при проверке опции, а до анализа --debug еще дело не дошло, то сообщения не будут выведены в файл или syslog. --debug=0|1|2 позволяют сразу в одном параметре включить логирование на консоль и указать уровень. Сохранено для совместимости с более старыми версиями. Для выбора уровня в режиме syslog или file используйте отдельный параметр --debug-level . Если в этих режимах --debug не указывать уровень через --debug-level , то автоматически назначается уровень 1. При логировании в файл процесс не держит файл открытым. Ради каждой записи файл открывается и потом закрывается. Так что файл можно удалить в любой момент, и он будет создан заново при первом же сообщении в лог. Но имейте в виду, что если вы запускаете процесс под root, то будет сменен UID на не-root. В начале на лог файл меняется owner, иначе запись будет невозможна. Если вы потом удалите файл, и у процесса не будет прав на создание файла в его директории, лог больше не будет вестись. Вместо удаления лучше использовать truncate. В шелле это можно сделать через команду ": >filename"
tpws может биндаться на множество интерфейсов и IP адресов (до 32 шт). Порт всегда только один. Параметры --bind-iface* и --bind-addr создают новый бинд. Остальные параметры --bind-* относятся к последнему бинду. Для бинда на все ipv4 укажите --bind-addr "0.0.0.0" , на все ipv6 - "::" . --bind-addr="" - биндаемся на все ipv4 и ipv6. Выбор режима использования link local ipv6 адресов ( fe80::/8 ) :
--bind-iface6 --bind-linklocal=no : сначала приватный адрес fc00::/7, затем глобальный адрес
--bind-iface6 --bind-linklocal=unwanted : сначала приватный адрес fc00::/7, затем глобальный адрес, затем link local.
--bind-iface6 --bind-linklocal=prefer : сначала link local, затем приватный адрес fc00::/7, затем глобальный адрес.
--bind-iface6 --bind-linklocal=force : только link local
Если не указано ни одного бинда, то создается бинд по умолчанию на все адреса всех интерфейсов. Для бинда на конкретный link-local address делаем так : --bind-iface6=fe80::aaaa:bbbb:cccc:dddd%iface-name Параметры --bind-wait* могут помочь в ситуациях, когда нужно взять IP с интерфейса, но его еще нет, он не поднят или не сконфигурирован. В разных системах события ifup ловятся по-разному и не гарантируют, что интерфейс уже получил IP адрес определенного типа. В общем случае не существует единого механизма повеситься на событие типа "на интерфейсе X появился link local address". Для бинда на известный ip, когда еще интерфейс не сконфигурирован, нужно делать так: --bind-addr=192.168.5.3 --bind-wait-ip=20 В режиме transparent бинд возможен на любой несуществующий адрес, в режиме socks - только на существующий.
Параметры rcvbuf и sndbuf позволяют установить setsockopt SO_RCVBUF SO_SNDBUF для локального и удаленного соединения.
--skip-nodelay может быть полезен, когда tpws используется без дурения, чтобы привести MTU к MTU системы, на которой работает tpws. Это может быть полезно для скрытия факта использования VPN. Пониженный MTU - 1 из способов обнаружения подозрительного подключения. С tcp proxy ваши соединения неотличимы от тех, что сделал бы сам шлюз.
--local-tcp-user-timeout и --remote-tcp-user-timeout устанавливают значение таймаута в секундах для соединений клиент-прокси и прокси-сервер. Этот таймаут соответствует опции сокета linux TCP_USER_TIMEOUT. Под таймаутом подразумевается время, в течение которого буферизированные данные не переданы или на переданные данные не получено подтверждение (ACK) от другой стороны. Этот таймаут никак не касается времени отсутствия какой-либо передачи через сокет лишь потому, что данных для передачи нет. Полезно для сокращения время закрытия подвисших соединений. Поддерживается только на Linux и MacOS.
Режим --socks не требует повышенных привилегий (кроме бинда на привилегированные порты 1..1023). Поддерживаются версии socks 4 и 5 без авторизации. Версия протокола распознается автоматически. Подключения к IP того же устройства, на котором работает tpws, включая localhost, запрещены. socks5 позволяет удаленно ресолвить хосты (curl : --socks5-hostname firefox : socks_remote_dns=true). tpws поддерживает эту возможность асинхронно, не блокируя процессинг других соединений, используя многопоточный пул ресолверов. Количество потоков определяется автоматически в зависимости от --maxconn , но можно задать и вручную через параметр --resolver-threads . Запрос к socks выставляется на паузу, пока домен не будет преобразован в ip адрес в одном из потоков ресолвера. Ожидание может быть более длинным, если все потоки заняты. Если задан параметр --no-resolve , то подключения по именам хостов запрещаются, а пул ресолверов не создается. Тем самым экономятся ресурсы.
Для перенаправления tcp соединения на transparent proxy используются команды следующего вида :
iptables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.127:988
iptables -t nat -I PREROUTING -i <внутренний_интерфейс> -p tcp --dport 80 -j DNAT --to 127.0.0.127:988
Первая команда для соединений с самой системы, вторая - для проходящих через роутер соединений.
DNAT на localhost работает в цепочке OUTPUT, но не работает в цепочке PREROUTING без включения параметра route_localnet :
sysctl -w net.ipv4.conf.<внутренний_интерфейс>.route_localnet=1
Можно использовать -j REDIRECT --to-port 988 вместо DNAT, однако в этом случае процесс transparent proxy должен слушать на ip адресе входящего интерфейса или на всех адресах. Слушать на всех - не есть хорошо с точки зрения безопасности. Слушать на одном (локальном) можно, но в случае автоматизированного скрипта придется его узнавать, потом динамически вписывать в команду. В любом случае требуются дополнительные усилия. Использование route_localnet тоже имеет потенциальные проблемы с безопасностью. Вы делаете доступным все, что висит на 127.0.0.0/8 для локальной подсети < внутренний_интерфейс>. Службы обычно привязываются к 127.0.0.1 , поэтому можно средствами iptables запретить входящие на 127.0.0.1 не с интерфейса lo, либо повесить tpws на любой другой IP из из 127.0.0.0/8 , например на 127.0.0.127 , и разрешить входящие не с lo только на этот IP.
iptables -A INPUT ! -i lo -d 127.0.0.127 -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP
Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от самого tpws. tpws запускается под пользователем tpws , для него задается исключающее правило.
IP6Tables work almost in the same way as IPV4, but there are a number of important nuances. In Dnat, you should take the address --to in square brackets. 예를 들어 :
ip6tables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to [::1]:988
Параметра route_localnet не существует для ipv6. DNAT на localhost (::1) возможен только в цепочке OUTPUT. В цепочке PREROUTING DNAT возможен на любой global address или на link local address того же интерфейса, откуда пришел пакет. NFQUEUE работает без изменений.
Базовая конфигурация :
IFACE_WAN=wan
IFACE_LAN=br-lan
sysctl -w net.ipv4.conf.$IFACE_LAN.route_localnet=1
nft create table inet ztest
nft create chain inet ztest localnet_protect
nft add rule inet ztest localnet_protect ip daddr 127.0.0.127 return
nft add rule inet ztest localnet_protect ip daddr 127.0.0.0/8 drop
nft create chain inet ztest input "{type filter hook input priority filter - 1;}"
nft add rule inet ztest input iif != "lo" jump localnet_protect
nft create chain inet ztest dnat_output "{type nat hook output priority dstnat;}"
nft add rule inet ztest dnat_output meta skuid != tpws oifname $IFACE_WAN tcp dport { 80, 443 } dnat ip to 127.0.0.127:988
nft create chain inet ztest dnat_pre "{type nat hook prerouting priority dstnat;}"
nft add rule inet ztest dnat_pre meta iifname $IFACE_LAN tcp dport { 80, 443 } dnat ip to 127.0.0.127:988
Удаление таблицы :
nft delete table inet ztest
!!!!!!! NFTables cannot work with IPSET-am. Own similar mechanism requires a huge amount of RAM !!! To download large sheets. For example, even 256 MB is not enough for a 100K post in NFSET. !!!!!!! If you need large sheets on home routers, roll back to the iPtables+IPSET.
ipset/zapret-hosts-user.txt и запустите ipset/get_user.sh На выходе получите ipset/zapret-ip-user.txt с IP адресами.Cкрипты с названием get_reestr_* оперируют дампом реестра заблокированных сайтов :
ipset/get_reestr_resolve.sh получает список доменов от rublacklist и дальше их ресолвит в ip адреса в файл ipset/zapret-ip.txt.gz. В этом списке есть готовые IP адреса, но судя во всему они там в точности в том виде, что вносит в реестр РосКомПозор. Адреса могут меняться, позор не успевает их обновлять, а провайдеры редко банят по IP : вместо этого они банят http запросы с "нехорошим" заголовком "Host:" вне зависимости от IP адреса. Поэтому скрипт ресолвит все сам, хотя это и занимает много времени. Используется мультипоточный ресолвер mdig (собственная разработка).
ipset/get_reestr_preresolved.sh . то же самое, что и 2), только берется уже заресолвленый список со стороннего ресурса.
ipset/get_reestr_preresolved_smart.sh . то же самое, что и 3), с добавлением всего диапазона некоторых автономных систем (прыгающие IP адреса из cloudflare, facebook, ...) и некоторых поддоменов блокируемых сайтов
Cкрипты с названием get_antifilter_* оперируют списками адресов и масок подсетей с сайтов antifilter.network и antifilter.download :
ipset/get_antifilter_ip.sh . получает лист https://antifilter.download/list/ip.lst.
ipset/get_antifilter_ipsmart.sh . получает лист https://antifilter.network/download/ipsmart.lst. умная суммаризация отдельных адресов из ip.lst по маскам от /32 до /22
ipset/get_antifilter_ipsum.sh . получает лист https://antifilter.download/list/ipsum.lst. суммаризация отдельных адресов из ip.lst по маске /24
ipset/get_antifilter_ipresolve.sh . получает лист https://antifilter.download/list/ipresolve.lst. пре-ресолвленный список, аналогичный получаемый при помощи get_reestr_resolve. только ipv4.
ipset/get_antifilter_allyouneed.sh . получает лист https://antifilter.download/list/allyouneed.lst. Суммарный список префиксов, созданный из ipsum.lst и subnet.lst.
ipset/get_refilter_ipsum.sh . Список берется отсюда : https://github.com/1andrevich/Re-filter-lists
Все варианты рассмотренных скриптов автоматически создают и заполняют ipset. Варианты 2-10 дополнительно вызывают вариант 1.
ipset/get_config.sh . этот скрипт вызывает то, что прописано в переменной GETLIST из файла config Если переменная не определена, то ресолвятся лишь листы для ipset nozapret/nozapret6.Листы РКН все время изменяются. Возникают новые тенденции. Требования к RAM могут меняться. Поэтому необходима нечастая, но все же регулярная ревизия что же вообще у вас происходит на роутере. Или вы можете узнать о проблеме лишь когда у вас начнет постоянно пропадать wifi, и вам придется его перезагружать каждые 2 часа (метод кувалды).
Самые щадящие варианты по RAM - get_antifilter_allyouneed.sh , get_antifilter_ipsum.sh , get_refilter_*.sh .
Листы zapret-ip.txt и zapret-ipban.txt сохраняются в сжатом виде в файлы .gz. Это позволяет снизить их размер во много раз и сэкономить место на роутере. Отключить сжатие листов можно параметром конфига GZIP_LISTS=0.
На роутерах не рекомендуется вызывать эти скрипты чаще раза за 2 суток, поскольку сохранение идет либо во внутреннюю флэш память роутера, либо в случае extroot - на флэшку. В обоих случаях слишком частая запись может убить флэшку, но если это произойдет с внутренней флэш памятью, то вы просто убьете роутер.
Принудительное обновление ipset выполняет скрипт ipset/create_ipset.sh . Если передан параметр no-update , скрипт не обновляет ipset , а только создает его при его отсутствии и заполняет. Это полезно, когда могут случиться несколько последовательных вызовов скрипта. Нет смысла несколько раз перезаполнять ipset , это длительная операция на больших листах. Листы можно обновлять раз в несколько суток, и только тогда вызывать create_ipset без параметра no-update . Во всех остальных случаях стоит применять no-update .
Список РКН уже достиг внушительных размеров в сотни тысяч IP адресов. Поэтому для оптимизации ipset применяется утилита ip2net . Она берет список отдельных IP адресов и пытается интеллектуально создать из него подсети для сокращения количества адресов. ip2net отсекает неправильные записи в листах, гарантируя отсутствие ошибок при их загрузке. ip2net написан на языке C, поскольку операция ресурсоемкая. Иные способы роутер может не потянуть.
Можно внести список доменов в ipset/zapret-hosts-user-ipban.txt . Их ip адреса будут помещены в отдельный ipset ipban . Он может использоваться для принудительного завертывания всех соединений на прозрачный proxy redsocks или на VPN.
IPV6 : если включен ipv6, то дополнительно создаются листы с таким же именем, но с "6" на конце перед расширением. zapret-ip.txt => zapret-ip6.txt Создаются ipset-ы zapret6 и ipban6. Листы с antifilter не содержат список ipv6 адресов.
СИСТЕМА ИСКЛЮЧЕНИЯ IP . Все скрипты ресолвят файл zapret-hosts-user-exclude.txt , создавая zapret-ip-exclude.txt и zapret-ip-exclude6.txt . Они загоняются в ipset-ы nozapret и nozapret6. Все правила, создаваемые init скриптами, создаются с учетом этих ipset. Помещенные в них IP не участвуют в процессе. zapret-hosts-user-exclude.txt может содержать домены, ipv4 и ipv6 адреса или подсети.
FreeBSD . Скрипты ipset/*.sh работают так же на FreeBSD. Вместо ipset они создают lookup таблицы ipfw с аналогичными именами. ipfw таблицы в отличие от ipset могут содержать как ipv4, так и ipv6 адреса и подсети в одной таблице, поэтому разделения нет.
Параметр конфига LISTS_RELOAD задает произвольную команду для перезагрузки листов. Это особенно полезно на BSD системах с PF. LISTS_RELOAD=- отключает перезагрузку листов.
Утилита ip2net предназначена для преобразования ipv4 или ipv6 списка ip в список подсетей с целью сокращения размера списка. Входные данные берутся из stdin, выходные выдаются в stdout .
-4 ; лист - ipv4 (по умолчанию)
-6 ; лист - ipv6
--prefix-length=min[-max] ; диапазон рассматриваемых длин префиксов. например : 22-30 (ipv4), 56-64 (ipv6)
--v4-threshold=mul/div ; ipv4 : включать подсети, в которых заполнено по крайней мере mul/div адресов. например : 3/4
--v6-threshold=N ; ipv6 : минимальное количество ip для создания подсети
В списке могут присутствовать записи вида ip/prefix и ip1-ip2. Такие записи выкидываются в stdout без изменений. Они принимаются командой ipset. ipset умеет для листов hash:net из ip1-ip2 делать оптимальное покрытие ip/prefix. ipfw из FreeBSD понимает ip/prefix, но не понимает ip1-ip2. ip2net фильтрует входные данные, выкидывая неправильные IP адреса.
Выбирается подсеть, в которой присутствует указанный минимум адресов. Для ipv4 минимум задается как процент от размера подсети (mul/div. например, 3/4), для ipv6 минимум задается напрямую.
Размер подсети выбирается следующим алгоритмом: Сначала в указанном диапазоне длин префиксов ищутся подсети, в которых количество адресов - максимально. Если таких сетей найдено несколько, берется наименьшая сеть (префикс больше). Например, заданы параметры v6_threshold=2 prefix_length=32-64, имеются следующие ipv6 :
1234:5678:aaaa::5
1234:5678:aaaa::6
1234:5678:aaac::5
Результат будет :
1234:5678:aaa8::/45
Эти адреса так же входят в подсеть /32. Однако, нет смысла проходиться ковровой бомбардировкой, когда те же самые адреса вполне влезают в /45 и их ровно столько же. Если изменить v6_threshold=4, то результат будет:
1234:5678:aaaa::5
1234:5678:aaaa::6
1234:5678:aaac::5
То есть ip не объединятся в подсеть, потому что их слишком мало. Если изменить prefix_length=56-64 , результат будет:
1234:5678:aaaa::/64
1234:5678:aaac::5
Требуемое процессорное время для вычислений сильно зависит от ширины диапазона длин префиксов, размера искомых подсетей и длины листа. Если ip2net думает слишком долго, не используйте слишком большие подсети и уменьшите диапазон длин префиксов. Учтите, что арифметика mul/div - целочисленная. При превышении разрядной сетки 32 bit результат непредсказуем. Не надо делать такое: 5000000/10000000. 1/2 - гораздо лучше.
Программа предназначена для многопоточного ресолвинга больших листов через системный DNS. Она берет из stdin список доменов и выводит в stdout результат ресолвинга. Ошибки выводятся в stderr.
--threads=<threads_number> ; количество потоков. по умолчанию 1.
--family=<4|6|46> ; выбор семейства IP адресов : ipv4, ipv6, ipv4+ipv6
--verbose ; дебаг-лог на консоль
--stats=N ; выводить статистику каждые N доменов
--log-resolved=<file> ; сохранять успешно отресолвленные домены в файл
--log-failed=<file> ; сохранять неудачно отресолвленные домены в файл
--dns-make-query=<domain> ; вывести в stdout бинарный DNS запрос по домену. если --family=6, запрос будет AAAA, иначе A.
--dns-parse-query ; распарсить бинарный DNS ответ и выдать все ivp4 и ipv6 адреса из него в stdout
Параметры --dns-make-query и --dns-parse-query позволяют провести ресолвинг одного домена через произвольный канал. Например, следующим образом можно выполнить DoH запрос, используя лишь mdig и curl :
mdig --family=6 --dns-make-query=rutracker.org | curl --data-binary @- -H "Content-Type: application/dns-message" https://cloudflare-dns.com/dns-query | mdig --dns-parse-query
Альтернативой ipset является использование tpws или nfqws со списком доменов. Оба демона принимают неограниченное количество листов include ( --hostlist ) и exclude ( --hostlist-exclude ). Прежде всего проверяются exclude листы. При вхождении в них происходит отказ от дурения. Далее при наличии include листов проверяется домен на вхождение в них. При невхождении в список отказ от дурения. Если все include листы пустые, это приравнивается к отсутствию include листов. Ограничение перестает работать. В иных случаях происходит дурение. Нет ни одного списка - дурение всегда. Есть только exclude список - дурение всех, кроме. Есть только include список - дурение только их. Есть оба - дурение только include, кроме exclude.
В системе запуска это обыграно следующим образом. Присутствуют 2 include списка : ipset/zapret-hosts-users.txt.gz или ipset/zapret-hosts-users.txt , ipset/zapret-hosts.txt.gz или ipset/zapret-hosts.txt и 1 exclude список ipset/zapret-hosts-users-exclude.txt.gz или ipset/zapret-hosts-users-exclude.txt
При режимах фильтрации MODE_FILTER=hostlist или MODE_FILTER=autohostlist система запуска передает nfqws или tpws все листы, файлы которых присутствуют. Передача происходит через замену маркеров <HOSTLIST> и <HOSTLIST_NOAUTO> на реальные параметры --hostlist , --hostlist-exclude , --hostlist-auto . Если вдруг листы include присутствуют, но все они пустые, то работа аналогична отсутствию include листа. Файл есть, но не смотря на это дурится все, кроме exclude. Если вам нужен именно такой режим - не обязательно удалять zapret-hosts-users.txt . Достаточно сделать его пустым.
Поддомены учитываются автоматически. Например, строчка "ru" вносит в список " .ru". Строчка " .ru" в списке не сработает.
Список доменов РКН может быть получен скриптами
ipset/get_reestr_hostlist.sh
ipset/get_antizapret_domains.sh
ipset/get_reestr_resolvable_domains.sh
ipset/get_refilter_domains.sh
Он кладется в ipset/zapret-hosts.txt.gz .
При изменении времени модификации файлов списки перечитываются автоматически.
При фильтрации по именам доменов демон должен запускаться без фильтрации по ipset. tpws и nfqws решают нужно ли применять дурение в зависимости от хоста, полученного из протокола прикладного уровня (http, tls, quic). При использовании больших списков, в том числе списка РКН, оцените объем RAM на роутере ! Если после запуска демона RAM под завязку или случаются oom, значит нужно отказаться от таких больших списков.
Этот режим позволяет проанализировать как запросы со стороны клиента, так и ответы от сервера. Если хост еще не находится ни в каких листах и обнаруживается ситуация, похожая на блокировку, происходит автоматическое добавление хоста в список autohostlist как в памяти, так и в файле. nfqws или tpws сами ведут этот файл. Чтобы какой-то хост не смог попась в autohostlist используйте hostlist-exclude . Если он все-же туда попал - удалите запись из файла вручную. Процессы автоматически перечитают файл. tpws / nfqws сами назначают владельцем файла юзера, под которым они работают после сброса привилегий, чтобы иметь возможность обновлять лист.
В случае nfqws данный режим требует перенаправления в том числе и входящего трафика. Крайне рекомендовано использовать ограничитель connbytes , чтобы nfqws не обрабатывал гигабайты. По этой же причине не рекомендуется использование режима на BSD системах. Там нет фильтра connbytes .
На linux системах при использовании nfqws и фильтра connbytes может понадобится : sysctl net.netfilter.nf_conntrack_tcp_be_liberal=1 Было замечено, что некоторые DPI в России возвращают RST с неверным ACK. Это принимается tcp/ip стеком linux, но через раз приобретает статус INVALID в conntrack. Поэтому правила с connbytes срабатывают через раз, не пересылая RST пакет nfqws .
Как вообще могут вести себя DPI, получив "плохой запрос" и приняв решение о блокировке:
nfqws и tpws могут сечь варианты 1-3, 4 они не распознают. Всилу специфики работы с отдельными пакетами или с TCP каналом tpws и nfqws распознают эти ситуации по-разному. Что считается ситуацией, похожей на блокировку :
Чтобы снизить вероятность ложных срабатываний, имеется счетчик ситуаций, похожих на блокировку. Если за определенное время произойдет более определенного их количества, хост считается заблокированным и заносится в autohostlist . По нему сразу же начинает работать стратегия по обходу блокировки. Если в процессе счета вебсайт отвечает без признаков блокировки, счетчик сбрасывается. Вероятно, это был временный сбой сайта.
На практике работа с данным режимом выглядит так. Первый раз пользователь заходит на сайт и получает заглушку, сброс соединения или броузер подвисает, вываливаясь по таймауту с сообщением о невозможности загрузить страницу. Надо долбить F5, принуждая броузер повторять попытки. После некоторой попытки сайт начинает работать, и дальше он будет работать всегда.
С этим режимом можно использовать техники обхода, ломающие значительное количество сайтов. Если сайт не ведет себя как заблокированный, значит обход применен не будет. В противном случае терять все равно нечего. Однако, могут быть временные сбои сервера, приводящие к ситуации, аналогичной блокировке. Могут происходит ложные срабатывания. Если такое произошло, стратегия может начать ломать незаблокированный сайт. Эту ситуацию, увы, придется вам контролировать вручную. Заносите такие домены в ipset/zapret-hosts-user-exclude.txt , чтобы избежать повторения. Чтобы впоследствии разобраться почему домен был занесен в лист, можно включить autohostlist debug log . Он полезен тем, что работает без постоянного просмотра вывода nfqws в режиме debug. В лог заносятся только основные события, ведущие к занесению хоста в лист. По логу можно понять как избежать ложных срабатываний и подходит ли вообще вам этот режим.
Можно использовать один autohostlist с множеством процессов. Все процессы проверяют время модификации файла. Если файл был изменен в другом процессе, происходит его перечитывание. Все процессы должны работать под одним uid, чтобы были права доступа на файл.
Скрипты zapret ведут autohostlist в ipset/zapret-hosts-auto.txt . install_easy.sh при апгрейде zapret сохраняет этот файл. Режим autohostlist включает в себя режим hostlist . Можно вести ipset/zapret-hosts-user.txt , ipset/zapret-hosts-user-exclude.txt .
Перед настройкой нужно провести исследование какую бяку устроил вам ваш провайдер.
Нужно выяснить не подменяет ли он DNS и какой метод обхода DPI работает. В этом вам поможет скрипт blockcheck.sh .
Если DNS подменяется, но провайдер не перехватывает обращения к сторонним DNS, поменяйте DNS на публичный. Например: 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1, 9.9.9.9 Если DNS подменяется и провайдер перехватывает обращения к сторонним DNS, настройте dnscrypt . Еще один эффективный вариант - использовать ресолвер от yandex 77.88.8.88 на нестандартном порту 1253. Многие провайдеры не анализируют обращения к DNS на нестандартных портах. blockcheck если видит подмену DNS автоматически переключается на DoH сервера.
Следует прогнать blockcheck по нескольким заблокированным сайтам и выявить общий характер блокировок. Разные сайты могут быть заблокированы по-разному, нужно искать такую технику, которая работает на большинстве. Чтобы записать вывод blockcheck.sh в файл, выполните: ./blockcheck.sh | tee /tmp/blockcheck.txt .
Проанализируйте какие методы дурения DPI работают, в соответствии с ними настройте /opt/zapret/config .
Имейте в виду, что у провайдеров может быть несколько DPI или запросы могут идти через разные каналы по методу балансировки нагрузки. Балансировка может означать, что на разных ветках разные DPI или они находятся на разных хопах. Такая ситуация может выражаться в нестабильности работы обхода. Дернули несколько раз curl. То работает, то connection reset или редирект. blockcheck.sh выдает странноватые результаты. То split работает на 2-м. хопе, то на 4-м. Достоверность результата вызывает сомнения. В этом случае задайте несколько повторов одного и того же теста. Тест будет считаться успешным только, если все попытки пройдут успешно.
При использовании autottl следует протестировать как можно больше разных доменов. Эта техника может на одних провайдерах работать стабильно, на других потребуется выяснить при каких параметрах она стабильна, на третьих полный хаос, и проще отказаться.
Blockcheck имеет 3 уровня сканирования.
quick - максимально быстро найти хоть что-то работающее.standard дает возможность провести исследование как и на что реагирует DPI в плане методов обхода.force дает максимум проверок даже в случаях, когда ресурс работает без обхода или с более простыми стратегиями.Есть ряд других параметров, которые не будут спрашиваться в диалоге, но которые можно переопределить через переменные.
CURL - замена программы curl
CURL_MAX_TIME - время таймаута curl в секундах
CURL_MAX_TIME_QUIC - время таймаута curl для quic. если не задано, используется значение CURL_MAX_TIME
CURL_CMD=1 - показывать команды curl
CURL_OPT - дополнительные параметры curl. `-k` - игнор сертификатов. `-v` - подробный вывод протокола
DOMAINS - список тестируемых доменов через пробел
HTTP_PORT, HTTPS_PORT, QUIC_PORT - номера портов для соответствующих протоколов
SKIP_DNSCHECK=1 - отказ от проверки DNS
SKIP_TPWS=1 - отказ от тестов tpws
SKIP_PKTWS=1 - отказ от тестов nfqws/dvtws/winws
PKTWS_EXTRA, TPWS_EXTRA - дополнительные параметры nfqws/dvtws/winws и tpws
PKTWS_EXTRA_1 .. PKTWS_EXTRA_9, TPWS_EXTRA_1 .. TPWS_EXTRA_9 - отдельно дополнительные параметры, содержащие пробелы
SECURE_DNS=0|1 - принудительно выключить или включить DoH
DOH_SERVERS - список URL DoH через пробел для автоматического выбора работающего сервера
DOH_SERVER - конкретный DoH URL, отказ от поиска
UNBLOCKED_DOM - незаблокированный домен, который используется для тестов IP block
Пример запуска с переменными:
SECURE_DNS=1 SKIP_TPWS=1 CURL_MAX_TIME=1 CURL=/tmp/curl ./blockcheck.sh
СКАН ПОРТОВ
Если в системе присутствует совместимый netcat (ncat от nmap или openbsd ncat. в openwrt по умолчанию нет), то выполняется сканирование портов http или https всех IP адресов домена. Если ни один IP не отвечает, то результат очевиден. Можно останавливать сканирование. Автоматически оно не остановится, потому что netcat-ы недостаточно подробно информируют о причинах ошибки. Если доступна только часть IP, то можно ожидать хаотичных сбоев, т.к. подключение идет к случайному адресу из списка.
ПРОВЕРКА НА ЧАСТИЧНЫЙ IP block
Под частичным блоком подразумевается ситуация, когда коннект на порты есть, но по определенному транспортному или прикладному протоколу всегда идет реакция DPI вне зависимости от запрашиваемого домена. Эта проверка так же не выдаст автоматического вердикта/решения, потому что может быть очень много вариаций. Вместо этого анализ происходящего возложен на самого пользователя или тех, кто будет читать лог. Суть этой проверки в попытке дернуть неблокированный IP с блокированным доменом и наоборот, анализируя при этом реакцию DPI. Реакция DPI обычно проявляется в виде таймаута (зависание запроса), connection reset или http redirect на заглушку. Любой другой вариант скорее всего говорит об отсутствии реакции DPI. В частности, любые http коды, кроме редиректа, ведущего именно на заглушку, а не куда-то еще. На TLS - ошибки handshake без задержек. Ошибка сертификата может говорить как о реакции DPI с MiTM атакой (подмена сертификата), так и о том, что принимающий сервер неблокированного домена все равно принимает ваш TLS handshake с чужим доменом, пытаясь при этом выдать сертификат без запрошенного домена. Требуется дополнительный анализ. Если на заблокированный домен есть реакция на всех IP адресах, значит есть блокировка по домену. Если на неблокированный домен есть реакция на IP адресах блокированного домена, значит имеет место блок по IP. Соответственно, если есть и то, и другое, значит есть и блок по IP, и блок по домену. Неблокированный домен первым делом проверяется на доступность на оригинальном адресе. При недоступности тест отменяется, поскольку он будет неинформативен.
Если выяснено, что есть частичный блок по IP на DPI, то скорее всего все остальные тесты будут провалены вне зависимости от стратегий обхода. Но бывают и некоторые исключения. Например, пробитие через ipv6 option headers . Или сделать так, чтобы он не мог распознать протокол прикладного уровня. Дальнейшие тесты могут быть не лишены смысла.
ПРИМЕРЫ БЛОКИРОВКИ ТОЛЬКО ПО ДОМЕНУ БЕЗ БЛОКА ПО IP
> testing iana.org on it's original
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
curl: (28) Operation timed out after 1002 milliseconds with 0 bytes received
> testing iana.org on 172.67.182.196 (rutracker.org)
HTTP/1.1 409 Conflict
> testing iana.org on 104.21.32.39 (rutracker.org)
HTTP/1.1 409 Conflict
> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
curl: (28) Connection timed out after 1001 milliseconds
> testing iana.org on 172.67.182.196 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure
> testing iana.org on 104.21.32.39 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure
> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
HTTP/1.1 307 Temporary Redirect
Location: https://www.gblnet.net/blocked.php
> testing iana.org on 172.67.182.196 (rutracker.org)
HTTP/1.1 409 Conflict
> testing iana.org on 104.21.32.39 (rutracker.org)
HTTP/1.1 409 Conflict
> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
curl: (35) Recv failure: Connection reset by peer
> testing iana.org on 172.67.182.196 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure
> testing iana.org on 104.21.32.39 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure
ПРИМЕР ПОЛНОГО IP БЛОКА ИЛИ БЛОКА TCP ПОРТА ПРИ ОТСУТСТВИИ БЛОКА ПО ДОМЕНУ
* port block tests ipv4 startmail.com:80
ncat -z -w 1 145.131.90.136 80
145.131.90.136 does not connect. netcat code 1
ncat -z -w 1 145.131.90.152 80
145.131.90.152 does not connect. netcat code 1
* curl_test_http ipv4 startmail.com
- checking without DPI bypass
curl: (28) Connection timed out after 2002 milliseconds
UNAVAILABLE code=28
- IP block tests (requires manual interpretation)
> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing startmail.com on 192.0.43.8 (iana.org)
HTTP/1.1 302 Found
Location: https://www.iana.org/
> testing iana.org on 145.131.90.136 (startmail.com)
curl: (28) Connection timed out after 2002 milliseconds
> testing iana.org on 145.131.90.152 (startmail.com)
curl: (28) Connection timed out after 2002 milliseconds
Файл /opt/zapret/config используется различными компонентами системы и содержит основные настройки. Его нужно просмотреть и при необходимости отредактировать.
На linux системах можно выбрать использовать iptables или nftables . По умолчанию на традиционных linux выбирается nftables , если установлен nft. На openwrt по умолчанию выбирается nftables на новых версиях с firewall4.
FWTYPE=iptables
На nftables можно отключить стандартную схему перехвата трафика после NAT и перейти на перехват до NAT. Это сделает невозможным применение некоторых методов дурения на проходящем трафике как в случае с iptables . nfqws начнет получать адреса пакетов из локальной сети и отображать их в логах.
POSTNAT=0
Существует 3 стандартных опции запуска, настраиваемых раздельно и независимо: tpws-socks , tpws , nfqws . Их можно использовать как по отдельности, так и вместе. Например, вам надо сделать комбинацию из методов, доступных только в tpws и только в nfqws . Их можно задействовать вместе. tpws будет прозрачно локализовывать трафик на системе и применять свое дурение, nfqws будет дурить трафик, исходящий с самой системы после обработки на tpws . А можно на эту же систему повесить без параметров socks proxy, чтобы получать доступ к обходу блокировок через прокси. Таким образом, все 3 режима вполне могут задействоваться вместе. Так же безусловно и независимо, в добавок к стандартным опциям, применяются все custom скрипты в init.d/{sysv,openwrt,macos}/custom.d .
Однако, при комбинировании tpws и nfqws с пересечением по L3/L4 протоколам не все так просто , как может показаться на первый взгляд. Первым всегда работает tpws, за ним - nfqws. На nfqws попадает уже "задуренный" трафик от tpws. Получается, что дурилка дурит дурилку, и дурилка не срабатывает, потому что ее задурили. Вот такой веселый момент. nfqws перестает распознавать протоколы и применять методы. Некоторые методы дурения от tpws nfqws в состоянии распознать и отработать корректно, но большинство - нет. Решение - использование --dpi-desync-any-protocol в nfqws и работа как с неизвестным протоколом. Комбинирование tpws и nfqws является продвинутым вариантом, требующим глубокого понимания происходящего. Очень желательно проанализировать действия nfqws по --debug логу. Все ли так, как вы задумали.
Одновременное использование tpws и nfqws без пересечения по L3/L4 (то есть nfqws - udp, tpws - tcp или nfqws - port 443, tpws - port 80 или nfqws - ipv4, tpws - ipv6) проблем не представляет.
tpws-socks требует настройки параметров tpws , но не требует перехвата трафика. Остальные опции требуют раздельно настройки перехвата трафика и опции самих демонов. Каждая опция предполагает запуск одного инстанса соответствующего демона. Все различия методов дурения для http , https , quic и т.д. должны быть отражены через схему мультистратегий. В этом смысле настройка похожа на вариант winws на Windows, а перенос конфигов не должен представлять больших сложностей. Основное правило настройки перехвата - перехватывайте только необходимый минимум. Любой перехват лишнего - это бессмысленная нагрузка на вашу систему. Опции демонов --ipset использовать запрещено. Это сделано намеренно и искусственно, чтобы не поощрять простой и работающий, но неэффективный метод на *nix системах. Используйте ipset -ы режима ядра. При необходимости пишите и задействуйте custom scripts . Настройки демонов можно для удобства писать на нескольких строках, используя двойные или одинарные кавычки. Чтобы задействовать стандартные обновляемые хост-листы из ipset , используйте маркер . Он будет заменен на параметры, соответствующие режиму MODE_FILTER, и будут подставлены реально существующие файлы. Если MODE_FILTER не предполагает стандартного хостлиста, будет заменен на пустую строку. Стандартные хостлисты следует вставлять в финальных стратегиях (стратегиях по умолчанию), закрывающих цепочки по группе параметров фильтра. Таких мест может быть несколько. Не нужно использовать в узких специализациях и в тех профилях, по которым точно не будет проходить трафик с известными протоколами, откуда поддерживается извлечение имени хоста ( http , tls , quic ). <HOSTLIST_NOAUTO> - это вариация, при которой стандартный автолист используется как обычный. То есть на этом профиле не происходит автоматическое добавление заблокированных доменов. Но если на другом профиле что-то будет добавлено, то этот профиль примет изменения автоматически.
Включение стандартной опции tpws в режиме socks
TPWS_SOCKS_ENABLE=0
На каком порту будет слушать tpws socks. прослушивается только localhost и LAN
TPPORT_SOCKS=987
Параметры tpws для режима socks
TPWS_SOCKS_OPT="
--filter-tcp=80 --methodeol <HOSTLIST> --new
--filter-tcp=443 --split-pos=1,midsld --disorder <HOSTLIST>"
Включение стандартной опции tpws в прозрачном режиме
TPWS_ENABLE=0
Какие tcp порты следует перенаправлять на tpws
TPWS_PORTS=80,443
Параметры tpws для прозрачного режима
TPWS_OPT="
--filter-tcp=80 --methodeol <HOSTLIST> --new
--filter-tcp=443 --split-pos=1,midsld --disorder <HOSTLIST>"
Включение стандартной опции nfqws
NFQWS_ENABLE=0
Какие tcp и udp порты следует перенаправлять на nfqws с использованием connbytes ограничителя
connbytes позволяет из каждого соединения перенаправить только заданное количество начальных пакетов по каждому направлению - на вход и на выход. Это более эффективная kernel-mode замена параметра nfqws --dpi-desync-cutoff=nX .
NFQWS_PORTS_TCP=80,443
NFQWS_PORTS_UDP=443
Сколько начальных входящих и исходящих пакетов нужно перенаправлять на nfqws по каждому направлению
NFQWS_TCP_PKT_OUT=$((6+$AUTOHOSTLIST_RETRANS_THRESHOLD))
NFQWS_TCP_PKT_IN=3
NFQWS_UDP_PKT_OUT=$((6+$AUTOHOSTLIST_RETRANS_THRESHOLD))
NFQWS_UDP_PKT_IN=0
Задать порты для перенаправления на nfqws без connbytes ограничителя
Есть трафик, исходящий сеанс для которого необходимо перенаправлять весь без ограничителей. Типичное применение - поддержка http keepalives на stateless DPI. Это существенно нагружает процессор. Использовать только если понимаете зачем. Чаще всего это не нужно. Входящий трафик ограничивается по connbytes через параметры PKT_IN. Если указываете здесь какие-то порты, желательно их убрать из версии с connbytes ограничителем
NFQWS_PORTS_TCP_KEEPALIVE=80
NFQWS_PORTS_UDP_KEEPALIVE=
Параметры nfqws
NFQWS_OPT="
--filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-split-pos=method+2 --dpi-desync-fooling=md5sig <HOSTLIST> --new
--filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-fooling=badseq,md5sig <HOSTLIST> --new
--filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 <HOSTLIST_NOAUTO>
Режим фильтрации хостов:
none - применять дурение ко всем хостам
ipset - ограничить дурение ipset-ом zapret/zapret6
hostlist - ограничить дурение списком хостов из файла
autohostlist - режим hostlist + распознавание блокировок и ведение автоматического листа
MODE_FILTER=none
Настройка системы управления выборочным traffic offload (только если поддерживается)
donttouch: выборочное управление отключено, используется системная настройка, простой инсталлятор выключает системную настройку, если она не совместима с выбранным режимом
none: выборочное управление отключено, простой инсталлятор выключает системную настройку
software: выборочное управление включено в режиме software, простой инсталлятор выключает системную настройку
hardware: выборочное управление включено в режиме hardware, простой инсталлятор выключает системную настройку
FLOWOFFLOAD=donttouch
Параметр GETLIST указывает инсталлятору install_easy.sh какой скрипт дергать для обновления списка заблокированных ip или хостов. Он же вызывается через get_config.sh из запланированных заданий (crontab или systemd timer). Поместите сюда название скрипта, который будете использовать для обновления листов. Если не нужно, то параметр следует закомментировать.
Можно индивидуально отключить ipv4 или ipv6. Если параметр закомментирован или не равен "1", использование протокола разрешено.
DISABLE_IPV4=1
DISABLE_IPV6=1
Количество потоков для многопоточного DNS ресолвера mdig (1..100). Чем их больше, тем быстрее, но не обидится ли на долбежку ваш DNS сервер?
MDIG_THREADS=30
Место для хранения временных файлов. При скачивании огромных реестров в /tmp места может не хватить. Если файловая система на нормальном носителе (не встроенная память роутера), то можно указать место на флэшке или диске. TMPDIR=/opt/zapret/tmp
Опции для создания ipset-ов и nfset-ов
SET_MAXELEM=262144
IPSET_OPT="hashsize 262144 maxelem 2097152"
Хук, позволяющий внести ip адреса динамически. $1 = имя таблицы
Адреса выводятся в stdout. В случае nfset автоматически решается проблема возможного пересечения интервалов.
IPSET_HOOK="/etc/zapret.ipset.hook"
ПРО РУГАНЬ в dmesg по поводу нехватки памяти.
Может так случиться, что памяти в системе достаточно, но при попытке заполнить огромный ipset ядро начинает громко ругаться, ipset заполняется не полностью.
Вероятная причина в том, что превышается hashsize , заданный при создании ipset (create_ipset.sh). Происходит переаллокация списка, не находится непрерывных фрагментов памяти нужной длины. Это лечится увеличением hashsize . Но чем больше hashsize , тем больше занимает ipset в памяти. Задавать слишком большой hashsize для недостаточно больших списков нецелесообразно.
Опции для вызова ip2net. Отдельно для листов ipv4 и ipv6.
IP2NET_OPT4="--prefix-length=22-30 --v4-threshold=3/4"
IP2NET_OPT6="--prefix-length=56-64 --v6-threshold=5"
Настройка режима autohostlist.
При увеличении AUTOHOSTLIST_RETRANS_THRESHOLD и использовании nfqws следует пересмотреть значения параметров NFQWS_TCP_PKT_OUT и NFQWS_UDP_PKT_OUT. Все ретрансмиссии должны быть получены nfqws, иначе триггер "зависание запроса" не сработает.
AUTOHOSTLIST_RETRANS_THRESHOLD=3
AUTOHOSTLIST_FAIL_THRESHOLD=3
AUTOHOSTLIST_FAIL_TIME=60
AUTOHOSTLIST_DEBUG=0
Включить или выключить сжатие больших листов в скриптах ipset/*.sh.
GZIP_LISTS=1
Команда для перезагрузки ip таблиц фаервола.
Если не указано или пустое, выбирается автоматически ipset или ipfw при их наличии. На BSD системах с PF нет автоматической загрузки. Там нужно указать команду явно: pfctl -f /etc/pf.conf На более новых pfctl (есть в новых FreeBSD, нет в OpenBSD 6.8) можно дать команду загрузки только таблиц: pfctl -Tl -f /etc/pf.conf "-" означает отключение загрузки листов даже при наличии поддерживаемого backend.
LISTS_RELOAD="pfctl -f /etc/pf.conf"
LISTS_RELOAD=-
В openwrt существует сеть по умолчанию 'lan'. Только трафик с этой сети будет перенаправлен на tpws. Но возможно задать другие сети или список сетей:
OPENWRT_LAN="lan lan2 lan3"
В openwrt в качестве wan берутся интерфейсы, имеющие default route. Отдельно для ipv4 и ipv6. Это можно переопределить:
OPENWRT_WAN4="wan4 vpn"
OPENWRT_WAN6="wan6 vpn6"
Параметр INIT_APPLY_FW=1 разрешает init скрипту самостоятельно применять правила iptables.
При иных значениях или если параметр закомментирован, правила применены не будут.
Это полезно, если у вас есть система управления фаерволом, в настройки которой и следует прикрутить правила.
На openwrt неприменимо при использовании firewall3+iptables.
Следующие настройки не актуальны для openwrt:
Если ваша система работает как роутер, то нужно вписать названия внутренних и внешних интерфейсов:
IFACE_LAN=eth0
IFACE_WAN=eth1
IFACE_WAN6="henet ipsec0"
Несколько интерфейсов могут быть вписаны через пробел. Если IFACE_WAN6 не задан, то берется значение IFACE_WAN.
중요한
Настройка маршрутизации, маскарада и т.д. не входит в задачу zapret. Включаются только режимы, обеспечивающие перехват транзитного трафика. Возможно определить несколько интерфейсов следующим образом:
IFACE_LAN="eth0 eth1 eth2"
Если вы используете какую-то систему управления фаерволом, то она может вступать в конфликт с имеющимся скриптом запуска. При повторном применении правил она могла бы поломать настройки iptables от zapret. В этом случае правила для iptables должны быть прикручены к вашему фаерволу отдельно от запуска tpws или nfqws.
Следующие вызовы позволяют применить или убрать правила iptables отдельно:
/opt/zapret/init.d/sysv/zapret start_fw
/opt/zapret/init.d/sysv/zapret stop_fw
/opt/zapret/init.d/sysv/zapret restart_fw
А так можно запустить или остановить демоны отдельно от фаервола:
/opt/zapret/init.d/sysv/zapret start_daemons
/opt/zapret/init.d/sysv/zapret stop_daemons
/opt/zapret/init.d/sysv/zapret restart_daemons
nftables сводят практически на нет конфликты между разными системами управления, поскольку позволяют использовать независимые таблицы и хуки. Используется отдельная nf-таблица "zapret". Если ваша система ее не будет трогать, скорее всего все будет нормально.
Для nftables предусмотрено несколько дополнительных вызовов:
Посмотреть set-ы интерфейсов, относящихся к lan, wan и wan6. По ним идет завертывание трафика. А так же таблицу flow table с именами интерфейсов ingress hook.
/opt/zapret/init.d/sysv/zapret list_ifsets
Обновить set-ы интерфейсов, относящихся к lan, wan и wan6. Для традиционных linux список интерфейсов берется из переменных конфига IFACE_LAN, IFACE_WAN. Для openwrt определяется автоматически. Множество lanif может быть расширено параметром OPENWRT_LAN. Все интерфейсы lan и wan так же добавляются в ingress hook от flow table.
/opt/zapret/init.d/sysv/zapret reload_ifsets
Просмотр таблицы без содержимого set-ов. Вызывает nft -t list table inet zapret
/opt/zapret/init.d/sysv/zapret list_table
Так же возможно прицепиться своим скриптом к любой стадии применения и снятия фаервола со стороны zapret скриптов:
INIT_FW_PRE_UP_HOOK="/etc/firewall.zapret.hook.pre_up"
INIT_FW_POST_UP_HOOK="/etc/firewall.zapret.hook.post_up"
INIT_FW_PRE_DOWN_HOOK="/etc/firewall.zapret.hook.pre_down"
INIT_FW_POST_DOWN_HOOK="/etc/firewall.zapret.hook.post_down"
Эти настройки доступны в config. Может быть полезно, если вам нужно использовать nftables set-ы, например ipban / ipban6 . nfset-ы принадлежат только одной таблице, следовательно вам придется писать правила для таблицы zapret, а значит нужно синхронизироваться с применением/снятием правил со стороны zapret скриптов.
custom скрипты - это маленькие shell программы, управляющие нестандартными режимами применения zapret или частными случаями, которые не могут быть интегрированы в основную часть без загромождения и замусоривания кода. Для применеия custom следует помещать файлы в следующие директории в зависимости от вашей системы:
/opt/zapret/init.d/sysv/custom.d
/opt/zapret/init.d/openwrt/custom.d
/opt/zapret/init.d/macos/custom.d
Директория будет просканирована в алфавитном порядке, и каждый скрипт будет применен.
В init.d имеется custom.d.examples.linux , в init.d/macos - custom.d.examples . Это готовые скрипты, которые можно копировать в custom.d . Их можно взять за основу для написания собственных.
Для linux пишется код в функции
zapret_custom_daemons
zapret_custom_firewall
zapret_custom_firewall_nft
zapret_custom_firewall_nft_flush
Для macos
zapret_custom_daemons
zapret_custom_firewall_v4
zapret_custom_firewall_v6
zapret_custom_daemons поднимает демоны nfqws / tpws в нужном вам количестве и с нужными вам параметрами. В первом параметре передается код операции: 1 = запуск, 0 = останов. Схема запуска демонов в openwrt отличается - используется procd. Поэтому логика останова отсутствует за ненадобностью, останов никогда не вызывается.
zapret_custom_firewall поднимает и убирает правила iptables . В первом параметре передается код операции: 1 = запуск, 0 = останов.
zapret_custom_firewall_nft поднимает правила nftables. Логика останова отсутствует за ненадобностью. Стандартные цепочки zapret удаляются автоматически. Однако, sets и правила из ваших собственных цепочек не удаляются. Их нужно подчистить в zapret_custom_firewall_nft_flush. Если set-ов и собственных цепочек у вас нет, функцию можно не определять или оставить пустой.
Если вам не нужны iptables или nftables - можете не писать соответствующую функцию.
В linux можно использовать локальные переменные FW_EXTRA_PRE и FW_EXTRA_POST .
FW_EXTRA_PRE добавляет код к правилам ip/nf tables до кода, генерируемого функциями-хелперами.
FW_EXTRA_POST добавляет код после.
В linux функции-хелперы добавляют правило в начало цепочек, то есть перед уже имеющимися. Поэтому специализации должны идти после более общих вариантов. Для macos правило обратное. Там правила добавляются в конец. По этой же причине фаервол в Linux сначала применяется в стандартном режиме, потом custom, а в MacOS сначала custom, потом стандартный режим.
В macos firewall-функции ничего сами никуда не заносят. Их задача - лишь выдать текст в stdout, содержащий правила для pf-якоря. Остальное сделает обертка.
Особо обратите внимание на номер демона в функциях run_daemon , do_daemon , do_tpws , do_tpws_socks , do_nfqws , номера портов tpws и очередей nfqueue . Они должны быть уникальными во всех скриптах. При накладке будет ошибка. Поэтому используйте функции динамического получения этих значений из пула.
custom скрипты могут использовать переменные из config . Можно помещать в config свои переменные и задействовать их в скриптах. Можно использовать функции-хелперы. Они являются частью общего пространства функций shell. Полезные функции можно взять из примеров скриптов. Так же смотрите common/*.sh . Используя хелпер функции, вы избавитесь от необходимости учитывать все возможные случаи типа наличия/отсутствия ipv6, является ли система роутером, имена интерфейсов, ...Хелперы это учитывают. Вам нужно сосредоточиться лишь на фильтрах {ip,nf}tables и параметрах демонов.
install_easy.sh автоматизирует ручные варианты процедур установки. Он поддерживает OpenWRT, linux системы на базе systemd или openrc и MacOS.
Для более гибкой настройки перед запуском инсталлятора следует выполнить раздел "Выбор параметров".
Если система запуска поддерживается, но используется не поддерживаемый инсталлятором менеджер пакетов или названия пакетов не соответствуют прописанным в инсталлятор, пакеты нужно установить вручную. Всегда требуется curl. ipset - только для режима iptables , для nftables - не нужен.
Для совсем обрезанных дистрибутивов (alpine) требуется отдельно установить iptables и ip6tables , либо nftables .
В комплекте идут статические бинарники для большинства архитектур. Какой-то из них подойдет с вероятностью 99%. Но если у вас экзотическая система, инсталлятор попробует собрать бинарники сам через make. Для этого нужны gcc, make и необходимые -dev пакеты. Можно форсировать режим компиляции следующим вызовом:
install_easy.sh make
Под openwrt все уже сразу готово для использования системы в качестве роутера. Имена интерфейсов WAN и LAN известны из настроек системы. Под другими системами роутер вы настраиваете самостоятельно. Инсталлятор в это не вмешивается. инсталлятор в зависимости от выбранного режима может спросить LAN и WAN интерфейсы. Нужно понимать, что заворот проходящего трафика на tpws в прозрачном режиме происходит до выполнения маршрутизации, следовательно возможна фильтрация по LAN и невозможна по WAN. Решение о завороте на tpws локального исходящего трафика принимается после выполнения маршрутизации, следовательно ситуация обратная: LAN не имеет смысла, фильтрация по WAN возможна. Заворот на nfqws происходит всегда после маршрутизации, поэтому к нему применима только фильтрация по WAN. Возможность прохождения трафика в том или ином направлении настраивается вами в процессе конфигурации роутера.
Деинсталляция выполняется через uninstall_easy.sh . После выполнения деинсталляции можно удалить каталог /opt/zapret .
Работает только если у вас на роутере достаточно места.
Копируем zapret на роутер в /tmp .
Запускаем установщик:
sh /tmp/zapret/install_easy.sh
Он скопирует в /opt/zapret только необходимый минимум файлов.
После успешной установки можно удалить zapret из tmp для освобождения RAM:
rm -r /tmp/zapret
Для более гибкой настройки перед запуском инсталлятора следует выполнить раздел "Выбор параметров".
Система простой инсталяции заточена на любое умышленное или неумышленное изменение прав доступа на файлы. Устойчива к репаку под windows. После копирования в /opt права будут принудительно восстановлены.
Требуется около 120-200 кб на диске. Придется отказаться от всего, кроме tpws .
Инструкция для openwrt 22 и выше с nftables
Никаких зависимостей устанавливать не нужно.
설치:
init.d/openwrt-minimal/tpws/* в корень openwrt./usr/bin/tpws .chmod 755 /etc/init.d/tpws /usr/bin/tpws/etc/config/tpws/etc/nftables.d/90-tpws.nft и закомментируйте строки с редиректом ipv6./etc/init.d/tpws enable/etc/init.d/tpws startfw4 restartПолное удаление:
/etc/init.d/tpws disable/etc/init.d/tpws stoprm -f /etc/nftables.d/90-tpws.nft /etc/firewall.user /etc/init.d/tpws /usr/bin/tpwsfw4 restartИнструкция для openwrt 21 и ниже с iptables
Установите зависимости:
opkg updateopkg install iptables-mod-extraopkg install ip6tables-mod-nat Убедитесь, что в /etc/firewall.user нет ничего значимого. Если есть - не следуйте слепо инструкции. Объедините код или создайте свой firewall include в /etc/config/firewall .
설치:
init.d/openwrt-minimal/tpws/* в корень openwrt./usr/bin/tpws .chmod 755 /etc/init.d/tpws /usr/bin/tpws/etc/config/tpws/etc/init.d/tpws enable/etc/init.d/tpws startfw3 restartПолное удаление:
/etc/init.d/tpws disable/etc/init.d/tpws stoprm -f /etc/nftables.d/90-tpws.nft /etc/firewall.user /etc/init.d/tpwstouch /etc/firewall.userfw3 restart Без рута забудьте про nfqws и tpws в режиме transparent proxy. tpws будет работать только в режиме --socks .
Ядра Android имеют поддержку NFQUEUE. nfqws работает.
В стоковых ядрах нет поддержки ipset. В общем случае сложность задачи по поднятию ipset варьируется от "не просто" до "почти невозможно". Если только вы не найдете готовое собранное ядро под ваш девайс.
tpws будет работать в любом случае, он не требует чего-либо особенного.
Хотя linux варианты под Android работают, рекомендуется использовать специально собранные под bionic бинарники. У них не будет проблем с DNS, с локальным временем и именами юзеров и групп.
Рекомендуется использовать gid 3003 (AID_INET). Иначе можете получить permission denied на создание сокета. Например: --uid 1:3003
В iptables укажите: ! --uid-owner 1 вместо ! --uid-owner tpws .
Напишите шелл скрипт с iptables и tpws, запускайте его средствами вашего рут менеджера. Скрипты автозапуска лежат тут:
magisk : /data/adb/service.d
supersu: /system/su.d
nfqws может иметь такой глюк. При запуске с uid по умолчанию (0x7FFFFFFF) при условии работы на сотовом интерфейсе и отключенном кабеле внешнего питания система может частично виснуть. Перестает работать тач и кнопки, но анимация на экране может продолжаться. Если экран был погашен, то включить его кнопкой power невозможно. Изменение UID на низкий (--uid 1 подойдет) позволяет решить эту проблему. Глюк был замечен на android 8.1 на девайсе, основанном на платформе mediatek.
Ответ на вопрос куда поместить tpws на android без рута, чтобы потом его запускать из приложений. Файл заливаем через adb shell в /data/local/tmp/, лучше всего в субфолдер.
mkdir /data/local/tmp/zapret
adb push tpws /data/local/tmp/zapret
chmod 755 /data/local/tmp/zapret /data/local/tmp/zapret/tpws
chcon u:object_r:system_file:s0 /data/local/tmp/zapret/tpws
Как найти стратегию обхода сотового оператора: проще всего раздать инет на комп. Для этого подойдет любая поддерживаемая ОС. Подключите android через USB кабель к компу и включите режим модема. Прогоните стандартную процедуру blockcheck. При переносе правил на телефон уменьшить TTL на 1, если правила с TTL присутствуют в стратегии. Если проверялось на windows, убрать параметры --wf-* .
Работа blockcheck в android shell не поддерживается, но имея рута можно развернуть rootfs какого-нибудь дистрибутива linux. Это лучше всего делать с компа через adb shell. Если компа нет, то развертка chroot - единственный вариант, хотя и неудобный. Подойдет что-то легковесное, например, alpine или даже openwrt. Если это не эмулятор android, то универсальная архитектура - arm (любой вариант). Если вы точно знаете, что ОС у вас 64-разрядная, то лучше вместо arm - aarch64. Выяснить архитектуру можно командой uname -a .
mount --bind /dev /data/linux/dev
mount --bind /proc /data/linux/proc
mount --bind /sys /data/linux/sys
chroot /data/linux
Первым делом вам нужно будет один раз настроить DNS. Сам он не заведется.
echo nameserver 1.1.1.1 >/etc/resolv.conf
Далее нужно средствами пакетного менеджера установить iptables-legacy. Обязательно НЕ iptables-nft, который, как правило, присутствует по умолчанию. В ядре android нет nftables.
ls -la $(which iptables)
Линк должен указывать на legacy вариант. Если нет, значит устанавливайте нужные пакеты вашего дистрибутива, и убеждайтесь в правильности ссылок.
iptables -S
Так можно проверить, что ваш iptables увидел то, что туда насовал android. iptables-nft выдаст ошибку. Далее качаем zapret в /opt/zapret . Обычные действия с install_prereq.sh , install_bin.sh , blockcheck.sh .
Учтите, что стратегии обхода сотового оператора и домашнего wifi вероятно будут разные. Выделить сотового оператора легко через параметр iptables -o <имя интерфейса> . Имя может быть, например, ccmni0 . Его легко увидеть через ifconfig . Wifi сеть - обычно wlan0 .
Переключать blockcheck между оператором и wifi можно вместе со всем инетом - включив или выключив wifi. Если найдете стратегию для wifi и впишите ее в автостарт, то при подключении к другому wifi она может не сработать или вовсе что-то поломать, потому подумайте стоит ли. Может быть лучше сделать скрипты типа "запустить обход домашнего wifi", "снять обход домашнего wifi", и пользоваться ими по необходимости из терминала. Но домашний wifi лучше все-же обходить на роутере.
Устройства типа E3372, E8372, E5770 разделяют общую идеологию построения системы. Имеются 2 вычислительных ядра. Одно ядро выполняет vxworks, другое - linux. На 4pda имеются модифицированные прошивки с telnet и adb. 그들은 사용해야합니다.
Дальнейшие утверждения проверены на E8372. На других может быть аналогично или похоже. Присутствуют дополнительные аппаратные блоки для offload-а сетевых функций. Не весь трафик идет через linux. Исходящий трафик с самого модема проходит цепочку OUTPUT нормально, на FORWARD =>wan часть пакетов выпадает из tcpdump.
tpws работает обычным образом.
nfqueue поломан, можно собрать фиксящий модуль https://github.com/im-0/unfuck-nfqueue-on-e3372h, используя исходники с huawei open source. Исходники содержат тулчейн и полусобирающееся, неактуальное ядро. Конфиг можно взять с рабочего модема из /proc/config.gz . С помощью этих исходников умельцы могут собрать модуль unfuck_nfqueue.ko . После его применения NFQUEUE и nfqws для arm работают нормально.
Чтобы избежать проблемы с offload-ом при использовании nfqws, следует комбинировать tpws в режиме tcp proxy и nfqws. Правила NFQUEUE пишутся для цепочки OUTPUT. connbytes придется опускать, поскольку модуля в ядре нет. Но это не смертельно.
Скрипт автозапуска - /system/etc/autorun.sh . Создайте свой скрипт настройки zapret, запускайте из конца autorun.sh через "&". Скрипт должен в начале делать sleep 5, чтобы дождаться поднятия сети и iptables от huawei.
경고
На этом модеме происходят хаотические сбросы соединений tcp по непонятным причинам. Выглядит это так, если запускать curl с самого модема:
curl www.ru
curl: (7) Failed to connect to www.ru port 80: Host is unreachable
Возникает ошибка сокета EHOSTUNREACH (errno -113). То же самое видно в tpws. В броузере не подгружаются части веб страниц, картинки, стили. В tcpdump на внешнем интерфейсе eth_x виден только единственный и безответный SYN пакет, без сообщений ICMP. ОС каким-то образом узнает о невозможности установить TCP соединение и выдает ошибку. Если выполнять подключение с клиента, то SYN пропадают, соединение не устанавливается. ОС клиента проводит ретрансмиссию, и с какого-то раза подключение удается. Поэтому без tcp проксирования в этой ситуации сайты тупят, но загружаются, а с проксированием подключение выполняется, но вскоре сбрасывается без каких-либо данных, и броузеры не пытаются установить его заново. Поэтому качество броузинга с tpws может быть хуже, но дело не в tpws. Частота сбросов заметно возрастает, если запущен торент клиент, имеется много tcp соединений. Однако, причина не в переполнении таблицы conntrack. Увеличение лимитов и очистка conntrack не помогают. Предположительно эта особенность связана с обработкой пакетов сброса соединения в hardware offload. Точного ответа на вопрос у меня нет. Если вы знаете - поделитесь, пожалуйста. Чтобы не ухудшать качество броузинга, можно фильтровать заворот на tpws по ip фильтру. Поддержка ipset отсутствует. Значит, все, что можно сделать - создать индивидуальные правила на небольшое количество хостов.
Некоторые наброски скриптов присутствуют в files/huawei. Не готовое решение! Смотрите, изучайте, приспосабливайте.
Здесь можно скачать готовые полезные статические бинарники для arm, включая curl : https://github.com/bol-van/bins
Описано в документации BSD
Описано в документации Windows
Для статических бинариков не имеет значения на чем они запущены: PC, android, приставка, роутер, любой другой девайс. Подойдет любая прошивка, дистрибутив linux. Статические бинарники запустятся на всем. Им нужно только ядро с необходимыми опциями сборки или модулями. Но кроме бинариков в проекте используются еще и скрипты, в которых задействуются некоторые стандартные программы.
Основные причины почему нельзя просто так взять и установить эту систему на что угодно:
Если в вашей прошивке есть все необходимое, то вы можете адаптировать zapret под ваш девайс в той или иной степени. Может быть у вас не получится поднять все части системы, однако вы можете хотя бы попытаться поднять tpws и завернуть на него через -j REDIRECT весь трафик на порт 80. Если вам есть куда записать tpws, есть возможность выполнять команды при старте, то как минимум это вы сделать сможете. Скорее всего поддержка REDIRECT в ядре есть. Она точно есть на любом роутере, на других устройствах под вопросом. NFQUEUE, ipset на большинстве прошивок отсутствуют из-за ненужности.
Пересобрать ядро или модули для него будет скорее всего достаточно трудно. Для этого вам необходимо будет по крайней мере получить исходники вашей прошивки. User mode компоненты могут быть привнесены относительно безболезненно, если есть место куда их записать. Специально для девайсов, имеющих область r/w, существует проект entware. Некоторые прошивки даже имеют возможность его облегченной установки через веб интерфейс. entware содержит репозиторий user-mode компонент, которые устанавливаются в /opt. С их помощью можно компенсировать недостаток ПО основной прошивки, за исключением ядра.
Можно попытаться использовать sysv init script таким образом, как это описано в разделе "Прикручивание к системе управления фаерволом или своей системе запуска". В случае ругани на отсутствие каких-то базовых программ, их следует восполнить посредством entware. Перед запуском скрипта путь к дополнительным программам должен быть помещен в PATH.
Подробное описание настроек для других прошивок выходит за рамки данного проекта.
Openwrt является одной из немногих относительно полноценных linux систем для embedded devices. Она характеризуется следующими вещами, которые и послужили основой выбора именно этой прошивк:
Если не работает автономный обход, приходится перенаправлять трафик через сторонний хост. Предлагается использовать прозрачный редирект через socks5 посредством iptables+redsocks , либо iptables+iproute+vpn . Настройка варианта с redsocks на openwrt описана в redsocks.txt. Настройка варианта с iproute+wireguard - в wireguard_iproute_openwrt.txt.
VPS - это виртуальный сервер. Существует огромное множество датацентров, предлагающих данную услугу. На VPS могут выполняться какие угодно задачи. От простого веб сайта до навороченной системы собственной разработки. Можно использовать VPS и для поднятия собственного vpn или прокси. Сама широта возможных способов применения, распространенность услуги сводят к минимуму возможности регуляторов по бану сервисов такого типа. Да, если введут белые списки, то решение загнется, но это будет уже другая реальность, в которой придется изобретать иные решения. Пока этого не сделали, никто не будет банить хостинги просто потому, что они предоставляют хостинг услуги. Вы как индивидуум скорее всего никому не нужны. Подумайте чем вы отличаетесь от известного VPN провайдера. VPN провайдер предоставляет простую и доступную услугу по обходу блокировок для масс. Этот факт делает его первоочередной целью блокировки. РКН направит уведомление, после отказа сотрудничать заблокирует VPN. Предоплаченная сумма пропадет. У регуляторов нет и никогда не будет ресурсов для тотальной проверки каждого сервера в сети. Возможен китайский расклад, при котором DPI выявляет vpn протоколы и динамически банит IP серверов, предоставляющих нелицензированный VPN. Но имея знания, голову, вы всегда можете обфусцировать vpn трафик или применить другие типы VPN, более устойчивые к анализу на DPI или просто менее широкоизвестные, а следовательно с меньшей вероятностью обнаруживаемые регулятором. У вас есть свобода делать на вашем VPS все что вы захотите, адаптируясь к новым условиям. Да, это потребует знаний. Вам выбирать учиться и держать ситуацию под контролем, когда вам ничего запретить не могут, или покориться системе.
VPS можно прибрести в множестве мест. Существуют специализированные на поиске предложений VPS порталы.
Например, вот этот. Для персонального VPN сервера обычно достаточно самой минимальной конфигурации, но с безлимитным трафиком или с большим лимитом по трафику (терабайты). Важен и тип VPS. Openvz подойдет для openvpn, но вы не поднимете на нем wireguard, ipsec, то есть все, что требует kernel mode. Для kernel mode требуется тип виртуализации, предполагающий запуск полноценного экземпляра ОС linux вместе с ядром. Подойдут kvm, xen, hyper-v, vmware.
По цене можно найти предложения, которые будут дешевле готовой VPN услуги, но при этом вы сам хозяин в своей лавке и не рискуете попасть под бан регулятора, разве что "заодно" под ковровую бомбардировку с баном миллионов IP. Кроме того, если вам совсем все кажется сложным, прочитанное вызывает ступор и вы точно знаете, что ничего из описанного сделать не сможете, то вы сможете хотя бы использовать динамическое перенаправление портов ssh для получения шифрованного socks proxy и прописать его в броузер. Знания linux не нужны совсем. Это вариант наименее напряжный для чайников, хотя и не самый удобный в использовании.
USDT
0x3d52Ce15B7Be734c53fc9526ECbAB8267b63d66E
BTC
bc1qhqew3mrvp47uk2vevt5sctp7p2x9m7m5kkchve
