简介：PanabitFREE_SANGUOr10_20150513_FreeBSD9.2_dev.tar.gz 是面向网络管理员、运维人员和二次开发者的一款免费网络行为审计与流量管理开发包，基于 FreeBSD 9.2 构建，可用于流量监控、用户行为审计、限速与 QoS 策略控制以及异常流量排查。压缩包共 379 个文件，约 1.79MB，以 gif、js、png 等 Web 界面素材，menu、htm、css 等菜单与页面配置，appctrl 应用识别资源、swf 图形组件、ko 内核模块及大量 CGI 管理脚本和策略配置项为主，基本覆盖从界面展示到策略执行的多个环节。已有 369 人学习，说明其在网络管理实验与旧版 Panabit 研究中有一定参考价值。读者可从中获得可部署的管理端页面与后端脚本线索、菜单注册和接口配置样例、审计与限速策略对象参考，以及按模块排查 Web 管理端、应用识别和流量控制问题的思路，适合用于实验环境搭建、功能定制和运维排错。

1. 出口只剩 40 Mbps 的那天，我把 IP 限速表删了

机房出口 100 Mbps，下午两点开始卡，路由器上只能看到一堆 IP 在抢带宽。按 IP 限速的结果很荒唐：P2P 下载的用户被限了，做视频会议的人也被限了，因为路由器根本不知道哪个包属于哪个应用。后来换成按应用识别再分配带宽的方式，问题才真正解决。PanabitFREE 就是处理这个方向的一套系统：跑在 FreeBSD 上的应用层流量管理网关，靠 DPI 识别协议和应用，再把人分进不同的带宽通道。文件名 PanabitFREE_SANGUOr10_20150513_FreeBSD9.2_dev.tar.gz 把这个东西说得很清楚：免费版、SANGUO r10 这一支、2015 年 5 月 13 日打的包、底座是 FreeBSD 9.2，后缀 dev 说明它是开发侧的内容，不是那种插上就能装的一键 ISO。它适合手上有多网口老机器、想做透明网桥限速的人，也适合想把应用识别和内核模块这层拆开看的人。

2. 拆开这个 tar.gz：底座、引擎、特征库得先分清

2.1 三层结构：动错一层会白折腾半天

流控网关看起来是一个整体，拆开其实是三层，混在一起就容易出问题。第一层是内核态，负责网卡驱动、二层桥接、转发路径和队列调度，这层的东西跟着内核版本走，ABI 一变就得重编。第二层是用户态，应用识别引擎、策略管理进程、Web 管理服务、日志都在这层，改动频率比内核高，出问题也更容易定位。第三层是特征库，也就是判断“这个包属于哪个应用”的指纹集合，端口、载荷特征、行为特征混在一起，通常单独升级，不跟着大版本走。

分清这三层的实际价值在排错。识别不准，先怀疑特征库，不要去动内核；桥接不通，先看网卡驱动和桥成员，不要去改策略；策略明明写了却不生效，多半是规则没绑到正确的接口方向，跟编译一点关系都没有。我见过不少人拿到 dev 包第一反应就是 make，结果十几分钟堆出上百行 error，最后发现只是运行机的内核是 9.1，而包里是照着 9.2 编的。

tar.gz 这种形式给的一般是构建产物加部分源码，不是完整可安装镜像。这意味着你得先确认目标机的底座能不能接住它，再谈怎么用。先别急着解，用tar -tzf看一眼顶层结构，通常就能判断出这是源码树还是已经编好的二进制集合。

2.2 解包流程和的几个必查项

下面这套顺序是我处理陌生 tar.gz 的固定动作，先看、再校验、最后才落盘，能省掉很多“解了一半发现包是坏的”的麻烦。

# 建一个干净的落地目录，路径不要带空格和中文 mkdir -p /opt/build/panabit && cd /opt/build/panabit # 先只看不落盘：确认包内顶层结构 tar -tzf /data/PanabitFREE_SANGUOr10_20150513_FreeBSD9.2_dev.tar.gz | head -40 # 统计条目数，判断规模；条目几千以上基本是源码树 tar -tzf /data/PanabitFREE_SANGUOr10_20150513_FreeBSD9.2_dev.tar.gz | wc -l # 校验完整性，这是后悔药：包坏了解出来全是玄学错误 sha256sum /data/PanabitFREE_SANGUOr10_20150513_FreeBSD9.2_dev.tar.gz # 正式解包，保留权限位 tar -xzvpf /data/PanabitFREE_SANGUOr10_20150513_FreeBSD9.2_dev.tar.gz -C /opt/build/panabit

