window_size = 20
def parsearg():
args = parser.parse_args()
window_size = args.window_size
# local variable only
def modify_window(pkt):
ip[TCP].window = window_size
NFQUEUE / PACKET LAB / BEIJING
MAKE THE
PACKET VISIBLE.
把一段 Python 网络实验重写为 Rust:在 Linux 用户态接收选定的 IPv4/TCP 报文,改写 TCP Window,重算校验和,再交还内核。
Rust 只改通告窗口;程序不解析 HTTP,也不直接切分应用数据。这里的 17 + 66 是对端 TCP 栈对窗口的响应。
01 / MECHANISM
一个窗口字段,经过五个边界。
iptables 负责选择报文,NFQUEUE 负责把报文交给用户态;Rust 仅在标志位精确匹配时改写两个字节,并重新计算 IPv4 与 TCP 校验和。
仓库提供的默认规则只排队源端口 80/443 的 SYN+ACK。程序还能识别 ACK、PSH+ACK、FIN+ACK,但在真实流量中需要为它们另加明确且受控的规则。
02 / THE REWRITE
同一个实验,两代实现。
Rust 版本保留原脚本的精确标志匹配与 NF_ACCEPT 路径,同时修复命令行窗口值没有进入回调的问题。
Config {
queue: 100,
window_size: 17,
}
CallbackState {
window_size: config.window_size,
}
rewrite_tcp_window(packet, 17)
SYN+ACK / FIN+ACK / PSH+ACK / ACK
改写后重算 IPv4 与 TCP checksum
--window-size 与 --window_size
修改或原样返回后统一 NF_ACCEPT
03 / OPERATOR SEQUENCE
顺序本身就是安全条件。
工具只能在 Linux 上运行,并需要 root、iptables 与 libnetfilter_queue。先启动队列消费者,再安装规则;结束时先删规则,再停进程。
sudo apt-get install -y build-essential pkg-config libnetfilter-queue-dev iptables
cargo build --releasesudo ./target/release/rust-geneva --queue 100 --window-size 17
sudo ./scripts/iptables-output.sh 100 addsudo ./scripts/iptables-output.sh 100 del
# 然后按 Ctrl+C 停止 rust-geneva规则没有使用 --queue-bypass;消费者退出后若规则仍在,匹配流量可能中断。
04 / CONCLUSION
重写完成;结论保持克制。
项目做什么?
它是 Linux NFQUEUE 上的出站 TCP 头改写器,不是 Web 代理,也不会开放被防火墙关闭的端口。
怎么使用?
编译 Rust 二进制,启动队列消费者,添加受控 OUTPUT 规则,抓包观察,最后先删规则再停止。
重写成功吗?
原脚本行为已由 Rust 实现,参数作用域问题已修复;单元测试和本次 VPS 集成实验均正常。
能正常用吗?
在本次 Debian 环境可以工作,但尚未覆盖 IPv6、IPv4 分片、压力和长期运行;未进行 Python 与 Rust 性能基准对比。
Rust 重写达成了报文改写目标。当前环境没有证明限制绕过效果,不能把可访问性结果外推为通用绕过能力。