如何用Node.js实现OpenBSD PF防火墙规则的Mock测试与可视化输出？

PF（Packet Filter）是OpenBSD引以为傲的防火墙系统，后来也被FreeBSD、NetBSD移植采用。它的规则文件pf.conf表达能力很强，宏、表格、锚点、状态跟踪选项一应俱全，但也正因为语法灵活，人工review规则文件时非常容易遗漏冲突或顺序问题。直接把新规则推到网关上测试显然不现实，一次失误就可能把自己锁在门外。于是就有了这样一个思路：用Node.js写一个PF规则的解析器和模拟引擎，把pf.conf加载进内存里跑单元测试，最后把规则匹配路径输出成图片，这就是本文要讲的PF Mock2Image方案。

PF规则解析器的设计与实现

整个方案的第一步是把pf.conf文本解析成结构化数据。PF配置由若干行组成，常见的指令包括block、pass、match、table、anchor以及宏定义。解析器不追求覆盖全部语法，只需要支持测试中会用到的子集即可。词法层面，PF用空格和制表符分隔token，注释以#开头，宏引用形如$ext_if，这些都要在分词阶段处理好。

下面是一个简化版解析器的核心代码。它逐行读取配置，先剥离注释、展开宏，再把每条规则拆成action、direction、协议、地址端口等字段，最后返回一个规则对象数组，供后续的模拟引擎消费。

const fs = require('fs');

function tokenize(line) {
  return line.trim().split(/\s+/).filter(Boolean);
}

function expandMacros(tokens, macros) {
  return tokens.map(t => {
    if (t.startsWith('$')) {
      return macros[t.slice(1)] || t;
    }
    return t;
  });
}

function parseRule(tokens) {
  const rule = { action: tokens[0], raw: tokens.join(' ') };
  for (let i = 1; i < tokens.length; i++) {
    const t = tokens[i];
    if (t === 'in' || t === 'out') rule.direction = t;
    else if (t === 'proto') rule.proto = tokens[++i];
    else if (t === 'from') rule.from = tokens[++i];
    else if (t === 'to') rule.to = tokens[++i];
    else if (t === 'port') rule.port = tokens[++i];
    else if (t === 'keep' || t === 'flags') { /* 状态与标记选项 */ }
  }
  return rule;
}