-t的作用是只列目录不写盘，遇到超大包时这一步能帮你判断要不要先腾空间。-p保留权限位很关键，包里的脚本和二进制依赖执行位，丢掉之后会出现一堆“找不到命令”的假故障。sha256sum建议记下来，跟后面从别处拿到的同一文件对一下，能排掉传输损坏这种最难查的问题。-C指定解包目标，-v打印条目，条目太多时可以去掉。

解开之后不要急着编译，先用几条命令把包内内容摸清楚。判断产物是 FreeBSD 还是 Linux，最直接的办法是看file的输出；找内核模块就找.ko；找构建入口就找Makefile。

cd /opt/build/panabit # 看两层的目录结构，判断是源码树还是产物集合 find . -maxdepth 2 -type d | sort # FreeBSD 内核模块的典型后缀 find . -type f -name "*.ko" | head # 构建入口 find . -type f \( -name "Makefile" -o -name "Makefile.*" \) | head # 对可执行文件做类型判断，输出里应出现 FreeBSD 字样 file $(find . -type f -perm -u+x | head -20)

file的输出如果出现FreeBSD字样，说明产物和底座匹配；如果出现Linux或ELF 64-bit LSB但不带 FreeBSD 标记，那大概率是拿错了包，或者这个包是给别的产品线用的。-perm -u+x是筛出有执行位的文件，head -20只取前 20 个，避免输出太长把终端刷爆。

2.3 版本必须对齐：FreeBSD 9.2 不是随手写的版本号

内核模块的 ABI 和内核版本是强绑定的。9.2-RELEASE 和 9.2-STABLE 之间看着只差一个词，实际内核结构体布局和符号版本都可能不同，硬加载的结果通常是kldload报Invalid argument或者直接 panic。所以第一步永远是确认运行机到底跑的是什么。

# 一次看全：内核版本、发行版分支 uname -a freebsd-version -k # 内核版本 freebsd-version -u # 用户态版本，两者不一致要留意 freebsd-version -r # 如果是 RELEASE 分支会给出具体版本 # 已经加载的模块清单，确认有没有冲突的同名模块 kldstat # 尝试加载时用 -v 看详细错误，比干瞪眼强 kldload -v ./your_module.ko

freebsd-version -k和-u分开看很有必要，用户态升级过但内核没升的机器在测试环境里特别常见，这种机器上编译出来的东西运行时行为会很怪。kldstat用来排掉“同名模块已经加载”的情况，kldload -v的详细错误信息是定位 ABI 不匹配的第一手材料。

如果确实要自己编模块，别一上来就buildworld，那个在 9.x 时代的老机器上是几小时起步的。只编需要的模块就够：

# 只编单个模块，省时间 cd /sys/modules/<模块目录> make clean make -j4 make install # 如果要连带内核一起编，用 KERNCONF 指定配置名，别用默认 GENERIC cd /usr/src make buildkernel KERNCONF=<你的配置名> -j4

-j4的并行度按 CPU 核数给，老机器双核就写-j2，写太大反而因为内存不够被 OOM 杀掉。KERNCONF一定要指定自己的配置，因为模块能不能加载成功，跟你内核里把网卡驱动编进去还是做成模块、有没有开 SMP、有没有开 PAE 都有关。

注意：9.2 这个底座放到今天的硬件上，最大的拦路虎不是系统本身，是网卡驱动。动手之前先确认目标机的网卡芯片在 9.2 的驱动列表里，不在的话先解决驱动，再谈其他。

3. 从裸机到管理页能打开：形态选型和最小配置

3.1 三种接入形态，选错了后面全白搭

设备怎么接，比装什么系统更影响后面的使用体验。常见三种形态，代价差别很大。

选型的判断标准很简单：如果诉求是“搞清楚谁在吃带宽”，先上旁路，一周就能拿到真实的流量画像，还不用担责任；如果诉求是“必须把 P2P 压下去”，那只能串进去，因为旁路模式下发阻断和限速的效果很有限，报文已经过了你的设备。

网桥形态是这套系统最常用的落地方式，也是最容易出问题的方式。它的好处是对现有网络完全透明，坏处是任何一层配错，整条链路就断，而且断得很难看——不通、但看不出哪里不通。

3.2 装机之后先认网口，别急着配地址

