ipt_geofence

ipt_geofence：把"国家"做成防火墙可匹配的一个维度

项目背景与痛点

绝大多数 ACL 是按 IP 或网段写的。这套模型在内部系统里够用，一旦服务暴露到公网就立刻失效：攻击流量来自全球几十个国家的僵尸网络，你不可能手工维护几十万条 -j DROP，也没法在发生勒索软件扫描时把某个网段当作"临时黑名单"写进配置——因为下次换一批 IP，规则就白写了。

真正的痛点是：我们希望按"归属地"这个粗粒度维度做策略，而不是逐个 IP 做策略。 商业 WAF 和 CDN 厂商的 geo-blocking 能做到，但代价是把流量交给第三方，或者背上一个昂贵的订阅。运维在自建场景下通常只剩两条路：一是自己写脚本拉 MaxMind 数据、拼 iptables-restore 文件，脆且难维护；二是干脆放弃，直接用 fail2ban 之类的行为检测兜底。

ntop/ipt_geofence 就是在这条缝里长出来的工具。它属于 ntop 生态（同一个团队维护 ntopng、nDPI），定位非常克制：只做一件事——把国家代码翻译成防火墙能高效匹配的集合，然后按策略放行或拦截。 不做流量解析，不做协议识别，不做威胁情报。

核心技术揭秘

这个项目的价值几乎全部压在"数据怎么进内核"这一步上，架构可以拆成三层：地理数据 → 前缀集合 → 防火墙规则。

第一层是数据源。 归属地判定必然依赖外部数据库，项目选择 MaxMind 系（GeoLite2 免费库可商用自建）。这里有个容易被忽视的难点：mmdb 是前缀树二进制格式，想要"枚举某国的全部网段"，要么遍历整棵树（很慢），要么借助官方 CSV 形式的 Blocks 表。无论走哪条路，工具都得承担"把归属地数据库转换为前缀列表"的翻译职责，且必须能容忍数据库的版本漂移。

第二层是映射，也是性能的分水岭。 一个中等国家动辄上万条前缀，如果逐条生成 iptables 规则，包过滤路径退化为线性匹配，几万条规则会让吞吐直接崩掉。正确解法是把前缀塞进 ipset（Linux）或 ipfw table（FreeBSD），内核侧用哈希或 radix 树做集合成员判断，单包匹配近似 O(1)。整个项目"能否生产可用"的关键，就取决于它有没有走这条集合路线——这也是它和一堆 GitHub 上的 shell 脚本的根本区别。

第三层是执行与生效。 围栏规则不能"边删边加"，否则中间态会放行本该被拦的流量。稳妥做法是先构建一个新集合，再整体切换引用（ipset 的 swap 语义），把变更窗口压到毫秒级。同时要处理连接状态：新的拦截规则对 conntrack 中已有的 ESTABLISHED 连接不会立即生效，想彻底断开需要额外清理会话——这是个必须写进运维手册的细节。

功能亮点与差异

跨平台是一大加分项。 绝大多数同类工具只伺候 Linux 的 iptables/nftables，而它在 FreeBSD 上走 ipfw table 这条完全不同的路径。对同时维护 BSD 边缘节点的团队，省掉了"两套脚本两套心智模型"的成本。

克制带来的可组合性。 它不试图做成守护进程全家桶，而是提供可被 cron、Ansible、CI 流水线调用的命令式能力。你可以把它嵌进"发布前收敛暴露面"的流程里，也可以让它在应急响应脚本中被调用，这种"Unix 小工具"气质在 ntop 系产品里一以贯之。

与 ntop 生态同源。 团队在流量分析侧积累的 GeoIP 使用经验，让归属地判定和数据更新这块踩坑更少，长期维护意愿也更强。相比之下，很多同类项目是个人脚本，作者一年后就失联了。

应用场景与落地建议

适合的场景很明确：暴露面收敛、合规性访问控制、以及 DDoS/扫描的粗粒度削峰。 比如只对特定国家开放的管理后台、跨境电商按市场区域做的访问限制、被境外大规模扫描时把来源整体拉黑的应急操作。

落地时有几个坑必须提前踩过：

• 先观察后拦截。 上线前开日志模式（或只做计数），跑一周看误伤率。GeoIP 对 VPN、代理、云厂商出口、CDN 回源节点的判定经常出现偏差，直接一刀切很容易把正常的跨国办公流量砍掉。
• 白名单要独立于 geo 规则。 运维跳板、监控探针、合作方 API 来源，务必用独立的 ipset 前置放行，否则数据库一更新你就把自己锁在门外。
• 注意移动网络与企业专线的特殊性。 部分运营商的出口 IP 归属地是"漂移"的，跨国企业专线更是常年被判成境外。这类流量应按 IP 而非按国家处理。
• IPv6 要单独验证。 双栈环境里 IPv6 前缀粒度远小于 IPv4，如果工具或内核只处理了 v4，会留下一条完整的绕过路径。
• 它不能替代 WAF/IPS。 地理围栏是"减面"不是"防御"，来自允许国家的攻击一样打得进来，别指望它挡住应用层漏洞。

综合评价

优点： 定位精准，用集合而非规则堆叠解决性能问题，跨 Linux/FreeBSD，依赖少，容易嵌入自动化流程，维护方有成熟的开源工程背景。

缺点： 功能面窄，策略表达能力有限（复杂条件组合仍需手写防火墙规则补足）；效果完全受制于外部 GeoIP 数据质量，而免费库的准确率和更新频率都有天花板；文档与示例相对单薄，新手上手需要一定的防火墙功底；对连接状态、日志观测等运维友好性的打磨程度，取决于版本演进。

一句话总结：它不是安全体系的骨架，但很适合做"暴露面控制"这块便宜又好用的软组织。 如果你的需求是"让世界上大部分地方连不上我的管理端口"，它比自研脚本可靠得多；如果你想靠它构建完整的访问控制体系，那你会失望——它从设计上就没打算变成那个东西。