function parsePfConf(path) {
  const macros = {};
  const rules = [];
  const lines = fs.readFileSync(path, 'utf8').split('\n');
  for (let raw of lines) {
    const line = raw.replace(/#.*$/, '').trim();
    if (!line) continue;
    if (line.includes('=')) {
      const [name, value] = line.split('=').map(s => s.trim());
      macros[name] = value;
      continue;
    }
    const tokens = expandMacros(tokenize(line), macros);
    rules.push(parseRule(tokens));
  }
  return rules;
}

module.exports = { parsePfConf };

这个实现有几个值得注意的点。第一，宏展开必须在解析规则之前完成，否则$ext_if会污染地址字段。第二，PF的地址字段支持any、CIDR网段和表格引用<tablename>，真实实现里需要一个专门的地址匹配函数而不是简单的字符串比较。第三，PF遵循“最后匹配的规则生效”语义，这和iptables的“首条命中即返回”完全不同，模拟引擎必须准确复现这一点，否则测试结果毫无意义。

内存模拟引擎：如何复现PF的匹配语义

解析只是准备工作，真正的价值在于模拟引擎。所谓Mock，就是构造一个虚拟的数据包对象，包含源地址、目的地址、协议、端口等字段，然后让它在规则集合上“走一遍”，观察最终的判定结果和沿途命中的规则。PF的评估逻辑可以概括为：自上而下逐条评估，pass和block都会记录，最后一条命中的规则决定数据包的命运，除非规则带quick关键字提前终止评估。

const { parsePfConf } = require('./parser');

function ipToInt(ip) {
  return ip.split('.').reduce((acc, o) => (acc << 8) + Number(o), 0) >>> 0;
}

function cidrMatch(packetIp, cidr) {
  if (cidr === 'any') return true;
  const [net, bits] = cidr.split('/');
  const mask = bits === undefined ? 0xFFFFFFFF : (~0 << (32 - Number(bits))) >>> 0;
  return (ipToInt(packetIp) & mask) === (ipToInt(net) & mask);
}

function evaluate(rules, packet) {
  const hits = [];
  let verdict = null;
  for (const rule of rules) {
    if (rule.direction && rule.direction !== packet.direction) continue;
    if (rule.proto && rule.proto !== packet.proto) continue;
    if (rule.from && !cidrMatch(packet.src, rule.from)) continue;
    if (rule.to && !cidrMatch(packet.dst, rule.to)) continue;
    hits.push(rule);
    verdict = rule.action;
    if (rule.raw.includes('quick')) break;
  }
  return { verdict, hits };
}

module.exports = { evaluate };

引擎的关键设计是把“判定结果”和“命中轨迹”一起返回。只返回verdict的话，测试失败时你只知道包被拦了，却不知道是被哪条规则拦的。返回完整的hits数组后，配合断言库可以做更精细的测试，比如断言某条关键规则一定出现在命中链中，或者断言某条废弃规则从未被命中，后者是清理僵尸规则的利器。

引擎的局限也要说清楚。PF真实功能中的状态表、ALTQ队列、锚点递归加载、标签等特性，这个简化引擎没有覆盖。如果测试场景涉及锚点，可以在解析阶段把anchor指令展开成子规则列表，让evaluate函数递归处理，思路是一样的。状态跟踪的模拟则更复杂一些，需要维护一个会话表来记录已建立的状态，属于进阶话题。

Mock2Image：把规则命中路径渲染成图

有了模拟引擎，最后一步是把测试结果可视化，这就是Mock2Image的含义。思路很直接：把数据包的评估过程画成一张流程图，每个节点是一条规则，命中路径用高亮颜色标出，最终判定用绿或红的结束节点表示。Node.js生态里可用sharp、node-canvas或者直接生成Graphviz DOT文本再调用外部渲染。最轻量的方案是生成SVG字符串，零外部依赖，可直接嵌入CI报告或HTML邮件。

function hitsToSvg(hits, verdict) {
  const nodeH = 60, gap = 20, width = 640;
  const height = hits.length * (nodeH + gap) + 80;
  let svg = `<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}">`;
  hits.forEach((rule, i) => {
    const y = i * (nodeH + gap) + 10;
    const color = rule.action === 'pass' ? '#2e7d32' : '#c62828';
    svg += `<rect x="20" y="${y}" width="${width - 40}" height="${nodeH}" rx="8" fill="#f5f5f5" stroke="${color}" stroke-width="2"/>`;
    svg += `<text x="35" y="${y + 25}" font-size="13" fill="#212121">#${i + 1} ${rule.action}</text>`;
    svg += `<text x="35" y="${y + 45}" font-size="11" fill="#616161">${rule.raw.slice(0, 60)}</text>`;
    if (i < hits.length - 1) {
      svg += `<line x1="${width / 2}" y1="${y + nodeH}" x2="${width / 2}" y2="${y + nodeH + gap}" stroke="#9e9e9e"/>`;
    }
  });
  const endY = hits.length * (nodeH + gap) + 10;
  svg += `<text x="20" y="${endY + 20}" font-size="16" font-weight="bold" fill="${verdict === 'pass' ? '#2e7d32' : '#c62828'}">最终判定: ${verdict}</text></svg>`;
  return svg;
}

const fs = require('fs');
const { parsePfConf } = require('./parser');
const { evaluate } = require('./engine');

const rules = parsePfConf('pf.conf');
const result = evaluate(rules, { direction: 'in', proto: 'tcp', src: '203.0.113.5', dst: '192.168.1.10' });
fs.writeFileSync('result.svg', hitsToSvg(result.hits, result.verdict));

图片输出的价值在团队协作中特别明显。当一次变更被CI拒绝时，附上命中路径图，reviewer一眼就能看出包是在哪条规则上被拦的，比翻几百行日志直观得多。如果需要PNG格式，用sharp库一行代码就能完成SVG到PNG的转换，或者调用Graphviz的dot命令渲染更复杂的拓扑。

集成到CI流程与测试用例组织

最后谈一下工程化落地。测试用例建议用Mocha或Jest组织，每个用例描述一个业务场景，例如“内网主机可以访问DMZ的Web服务”、“外网禁止访问管理端口”。用例数据可以放在JSON文件里，和规则文件一起纳入版本管理，这样规则变更提交时CI自动跑全量用例，任何行为变化都会被立刻捕获。

const assert = require('assert');
const { parsePfConf } = require('./parser');
const { evaluate } = require('./engine');

describe('PF规则回归测试', () => {
  const rules = parsePfConf('test/fixtures/pf.conf');

  it('允许外网访问HTTPS服务', () => {
    const r = evaluate(rules, { direction: 'in', proto: 'tcp', src: '203.0.113.5', dst: '10.0.0.80', port: '443' });
    assert.strictEqual(r.verdict, 'pass');
  });

  it('禁止外网访问SSH管理端口', () => {
    const r = evaluate(rules, { direction: 'in', proto: 'tcp', src: '203.0.113.5', dst: '10.0.0.80', port: '22' });
    assert.strictEqual(r.verdict, 'block');
  });
});

这套方案的本质是把防火墙规则当代码来管理：解析器相当于编译器前端，模拟引擎相当于解释器，Mock2Image相当于覆盖率报告。它不能完全替代真机测试，比如内核级NAT行为、网卡路由这些只有真实环境才能验证，但在规则逻辑层面的回归检查上，它的成本几乎为零。对于频繁变更防火墙策略的团队来说，把pf.conf纳入测试流水线，是提升变更信心性价比最高的手段之一。

Node.jsOpenBSD PFMock测试修改时间：2026-09-09 15:41:26