装机完成，第一件事不是配 IP，是认网口。FreeBSD 的网口命名跟着驱动走，常见的有em0、igb0、re0、bge0，同一台机器换个插槽名字就变。网口顺序搞反是典型的血泪经验：网桥的两个成员接反了，链路灯是亮的，管理页也打不开，你会以为是系统没起来。

# 列出所有网口，顺序就是系统里的编号 ifconfig -l # 看每个口的链路状态和速率，插拔网线对照着看 ifconfig -a | grep -E "flags|media|status" # 看磁盘和分区，确认系统盘和数据盘的位置 gpart show # 看内存和 CPU，评估能开多少会话和日志 dmesg | grep -E "CPU|memory"

ifconfig -l的输出是纯名字列表，最适合拿来对照物理口。ifconfig -a加 grep 看status字段，active说明有链路，no carrier说明线没插好或者对端没起来——这一步能把“系统没起来”和“线没接对”区分开。gpart show在装机阶段用来确认分区落在哪块盘上，日志盘和系统盘分开是个好习惯。

网口认完之后，建议用标签纸把每个口的用途写上去，物理机房里贴标签这件事，做一次能省掉后面无数次拔错线。

3.3 最小可用配置：管理口和桥成员要分开

网桥模式的核心原则只有一条：管理口不要加进桥。管理口一旦成为桥成员，它的 IP 层就失效了，你会得到一个“链路通但管理页打不开”的黑匣子状态。

# 管理口单独留一个物理口，配内网地址 ifconfig em0 inet 192.168.10.1/24 up # 创建网桥，把两个数据口加进去 ifconfig bridge0 create ifconfig bridge0 addm em1 addm em2 up # 两个成员口只做二层转发，不配 IP ifconfig em1 up ifconfig em2 up # 确认桥的成员和转发表 ifconfig bridge0

addm是 add member 的缩写，一次可以加多个。两个成员口不配 IP 是有意为之：它们只做二层转发，配了地址反而会引入本地收包，出现“一半通一半不通”的怪现象。ifconfig bridge0单独执行会列出成员口和学到的 MAC 地址表，这是判断桥有没有正常工作的第一手依据。

配置项和常用值整理成一张表，装机时照着填就够：

3.4 验证流量真过了桥，而不是“看着像通了”

管理页能打开不代表业务流量通了，这两件事完全独立。验证要分两层做：二层看桥有没有转发，三层看业务能不能通。

# 在桥上抓包，确认双向都有流量 tcpdump -i bridge0 -n -c 50 # 看两个成员口的计数器增长，双向都应该在涨 netstat -I em1 -w 1 netstat -I em2 -w 1 # 看桥学到的 MAC 表，有没有两侧的设备 ifconfig bridge0 | grep -A 10 member

tcpdump -c 50抓够 50 个包就停，避免刷屏；-n不做 DNS 反解，速度快很多。netstat -I em1 -w 1每秒刷新一次计数器，正常情况下两个口的 in/out 字节数都在涨——如果只有一边涨，说明流量只进去了没出来，多半是桥少加了一个成员，或者某个口的双工/速率协商不一致。

我一般还会从内网找一台机器，ping一个外网地址，同时在这台设备上抓包，两件事一起看。ping 通但抓不到包，说明流量根本没走这台设备；抓得到包但 ping 不通，说明设备转发了但上游有问题。这两种情况的排查方向完全相反，早分清早省事。

4. 策略怎么落地：从识别结果到队列限速

4.1 一个包从进网卡到被限速，中间发生了什么

理解数据路径，后面所有“策略不生效”的问题都能自己推。入方向的包进网卡，进桥或者进路由，然后进识别引擎。识别引擎对一条新连接的前若干个包做特征匹配，端口、载荷特征、连接行为都看，匹配上之后就给这条流打一个应用标签，后续的包走快路径，只按五元组查标签，不再重新做深度检测。

打上标签之后进策略匹配。匹配条件一般包括源地址组、目的地址组、应用或应用组、时间段，命中之后执行动作：放行、阻断、限速到某个通道、或者只做记录。限速的动作最后落到队列调度器上，通道定义了这个队列的最大带宽和优先级，队列再决定哪个包先出。

这条链路上有两个地方最容易出问题。一是识别阶段，前几个包做深度检测会带来一点延迟，加密流量或者特征库太旧的时候根本认不出来，标签是“未知”，策略就匹配不上。二是队列阶段，通道的最大带宽如果设得比物理带宽还大，等于没限。

4.2 配置顺序：先建通道，再写规则，最后绑方向

