Core Analysis¶

Project Positioning: zapret focuses on addressing the problem where DPI (Deep Packet Inspection) recognizes flows/packets by signatures and triggers blocking or throttling for specific sites/protocols. It is not a VPN or remote proxy; instead it modifies packets/flows locally to avoid DPI triggers.

Technical Analysis¶

• How it solves the problem: DPI relies on signature matching and flow reassembly. By introducing non-typical segmentation, manipulating TCP sequence numbers, injecting forged packets, or altering HTTP headers, zapret changes the observable characteristics of a flow so DPI cannot match signatures reliably and thus avoids triggering blocks.
• Tooling: nfqws performs packet-level modification at NFQUEUE before reassembly; tpws operates at the stream/proxy level, doing transparent segmentation/rewrites and preserving connection semantics. They can be combined depending on performance and compatibility needs.

Practical Recommendations¶

1. Test scope: Start in a test environment with dry-run and a small hostlist to validate strategy effectiveness.
2. Scoped application: Use autohostlist or custom hostlists to limit interventions to affected traffic and reduce side effects.
3. Tool selection: Prefer nfqws for fine-grained control if CPU/memory allow; use tpws or pared-down strategies on resource-constrained devices.

Important Notice: This approach will not work if the target is blocked by direct IP blacklisting or if DPI performs full reassembly and connection re-initiation (e.g., certain middlebox proxies).

Summary: zapret provides a locally runable, configurable set of desynchronization and forgery techniques to mitigate signature/reassembly-based DPI triggers on constrained devices, but it is not a universal bypass for all blocking scenarios.

Core Analysis¶

Rationale for choice: Using NFQUEUE and raw socket/flow rewriting enables direct control at the kernel/user boundary, allowing modification of packets and flows before DPI completes reassembly or signature matching.

Technical Features and Advantages¶

• Fine-grained intervention (packet-level): nfqws uses NFQUEUE to hand packets to user space before TCP reassembly, enabling changes to sequence numbers, segmentation, or forged packets — highly effective against DPI that inspects pre-reassembly characteristics.
• Stream-level compatibility (proxy-style): tpws operates at the connection level and can perform semantic transformations (e.g., application-layer segmentation) with lower CPU overhead and better connection semantics retention on some devices.
• Modularity and composability: Strategies can be combined across both layers, trading off precision and performance based on need.
• Portability and lightweight design: The project’s OpenWrt/embedded focus indicates attention to runtime footprint and minimal dependencies.

Practical Recommendations¶

1. Strategy preference: Use nfqws if resources allow for more precise control; use tpws where CPU is constrained or when preserving connection semantics is critical.
2. Hybrid use: Start with tpws for low-cost tests and escalate to nfqws for packet-level interventions if needed.
3. Monitor cost: Test CPU, conntrack entries, and latency under load to avoid NFQUEUE-induced kernel queue blocking.

Important Notice: Sustained high load on NFQUEUE may cause kernel queue backpressure, packet drops, or connectivity issues; configure queue sizes and test under stress.

Summary: The NFQUEUE + flow-rewrite hybrid provides a practical trade-off between control precision and deployability, allowing packet-level interventions where required while retaining options for lower-cost stream-level strategies.

Core Analysis¶

Learning curve: Medium to high. Users need to understand iptables/nftables, NFQUEUE, conntrack, TCP sequencing and reassembly, and how to monitor CPU and connection tables on constrained devices. These are the main hurdles for newcomers.

Common Pitfalls¶

• Misconfigured rules causing outages: Improper NFQUEUE or iptables rules can intercept and block large portions of traffic.
• Strategies breaking legitimate connections: Incorrect segmentation or sequence-number overrides can break HTTP/HTTPS sessions or disturb TLS handshakes.
• Performance bottlenecks: Packet-level modification at scale consumes significant CPU and may overwhelm embedded devices.

Practical Recommendations (minimize risk)¶

1. Progressive validation: Use dry-run or low-impact modes in a test or isolated environment to observe effects on target sites.
2. Scope limitation: Apply strategies only to necessary hostlists/IP lists to avoid global interference.
3. Rollback and monitoring: Keep a one-click disable script or systemd unit, and monitor CPU, conntrack, latency, and connection failure rates.
4. Backup configs: Save current iptables/nftables rules before changes to enable quick rollbacks.
5. Gradual escalation: Start with low-cost strategies (HTTP header tweaks, simple segmentation), then apply more invasive packet-level methods if needed.

Important Notice: Always have a rollback plan before first deploying into production to avoid network-wide connectivity failures.

Summary: Conservative, stepwise testing combined with clear rollback procedures keeps operational risk acceptable and enables gradual tuning of zapret strategies.

Core Analysis¶

Typical ineffective scenarios:

• Direct IP blocking: If the target IP is dropped at the network layer or unreachable, packet/flow rewriting cannot restore reachability.
• Middlebox/proxy with full reassembly: If DPI in the middle can fully reassemble sessions and make decisions based on reconstructed semantics (or re-initiate the connection on the server side), local desynchronization/forgery cannot change its decision.
• TLS/session rewriting: When a middlebox rewrites TLS or reconstructs application-layer sessions, light packet tweaks are unlikely to succeed.

How to assess infeasibility¶

1. IP reachability checks: Use ping, traceroute, and telnet to check IP-layer blackholing.
2. Injection/reset observation: Capture traffic with tcpdump to see if RSTs or injected packets originate from middlebox addresses and target both server and client.
3. Session reassembly diagnosis: Compare TCP sequence/reassembly views between client and server; if DPI has an independent reconstructed session with the server, bypassing is hard.
4. Progressive testing: Try low-cost strategies (e.g., header tweaks) and measure any reduction in trigger rate.

Important Notice: If assessment indicates direct IP blocking or middlebox full reassembly, consider alternatives such as a trusted VPS + encrypted tunnel or changing server IP/port strategies.

Summary: Verify IP reachability and DPI reassembly capability before deployment; if DPI fully reassembles or IPs are blackholed, zapret’s local strategies are generally ineffective and alternatives should be considered.

Core Analysis¶

Goal: Find an effective strategy combination for a blocked site with minimal side effects.

Actionable testing process (stepwise)¶

1. Establish baseline: Capture traffic with tcpdump/browser devtools without any modifications to record failure mode (status codes, redirects, RSTs).
2. Low-impact attempts: Enable lightweight tweaks (e.g., Host case changes, method/path spacing or appended dot) in dry-run or on a single client to see if trigger rate drops.
3. Incremental escalation: If needed, try in order: TCP segmentation (change MSS/segment points), delayed segmentation, forged packet injection (RST/redirect), IP_ID/fragment manipulation, and sequence-number overrides. Enable one technique at a time and log effects.
4. Parameter tuning: For effective techniques, tune parameters (segment size, injection timing, sequence offset) and perform A/B tests for success rate and page integrity.
5. Combination and regression: Combine successful single methods, verify compatibility with TLS, persistent connections, and streaming; retest under different loads/times.
6. Deploy and monitor: Apply only to targeted hostlists, continuously monitor error rate, latency, CPU, and conntrack; keep rollback scripts ready.

Practical tips¶

• Reproducibility: Keep detailed logs and packet captures for each change to enable rollbacks and shareable diagnostics.
• Conservative approach: Prioritize page/functionality preservation before maximizing trigger reduction.

Important Notice: Be cautious when applying techniques that affect TLS records; validate such strategies in a controlled environment first.

Summary: A systematic “baseline → low-impact → incremental escalation → combination → monitoring & rollback” workflow yields an effective, low-side-effect tuning process for individual blocked sites.