zapret
v69.8
Zapret是免費的和開源的。任何強迫您僅從其資源中下載Zapret的人都需要刪除鏈接，視頻，文件，證明版權的這些要求本身違反了許可。
自動反擊DPI，不需要連接任何第三方服務器。它可以幫助繞過站點HTTP（S）的鎖或減速，例如，用於阻止VPN的TCP和UDP協議的標誌性分析。
該項目主要針對低功率嵌入式設備 - 在OpenWrt下工作的路由器。支持傳統的Linux系統，FreeBSD，OpenBSD，部分支持MACOS。在某些情況下，可以獨立將解決方案擰到各種固件。
大多數功能在Windows上都起作用。
在最簡單的情況下，您正在處理被動DPI。被動DPI可以從流中讀取流量，可以注入其軟件包，但不能阻止傳遞軟件包。如果請求為“不良”，則被動DPI注射了RST軟件包，可選地用HTTP重定向軟件包進行補充。如果僅針對客戶端注入假軟件包，則可以根據某些條件，根據某些條件需要單獨選擇iptables命令，將rst和/或重定向到插件。因此，我們圍繞扳機操作的後果。如果被動DPI指示包括服務器在內的第一個軟件包，那麼您將無能為力。您的任務是防止觸發觸發器的扳機。僅iptables就不會結束。該項目旨在防止禁令，而不是消除其後果。
活動DPI被放置在電線的切口中，並且可以根據任何標準放置包裝，包括識別TCP流並阻止屬於該流量的任何軟件包。
如何防止禁止禁止的觸發因素？發送DPI不指望的東西，並且識別請求及其阻塞的算法會破壞他。
如果將某些DPI分為TCP段，則無法識別HTTP請求。 For example, a request of the type GET / HTTP/1.1rnHost: kinozal.tv...... We send in 2 parts: first there is GET , then / HTTP/1.1rnHost: kinozal.tv..... Other DPI stumble when the header Host: is written in another register: for example, host: .在某些地方，在方法之後添加額外的差距： GET / => GET /或在主機名的末尾添加點： Host: kinozal.tv.
還有更高級的魔術旨在克服包裝級別的DPI。
閱讀有關DPI的更多信息：
https://habr.com/en/post/335436或https://web.archive.org/web/2023033123644/https://https://habr.com/en/post/3335436/
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系統，有一個改編版本-DVTWS，是從相同來源收集的（請參見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 ，則消息將不會顯示到文件或系統log。登錄文件時，該過程不會打開文件。為了每個錄製，文件打開然後關閉。因此可以隨時刪除該文件，並將在日誌中的第一個消息中再次創建文件。但是請記住，如果您在根本下啟動該過程，則將被UID替換為非根。一開始，文件上的文件會更改日誌，否則錄製將不可能。如果然後刪除文件，並且該過程將無權在其目錄中創建文件，則將不再執行日誌。而不是拆卸，最好使用截斷。在SHEL中，可以通過命令“：> filename”來完成此操作。
它的本質如下。添加了原始請求，修改，虛假信息（假貨），以便服務器操作系統將原始請求轉移到服務器進程不變，而DPI看到了另一個。他不會阻止的事實。服務器看到一件事，DPI是另一件事。 DPI不明白禁止的請求已傳輸，也不會阻止它。
有很多實現這一結果的機會。這可以是偽造軟件包的傳輸，因此它們可以到達DPI，但不要到達服務器。可以使用TCP級別（分割）或IP級別的碎片化。具有TCP序列編號的遊戲或TCP段的混亂順序有基於遊戲的攻擊。方法可以在各種版本中組合。
假貨是單獨的NFQW生成的軟件包，可為DPI提供虛假信息。他們要么不應該到達服務器，要么可以到達服務器，但必須將其丟棄給它們。否則，TCP連接的故障或違反了傳輸流的完整性，這可以保證破壞資源。有許多方法可以解決此問題。
md5sig添加了TCP MD5簽名選項。它不適用於所有服務器。 MD5軟件包通常僅丟棄Linux。badsum破壞了TCP的控制量。如果您的設備適用於NAT，它將不起作用，NAT不會錯過輪椅的袋子。 Linux中最常見的設置路由器NAT不會錯過它們。大多數家用路由器都是建立在Linux上的。確保嵌套如下：默認情況下net.netfilter.nf_conntrack_checksum=1使CONNTRACK檢查傳入軟件包的TCP和UDP結帳，並設置了帶有輪椅的軟件包的狀態。通常在iPtables規則中，插入了前鏈中無效狀態的包裹的規則。這些因素的聯合組合導致通過這種路由器缺乏壞人。在“ openwrt”中，從變速箱net.netfilter.nf_conntrack_checksum=0中，通常沒有其他路由器，並且不能總是更改。為了使NFQW通過路由器工作，您需要將指定的SYSCTL值設置為0。路由器上的NFQWS本身將無需這種配置而工作，因為從未檢查過本地創建的軟件包的Chexumma。例如，如果另一個NAT之後的路由器，例如提供商，並且不會錯過無效的數據包，您將無法對此做任何事情。但是通常提供者仍然錯過了Badsum。在某些適配器/運動衫/驅動程序中，RX-Checksum卸載，在OS中接收之前，將被迫刪除BadSum軟件包。在這種情況下，如果可以做某事，則只會修改驅動程序，這似乎是極為平底的。已經確定，基於中等基因的一些路由器以這種方式行事。 BadSum軟件包離開了客戶端操作系統，但是路由器在BR-Lan中沒有通過TCPDUMP看到。此外，如果在路由器本身上執行NFQW，則旁路可以工作。 BadSum通常會留下外部接口。badseq將TCP序列編號增加到某個值，從而從TCP窗口中撤回。此類軟件包可能會被接收節點丟棄，如果DPI著重於序列編號，也可能會丟棄。默認情況下，選擇SEQ位移-10000。練習表明，某些DPI不會錯過特定窗口外的SEQ。但是，如此小的位移會導致大量流和包裝丟失的問題。如果您使用的是--dpi-desync-any-protocol ，則可能需要安裝BADSEQ增量0x80000000。這將提供可靠的保證，即虛假軟件包不會楔入服務器上的TCP窗口。還注意到，BadSeq在HTTP分析過程中打破了某些DPI的邏輯，從而導致連接凍結。此外，在同一DPI TLS上，BadSeq效果很好。TTL似乎是最好的選擇，但它需要為每個提供商進行單獨調整。如果DPI比提供商的本地站點更遠，則可以切斷對其的訪問。 TSPU在高速公路上的存在加劇了這種情況，這迫使TTL使TTL很高，從而增加了假貨對服務器的崩潰風險。需要手動填寫IP排除列表。與TTL一起，您可以使用MD5SIG。這不會破壞任何東西，但是給出了“壞”包將到達TTL的工作地點。如果找不到自動解決方案，請使用zapret-hosts-user-exclude.txt文件。路由器的一些庫存固件修復了即將發出的TTL，而不會斷開此選項，將無法通過它們來使用。值得選擇的TTL是什麼：找到旁路仍然有效的最小值。這將是您的DPI Hop的數量。hopbyhop僅指IPv6。添加了IPv6 Extens Header hop-by-hop options 。 hopbyhop2添加了2個避難所，這違反了標準，並保證被所有操作系統中的協議堆棧丟棄。所有操作系統都接受了一個Heder Hop-Hop，但是在某些頻道/提供商上，這些軟件包可能會被過濾而不是到達。計算是DPI將通過跳躍的跳躍分析軟件包，但它不會到達提供商過濾器的收件人，或者將被服務器拋棄，因為有兩個頭。datanoack使用ACK TCP標誌發送假貨。服務器不接受，DPI可以接受。如果使用Masquarade，即使是從本地系統（幾乎總是在IPv4路由器上），此技術可能會破壞NAT，並且並不總是與Iptables一起使用。在沒有固定裝置和Nftables的系統上，它可以無限制地工作。經過實驗發現，許多提供商NAT不會丟棄這些軟件包，因此即使在內部提供商IP中也可以使用。但是它不會通過linux nat，因此該技術很可能不在家庭路由器後面工作，但可能會從中使用。如果連接連接，它可以通過路由器工作，並且在路由器上，可以打開硬件加速度。autottl 。 TTL自動定義中該制度的本質，因此幾乎可以肯定會通過DPI，並且不會稍微到達服務器。採用TTL 64.128,255的基本值，外觀的包裹（是的，有必要將第一個傳入的軟件包引向NFQWS！）。計算軌道的長度，進行delta （默認為1）。如果TTL不超出範圍（默認情況下，最大為最大-3.20），則最小值，最大值被以適合該範圍。如果所得的TTL大於路徑的長度，則自動化不起作用，並且採取固定的TTL值。該技術使您可以在包括高速公路在內的障礙（DPI，TSPU）阻止整個網絡（DPI，TSPU）時解決問題。但是可能會失敗。例如，使用傳入和傳出通道的不對稱性到特定服務器。在某些提供商上，這項技術會很好地運行，而其他提供商將帶來更多的問題，而不是好的問題。在某個地方可能需要調整參數。最好與其他限制器一起使用。區域模式可以組合任何組合。 --dpi-desync-fooling通過逗號獲得許多值。
multisplit 。我們將請求切成--dpi-desync-split-pos中指示的位置。multidisorder 。我們將請求切成--dpi-desync-split-pos中指示的位置，然後以相反的順序發送。fakedsplit 。我們削減了對兩個部分的要求，用假貨構架了每個部分：第一部分的假貨，第1部分，第一個部分，第二部分的假貨，2部分，第二部分的偽造fakeddisorder 。類似於fakedsplit ，僅以相反的順序為：第二部分的假貨，第二部分，第二部分的假貨，第一部分的偽造，1部分，偽造的1部分。 fakedsplit中的fakeddisorder中的偽裝內容由參數--dpi-desync-fakedsplit-pattern （默認為0x00）確定。這些假貨是從模式中取出的，其位移對應於引用部分的位移。假貨的尺寸對應於發送的零件的長度。這些模式的目的是使偽造之間的原始數據識別複雜化。
為了確定切割的位置，使用標記。
相對位置：
--methodeol造成的可能會移動。那麼位置可以是1或2。標記列表的示例： 100,midsld,sniext+1,endhost-2,-10 。
打破軟件包時，第一件事是解決標記 - 找到所有這些相對位置和位移的使用。如果當前協議中沒有相對位置，則不會應用和丟棄此類位置。然後，關於程序包組中當前軟件包的位移（例如，與Kyber的TLS Multi -packet請求）之間存在歸一化位置。所有延伸超出當前軟件包限制的位置都被拋棄了。其餘的分類以增加重複。在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添加了seqovl ，該字節在一個TCP段之一的開頭中，其序列編號在seqovl中。對於第一個部分split時，對於disorder第二部分開始時（原始訂單中的第二個）。
在split計算是基於以下事實：先前的引用（如果是）已經輸入了服務器應用程序的coquet，因此到達的新產品僅部分在當前窗口（窗口內）中。在前面，假零件被丟棄，其餘部分包含原件，並從窗口的開頭開始，因此進入插座。服務器應用程序接收了客戶端真正發送的所有內容，並丟棄了偽造的窗外部分。但是DPI無法理解這一點，因此他有一個序列desinchronation。必須將seqovl的第一段不超過MTU的長度。這種情況會在Linux中自動識別，並取消seqovl 。在其他系統中，情況沒有被識別，這將導致連接的故障。因此，選擇第一個拆分位置和seqovl ，以便在任何情況下都不會超過MTU。否則，精神化可能無法隨機起作用。
對於disorder重疊，它轉移到包裝的倒數第二部分。為簡單起見，我們將假設該部門分為2個部分，它們將以“ 2 1”為順序“ 2 1”，原始順序“ 1 2”。有必要將seqovl小於第一個拆分的位置，否則發送的所有內容都會立即轉移到插座上，包括偽造，打破了應用級別的協議。該程序很容易檢測到這種情況，並取消了seqovl 。原則上不可能增加包裝的大小。在包裝的第二部分的條件下，完全是窗口中的，因此服務器操作系統完全接受它，包括假貨。但是，由於尚未採用1包1個包的數據的初始部分，因此無需訪問服務器應用程序而在核存儲器中保留了偽造和真實數據。一旦包裝的第一部分出現，它就會重寫核記憶中的假部分。該核從1和2個零件接收數據，因此該應用程序被發送到應用程序插座。除Solaris外，所有UNIX OS的行為都將留下最後的數據。 Windows留下了舊數據，因此與Windows服務器一起工作時，患有SEQOVL的混亂將導致增援。 Solaris幾乎已經死了，很少有Windows服務器。您可以在必要時使用床單。該方法允許您在不欺騙和TTL的情況下做。假貨與真實數據混合。 fakedsplit/fakeddisorder仍然添加其他單獨的假貨。
split版本中的seqovl只能是絕對正值，因為它僅在第一個軟件包中使用。在disorder版本中，所有標記選項都是允許的。它們會自動將系列中的當前軟件包標準化。您可以在midsld上編織並在midsld-1上製作Seqovl。
hopbyhop ， destopt和ipfrag1 DesingHronization模式（不要與Fololing混淆！）僅與IPv6相關，並在添加所有屬於desinchronization的軟件包中添加hop-by-hop options ， destination options或fragment 。在這裡，有必要了解添加標頭會增加包裝的大小，因此不能將其應用於最大尺寸的數據包。傳輸大消息時就是這種情況。如果不可能發送包裹，將取消精神的精神，將包裹在原件中被驅逐出去。計算是DPI將在主ipv6標題的下一個標頭字段中看到0，並且不會跳到擴展防護區以尋找運輸標頭。因此，它不會理解它是TCP或UDP，並且不會在沒有分析的情況下錯過包裹。也許有些DPI會購買。它可以與第二階段的任何模式結合使用，除了ipfrag1+ipfrag2選項。例如， 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交付的確認是帶有ACK序列的ACK服務器軟件包，對應於ClientHello+1的長度。在疾病版本中，部分確認（麻袋）通常是第一個，然後是完整的ACK。如果代替ACK或麻袋，則有一個最小延遲的REST軟件包，則DPI在請求的階段將您切斷。如果REST在延遲等於服務器的延遲後完成一個完整的ACK，則DPI可能會對服務器響應做出反應。如果ClientHello滿意他而不檢查ServerHello，DPI可以落後於流。那你很幸運。假選項可能會起作用。如果他不落後並頑固地檢查ServerHello，則可以嘗試強迫服務器通過參數-Wssize中的部分發送ServerHello（請參閱Conntrack）。如果這無濟於事，那麼如果沒有服務器的幫助，就不太可能這樣做。最好的解決方案是在服務器上啟用TLS 1.3支持。在其中，服務器證書以加密形式傳輸。這是所有阻塞站點的管理員的建議。打開TLS 1.3。因此，您將提供更多克服DPI的機會。
在日內瓦文檔中，這稱為“ TCB周轉”。試圖誤導DPI的客戶和服務器的角色。
由於該模式違反了NAT的工作，因此只有在攻擊設備和DPI之間沒有NAT的情況下，設備才能工作。該攻擊將無法通過NAT路由器起作用，但可能會從中使用。為了對通過流量進行攻擊，需要進行NFTABLES和NAT後方案。
這裡的一切都很簡單。數據已添加到SYN軟件包中。如果不使用TCP快速開放（TFO），則所有操作系統都會忽略它們，而DPI可以感知到無需理解在那裡吃飯。與TFO的原始連接不會觸摸，因為這肯定會破壞它們。沒有澄清參數，添加了16個零字節。
從NAT的VirtualBox和VMware的VM內部，許多NFQWS軟件包技術在NAT模式下不起作用。 TTL被強行替換，假包裹不會通過。您需要在橋樑模式下配置網絡。
NFQWS配備了有限的跟踪TCP化合物實現。它已打開，以實現某些抵消DPI的方法。 Connetrack能夠監視連接階段：SYN，已建立，FIN，每個方向上的軟件包數，序列編號。 Connetrack能夠用一個袋子或僅在一個方向上“饋送”。當您找到帶有SYN或SYN設置的標誌的軟件包時，該連接進入表格。因此，如果您需要Conntrack，則在iPtables重定向規則中，連接應從第一個軟件包轉到NFQW，儘管它可以突破Connbytes濾鏡。對於UDP而言，進入表的啟動器是第一個UDP軟件包。它還決定流動的方向。據信，第一個UDP軟件包來自客戶端到服務器。接下來，所有帶有共同的src_ip,src_port,dst_ip,dst_port軟件包被認為屬於這種流程之前的流動時間。 Conntrack很簡單，沒有考慮到連接的各種攻擊，它沒有記錄有關序列編號或Chekumm的有效性的軟件包。它的任務僅是為了維持NFQW的需求，通常僅以傳出流量為食，因此對外部網絡的替代不敏感。一旦需要跟踪它或在不活動中的Timout消失後，該連接就會立即從表中刪除。連接的每個階段都有單獨的超時。可以通過參數--ctrack-timeouts更改它們。
--wssize允許您從客戶端更改服務器的TCP窗口的大小，以便他將以下答案發送到零件。為了影響所有服務器OS，有必要在發送消息之前更改來自客戶端的每個軟件包的窗口大小，應將其分開的答案（例如TLS ClientHello）。這就是為什麼有必要知道何時停止的原因。如果您不停止並一直安裝低WSSize，則速度將災難性下降。在Linux中，這可以通過Connbytes停止，但是在BSD系統中，沒有這種可能性。對於HTTP（S），我們在發送第一個HTTP請求或TLS ClientHello後立即停止。如果您不處理HTTP（S），則需要參數--wssize-cutoff 。它設置了WSSize操作停止的限制。數字之前的前綴D僅表示帶有數據有效載荷，前綴S-相對序列編號的軟件包，換句話說，客戶端 + 1傳輸的字節數。如果帶有HTTP請求的軟件包或TLS ClientLol，則WSSIZE操作停止，而無需等待WSSize size -size -size -size -size -size cutoff。如果您的協議容易長期無所不能，則通過--ctrack-timeouts參數增加了建立的階段。默認值很低 - 僅5分鐘。不要忘記，NFQWS會通過包裹以包裹為食。如果您限制了通過Connbytes的軟件包的攝入量，則該表可能會在已建立的階段保留懸掛的化合物，這只能在Timout中掉落。要診斷Conntrack，請將SiGUSR1信號發送到NFQWS： killall -SIGUSR1 nfqws 。當前表將由NFQWS顯示在Stdout中。
通常，在SYN軟件包中，客戶端除窗口大小外，還引用TCP擴展scaling factor 。縮放係數是deuce的程度，它乘以窗口大小：0 => 1，1 => 2，2 => 4，...，8 => 256，...在WSSIZE縮放因子參數中通過結腸指示。縮放係數只能減少，增加的增加，以防止超過服務器的窗口大小。要迫使服務器到ServerHello的分裂，為了避免從DPI上的服務器證書清除服務器名稱，最好使用--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包，則它們會很長。默認情況下，Kyber將打開，從Chromium 124開始。 Chrome由TLS Fingerprinnt隨機化。 SNI可以在開始和結尾處，也就是說，進入任何軟件包。狀態DPI通常完全重新組裝請求，然後才決定阻止。如果使用部分客戶端的TLS或QUIC包獲取TLS或QUIC軟件包，則開始組裝過程，並且包裝延遲了，直到其結束才發送。在組件結束時，包裝通過完全收集的客戶端通過DESANGRONINIP。如果在組裝過程中發生任何錯誤，則立即將被拘留的軟件包發送到網絡，並取消desinchronization。
對於多段TLS的所有TCP拆分選項都有特別的支持。如果您指出拆分的位置比第一個套件的長度多，那麼崩潰不一定發生在第一個包裝，而是最終位置的一個套件是，例如，如果客戶端發送了TLS ClientHello 2000，SNI是從1700開始的，則是1700，而fake,multisplit選項則設置為假，那麼第一個包裝是假的，然後是原始包中的第一個包裝，並且是原始包中的第一個包裝。結果，我們在開始時有一個假貨和3個真正的細分市場。
UDP攻擊的功能更具限制。 UDP不能與IP級別不同。對於UDP，只有DesingHronization模式fake ， hopbyhop ， destopt ， ipfrag1 ， ipfrag2 ， udplen ， tamper是有效的。可以將fake ， hopbyhop ， destopt與ipfrag2 ， fake ，udplen和篡改的fakeknown相結合。 udplen將UDP數據包的大小增加到--dpi-desync-udplen-increment中指定的字節數。默認情況下，填充填充零，但是您可以設置圖案。專為欺騙DPI而設計，專注於包裝的尺寸。如果用戶協議不綁定到UDP有效載荷的大小，則可能會工作。篡改模式是指通過協議的特殊方式修改已知協議的軟件包。目前，它僅適用於DHT。用內容的解碼和主機的名稱（即--hostlist參數可以工作）來確定Quic初始軟件包。 Wineguard Handhake Infusion和DHT（以'd1'開頭，以'e'結尾）。為了實現其他協議，必須指出--dpi-desync-any-protocol 。 Connetrack已為UDP實施。您可以使用dpi-desync-cutoff。可以使用--ctrack-timeouts中的第4個參數更改UDP的連接taimout。假攻擊僅對狀態DPI有用，在單個軟件包級別的分析中毫無用處。默認情況下，填充-64零。您可以在--dpi-desync-fake-unknown-udp中指定文件。
現代網絡實際上不會錯過IP級別的零散的TCP。在UDP上，這是更好的，因為某些UDP協議可以依靠此機制（舊版本的IKE）。但是，在某些地方，他們切割和碎片的UDP。 Linux路由器可以自發地組裝或釋義袋。 TCP和UDP分別設置了碎片位置。默認情況下，分別為24和8，應為8的倍數。位移被認為是運輸標題。
在Linux上的片段上有很多瞬間，沒有任何片段，沒有理解就無法解決。
IPv4：Linux提供IPv4片段，但是輸出鏈中的標準iptables設置可能會導致發送錯誤。
IPv6：沒有辦法應用保證，可以在不碎片部門向Conntrack進行碎片的情況下發送片段。在不同的系統上，結果有所不同。他們正常離開的某個地方，包裹是碎片的。對於核<4.16，似乎沒有其他方法可以解決此問題，除非卸載nf_conntrack模塊，從而收緊nf_defrag_ipv6的依賴性。它只是執行碎片。對於核4.16+，情況要好一些。從碎片策劃中，包裝在notrack狀態下被排除在外。為了不弄亂描述，請參見在blockcheck.sh中解決此問題的示例。
有時，需要使用raw_before_defrag=1參數加載ip6table_raw模塊。模塊的openWRT參數通過差距表示，其名稱在/etc/modules.d文件中。在傳統系統中，查看是否使用了iptables-legacy或iptables-nft 。 /etc/modprobe.d/ip6table_raw.conf遺產，則需要使用內容：
options ip6table_raw raw_before_defrag=1
在某些傳統發行版中，您可以通過以下方式更改當前的IP6tables：Update-Anternatives-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,
},
並在任何地方替換-450。
這必須手動完成，在blockcheck.sh中沒有自動化。
或者，您可以nftables地擺脫此問題。在這裡，您可以使用任何優先級創建netfilter hook 。使用優先級-401及以下。
使用iPtables和nat時，似乎無法在NAT之後附加隊列處理程序。該軟件包以內部網絡的源地址輸入NFQW，然後分散，不再處理NAT。因此，它使用SRC IP 192.168.xx進入外部網絡，因此該方法不起作用。顯然，唯一的工作方法是放棄iptables並使用Nftables。鉤子應優先級為101或更高。
NFQWS能夠對各種請求做出不同的反應並採用不同的精神策略。這是通過支持許多精神概況來實現的。配置文件用--new參數在命令行中分配。第一個配置文件是自動創建的。對他--new不是必需的。每個配置文件都有一個過濾器。默認情況下，它是空的，即配置文件滿足任何條件。過濾器可能包含硬參數：協議，IPSET和TCP/UDP端口的IP。即使在主機和L7未知時，它們也總是明確地識別出它們的零階段。作為軟過濾器，主機列表和應用級別（L7）的協議可以起作用。 L7協議通常在第一個數據包後已知。收到請求後，從第一個到最後一個順序檢查配置文件，以達到與過濾器的第一個重合。首先檢查過濾器的剛性參數。如果不匹配，則立即向下一個配置文件過渡。如果任何配置文件都滿足硬濾波器和L7濾波器並包含一個自動宿主，則將立即選擇。如果配置文件滿足硬過濾器和L7濾波器，則設置了敵對的，並且我們仍然沒有主機名，請過渡到下一個配置文件。否則，將對此配置文件的主機清單進行檢查。如果主機名滿足表，則選擇此配置文件。否則，將要過渡到下一個。可能會發生在接收主機的名稱或L7協議的識別之前，該連接根據一個配置文件進行，當澄清這些參數時，配置文件即時更改。當澄清L7和主機的名稱時，這甚至可以發生兩次。大多數情況下，這種澄清是通過一個動作組合在一起的，因為L7和主機通常都由一個軟件包識別。因此，如果您具有零階段的挖掘參數，請仔細考慮在策略切換時會發生什麼。觀看調試日誌，以更好地了解NFQWS的作用。配置文件的編號是從1到N。鏈中的後者創建了一個空的配置文件，其中數字為0。當沒有過濾器條件重合時，使用它。
重要的
僅在不可能將現有資源的現有策略結合起來的情況下才創建多種策略。 libem的臟胚°ю都函~~ыы。
Important
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 ，則消息將不會顯示到文件或系統log。 --debug=0|1|2 。 liminum。 --debug-level --debug-level --debug聽йd了жπдеедержμфπ了。為了每個錄製，文件打開然後關閉。因此可以隨時刪除該文件，並將在日誌中的第一個消息中再次創建文件。但是請記住，如果您在根本下啟動該過程，則將被UID替換為非根。一開始，文件上的文件會更改日誌，否則錄製將不可能。如果然後刪除文件，並且該過程將無權在其目錄中創建文件，則將不再執行日誌。而不是拆卸，最好使用截斷。在SHEL中，可以通過命令“：> 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。 DnAT溝™µCisull課 - 至-to - to - to - to。例如 ：
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 m lipse-ipset-oul。 ™™lomыйыйыйчч電х執х執б都8bibim，заа激зμVIL。 。 !!!! uеdam。
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.
Important
Настройка маршрутизации, маскарада и т.д. не входит в задачу 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 лучше все-же обходить на роутере.
y尋度，E8372，e5770。極ююычÖ2×極函。 o電−°µ −пол鏢vxworks，дрое -linux。臟4pda極。它們需要使用。
Дальнейшие утверждения проверены на 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文檔中描述
都8bimum°чL信庭函подойдет啟，а可，дистриб為linux。 Cist。他們只需要具有必要的組裝選項或模塊的核心。臟°函
Основные причины почему нельзя просто так взять и установить эту систему на что угодно:
Если в вашей прошивке есть все необходимое, то вы можете адаптировать 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 порталы.
例如，這個。 дляперсональ恆Vpnvpn見vpn見□upi基極Ö。 ~~ lie護vps。 OpenVZ NIMTEM光啟動，儀式，IPSEC，Ipsec，inтlipultevpn，iPSec，iPSec，。都隆基內元模式誤QCC或μ烯。 подой短KVM，XEN，HYPER-V，VMware。
По цене можно найти предложения, которые будут дешевле готовой VPN услуги, но при этом вы сам хозяин в своей лавке и не рискуете попасть под бан регулятора, разве что "заодно" под ковровую бомбардировку с баном миллионов IP. Кроме того, если вам совсем все кажется сложным, прочитанное вызывает ступор и вы точно знаете, что ничего из описанного сделать не сможете, то вы сможете хотя бы использовать динамическое перенаправление портов ssh для получения шифрованного socks proxy и прописать его в броузер. Знания linux не нужны совсем. Это вариант наименее напряжный для чайников, хотя и не самый удобный в использовании.
USDT
0x3d52Ce15B7Be734c53fc9526ECbAB8267b63d66E
BTC
bc1qhqew3mrvp47uk2vevt5sctp7p2x9m7m5kkchve