配置对象之间有依赖关系，顺序错了会出现“规则写了但选不到通道”的情况。正确的顺序是通道 → 策略组 → 规则 → 绑定接口方向。

规则是有顺序的，从上往下匹配，命中即停。这意味着兜底规则必须放最后，具体的应用规则放前面。我见过把“全部放行”放在第一条的配置，后面写了二十条限速规则，一条都没生效——因为所有流量在第一条就放行了。

通道的配置也有讲究。保证带宽是你承诺给这类应用的下限，最大带宽是上限。把 P2P 的保证带宽设成 0、最大带宽设成出口的 5%，是对的；把视频会议的保证带宽设成 20%、最大带宽设成 30%，也是对的。反过来，给 P2P 设一个很大的保证带宽，就等于把其他应用饿死了。

4.3 参数怎么给：几个能直接抄的经验值

带宽规划没有标准答案，但有一套能用的起步值。出口 100 Mbps 的场景，我一般这么分：

出口带宽先扣掉 10% 左右给协议开销，100 Mbps 的线路按 90 Mbps 来规划，不然队列排满的时候实际吞吐会掉得比预期厉害。P2P 不要直接阻断，阻断会让一些客户端反复重试，反而放大连接数；压到 8% 以内，用户体感是“慢”，不会来报故障。

连接数限制是另一个维度。单 IP 连接数上限给 200 到 500 之间比较常见，具体看业务；NAT 环境下可以适当放宽，但要留意会话表大小和内存占用。连接数打满的表现是 new connection 建不起来，但带宽看起来还有富余，这个现象很有辨识度。

4.4 从命令行侧验证策略真的生效了

管理页上的数字是加工过的，想要一手数据得自己看。FreeBSD 上流控的底层常见做法是基于 dummynet 的 pipe 和 queue，即使上层做了封装，底层的统计口径还是通的。

# 看已配置的管道和队列，以及各自的包计数和丢包 ipfw show ipfw pipe show ipfw queue show # 看当前连接数最多的源 IP，找出 top talker netstat -an -f inet | awk '{print $5}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20 # 看接口层面的错包和丢包，排除物理层问题 netstat -I em1 -w 1

ipfw pipe show的输出里重点看两个数：进去了多少包、丢了多少包。包数在涨说明流量确实进了这个管道，丢包数在涨说明限速正在起作用——限速的本质就是排队加丢弃。如果包数一直是 0，那说明规则没匹配上，回到上一节检查规则顺序和绑定方向。

netstat -an那条管道命令是找 top talker 的土办法，cut -d. -f1-4取 IP 的前四段，uniq -c计数，sort -rn倒序。这个方法粗但快，不需要装任何额外工具。

注意：不要在业务高峰期改策略。改完立刻保存，很多“配置莫名其妙丢了”的情况，其实是改完没点保存就关了页面。

5. 五个把我按住过的现场：避坑与排查

5.1 桥接后全网不通，管理页也打不开

现象：按文档配完桥，链路灯正常，内网所有机器上不了网，管理页也进不去，只能接显示器看控制台。

原因：管理口被加进了桥成员，或者两个桥成员口上还留着 IP 地址。桥成员口的 IP 层会失效，管理面跟着一起断。

解决：把管理口从桥里摘出来，单独占一个物理口；确认两个成员口上没有残留 IP。排查时在控制台执行ifconfig bridge0看成员列表，再ifconfig em1看有没有 inet 地址，两个命令就能定位。

5.2 识别率低得离谱，一半流量都是“未知”

现象：管理页上“未知应用”占了 40% 以上，P2P 全跑在未知里，限速规则打不中。

原因：特征库版本太旧，认不出新版本的客户端协议；另一部分是真的加密流量，端口和载荷都看不出特征。

解决：先把特征库升到能拿到的最新版本，再看未知流量的占比。剩下那部分加密流量不要硬刚识别，改用连接数上限加行为特征来限，比如单 IP 连接数超过阈值就降速。这个思路比追求 100% 识别率现实得多。

5.3 限速规则写了，带宽一点没降

现象：规则配好了，通道也建了，管理页显示规则命中数在涨，但实际下载速度还是满的。

原因：三种可能。规则绑在了错误的方向上，比如限的是出方向，实际拥塞在入方向；通道的最大带宽设得比物理带宽还大，等于没限；或者规则顺序问题，前面有一条全放行先命中了。

解决：先看规则的命中计数，再对照方向；然后把通道最大带宽调到一个明显偏小的值（比如 1 Mbps）做验证，能降说明通道配置没问题，是参数给大了；最后检查规则顺序，把兜底放行挪到最后。

5.4 高峰期设备自己 CPU 打满，转发开始丢包

现象：白天业务高峰，设备 CPU 跑到 90% 以上，ping 的延迟从 1 ms 涨到几十毫秒，偶尔丢包。

原因：开了全量会话日志或者全量抓包记录，每条连接都要落盘；规则条数太多，几百条规则逐包匹配；硬件本身性能不够，老机器的转发能力有限。

解决：先关日志，这一步通常能立刻降下来 20 到 30 个百分点；然后合并规则，把能归到一个地址组的 IP 合并，把能归到一个应用组的协议合并；最后才是考虑换硬件。日志这种功能，排查期开，稳定期关，别一直开着。

5.5 重启之后配置回到默认，白配一遍

现象：断电或者重启之后，所有策略、地址组、通道全没了，回到出厂状态。

原因：配置没保存；或者系统盘是 U 盘、CF 卡这类易损介质，写入失败；也可能是升级过程中配置文件被覆盖。

解决：改完配置立刻保存，并且导出一份配置备份到别的机器上。系统盘用 U 盘的设备，定期检查dmesg里有没有介质读写错误。升级前先备份，升级后先比对，这个动作固定下来就不会再吃亏。

6. 进阶：把“识别准确率”量出来，而不是看管理页给的百分比

管理页上那个识别率是个加工过的数字，信它容易吃亏。真实做法是自己量：在桥的两侧同时抓包，用同一段时间窗口的数据对比，看设备认为的 top talker 和实际抓到的 top talker 差多少。

先抓包，落到文件，注意两侧同时开始，时间窗口对齐：

# 桥内侧抓 60 秒，只抓 IP 层，存成 pcap timeout 60 tcpdump -i bridge0 -n -s 96 -w /tmp/in.pcap # 如果设备上有两个独立网口，也可以分别抓，便于对比方向 timeout 60 tcpdump -i em1 -n -s 96 -w /tmp/em1.pcap

-s 96只抓每个包的前 96 字节，够看 IP 头和部分载荷，又能大幅压小文件，抓 60 秒不会把盘写满。timeout 60是防止忘了停，抓包进程挂后台跑一晚上把盘写爆的事故我见过不止一次。

然后把 pcap 里的源 IP 和字节数统计出来，跟管理页的会话表对照：

# 从 pcap 文本里粗统计每个源 IP 的字节数，用来和管理页的 top talker 对照 import re import sys from collections import defaultdict # tcpdump -n 的文本格式里，源 IP 在 "IP " 之后 pat = re.compile(r"IP (\d+\.\d+\.\d+\.\d+)\.\d+ >") counter = defaultdict(int) with open(sys.argv[1], encoding="utf-8", errors="ignore") as f: for line in f: m = pat.search(line) if not m: continue # 用行长度粗略代替包长，做排序够用，不要当精确值 counter[m.group(1)] += len(line) # 取前 20 名，跟管理页对照 for ip, n in sorted(counter.items(), key=lambda x: -x[1])[:20]: print(f"{ip}\t{n}")

这个脚本的定位是“粗排”，len(line)代替真实包长只影响绝对数值，不影响排序，用来找 top talker 足够了。要精确字节数就读 pcap 头里的长度字段，或者直接用tcpdump -r in.pcap -n | awk之类的方式算。脚本的输入是tcpdump -r /tmp/in.pcap -n的输出重定向成的文本文件，跑之前先转一道。

对照的方法很简单：管理页给出的 top 10 源 IP，和脚本算出来的 top 10，重合度低于七成，说明识别或者会话统计这一层有问题，先别急着调策略。重合度高但限速效果不好，那问题在通道参数和规则顺序上，方向完全不同。

容量边界也要自己摸。找一台机器用限速工具打到出口带宽的 80%，持续十分钟，同时观察设备的 CPU、会话数、丢包计数。三个指标里任何一个先到瓶颈，就是这台设备的实际上限。这个数字比任何标称参数都可靠，因为它是你自己环境里跑出来的。

从那以后我每次上线前都先旁路跑 24 小时，把实际流量的 top 20 跟管理页对一遍，对不上就先不动策略，先查识别。这个习惯帮我避掉了好几次“策略上线才发现一半应用认不出来”的尴尬。希望帮到你。

本文还有配套的精品资源，点击获取