> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20190102-freebsd-ru-men/we-get-letters.md).

# 读者来信

* 原文链接：[We Get Letters](https://freebsdfoundation.org/our-work/journal/browser-based-edition/)
* 作者：**MICHAEL W LUCAS**

来信请寄 <letters@freebsdjournal.org>

***

亲爱的来信专栏小工：

这些防火墙都是怎么回事？我们会不会去掉其中一些？还有，你真的会回答我们寄来的任何问题吗？

谢谢， Troublemaker（捣蛋鬼）

***

亲爱的 Troublemaker：

是的，任何问题我都会回答——前提是它能通过 FreeBSD 期刊备受尊敬的编辑委员会的审查。提醒你，他们不让我用“怯懦无能”、“呜咽”这类词，所以我的回答可能没你期望的那么有用。他们几乎肯定会否决“胆小如鼠”，尤其是我用它来指代他们时，所以我不会。

公平起见，我自己也有要否决的内容。

我全心全意否决你的问题。“防火墙”这个词毫无意义。

如果你把我那位原始的 Unix 导师从低温胶囊里解冻（并处理掉那些乏味的琐事——比如治好他所有的癌症、重启他的心脏、封好所有被冰晶撑破的细胞，因为自制的低温冷冻实际上等同于严肃的死后冻伤——尤其是在 2003 年那场为期三天的“大停电”很可能耗尽了他的 UPS 之后），他不会认出我们今天称之为“防火墙”的任何东西。我深入挖掘了上古邮件列表，试图找出互联网上的第一个防火墙——付出了你肯定不会充分感激的那一丝努力——结果完全被这种含糊不清堵了回去。

防火墙最早是一种不可燃的实体墙。在两栋建筑之间建一道防火墙，你就能把其中一栋付之一炬而不烧塌另一栋——这对匈奴人想必相当便利，他们想在洗劫罗马、放火焚烧神庙之后再去掠夺隔壁的国库。至少，我的前辈们是这么告诉我的。我那本 1933 年版《牛津英语词典》里没有“firewall”一词，而牛津大学对罗马了如指掌，所以我很怀疑早期互联网工程师只是编出这套词源，看看我们是否会相信。

如今我们对防火墙形成了几种不同的思路：包过滤与代理。

包过滤器调节哪些连接可以通过。你可以配置主机的包过滤器来保护该主机，或者把包过滤器放在整个网络前端，控制 IP 层对网络的访问。包过滤器必须与内核集成，除非你对待性能的态度像对待政客那样充满轻蔑。FreeBSD 自带三个：IPFW、IP Filter 与 PF。

代理会终止所有通向外部世界的 TCP/IP 连接，在应用栈的更高层检查流量，并发起一个新请求。FreeBSD 在包集合中包含数十种这类小东西。在 Ports 索引中搜索“代理”会得到 981 个结果，虽然我很确定其中相当一部分其实并非代理，但我懒得去审计整个清单，所以我们就用那些众所周知的标准，比如 Squid、SOCKS 与 relayd。在上一个千年里，我靠安装并支持 FireWall Tool Kit——元祖代理——谋生，日子过得相当不错。业余时间里，我乐此不疲地为 FWTK 起各种滑稽的逆向名。

那些嘴里挂着 devops、serverless 的年轻人觉得包过滤器防火墙就是全部。然后他们的区块链 dotcom 崩盘了。他们手忙脚乱地去找不太赚钱的工作，一接触代理就抽搐。许多跨国公司以合规、数据控制、或某种对“安全”的模糊幻觉的名义，禁止所有未经代理的互联网连接。在这些公司里开通一条直连外部的 TCP/IP 连接，类似于经鼻窦自我摘除脾脏。

这些“防火墙相关的东西”是怎么进到 FreeBSD 里的？

因为有人在维护。

为什么有人维护？

因为他们需要。

没人会把我们匆忙生活中所剩无几的宝贵分钟，花在自己不需要的代码上被反复锤打。我维护了几年 mod\_auth\_xradius，因为我迫切需要它把 Apache 与公司的认证系统粘合起来。要么维护一个 Port，要么把一切都跑在某个我不愿提名的平台上——这个平台与“Abominable Dysentery（可怕的痢疾）”押头韵，所以我学会了发补丁、应付 Bugzilla 等等。这一切偶尔令人沮丧，但仍胜过从 Event Obscurer 中强行榨取有用信息。

顺便说一句，我推荐 FWTK。它仍在 fwtk.org 上。2.1 版于 1998 年 2 月 27 日发布，不过 1998 年 3 月 2 日又冒出第二个 2.1 版，因为那时我们还没发明像样的版本号管理。正是因为 FWTK，我才为 Squid 与 IPFW 的到来喝彩；正是因为它们，我才为 IP Filter 欢呼；正是因为它，我才为 PF 与 relayd 的出现举办庆典。

最近那次发布如今已到了可以在拉斯维加斯合法喝酒下注的年纪。

顺便说一句，2019 年 3 月 2 日我会到拉斯维加斯。或许我该为 FWTK 办一场成人礼。

***

亲爱的来信专栏小工：

我指的是包过滤器，你这只傻鹅。

如果你真回答任何问题：衣衫不整的程序员骑独轮车，与衣着得体的程序员骑自行车，区别是什么？

Troublemaker

***

亲爱的 Troublemaker：

再说一遍：因为人们需要它。

FreeBSD 中的任何代码，无论是内核还是用户态，都需要照看与喂养。程序员会冒出“支持新硬件”、“没人再用 twoax 了”这类古怪想法，于是他们以进步的名义不断更改代码内部结构与 API。把网络栈改造成支持 40GB 以太网卡，就得有人评估包过滤器代码是否仍能正常工作。

如果没人去调整那段代码，最终它会失效，而某人——按传统，是个丹麦人——会把它从源码树中砍掉。

IPFW 是 FreeBSD 元祖级的防火墙。它是许多资深开发者的心头好，他们在九十年代末学会了它，不明白为什么还有人想要更简单的东西。我曾用它在本地的办公室里模拟一条跨洋链路，因为 Web 开发者应当和他们倒霉的用户一样受苦。

IP Filter 是为那些必须在多种 Unix 上使用同一款包过滤器的受谴灵魂准备的。我不知道他们做了什么才被判处多平台折磨，但那必然是令人发指的——即便以我那极高的标准衡量。

PF 是迄今为止最流行的通用包过滤器。它从 OpenBSD 移植而来，之后又 fork 以适配 FreeBSD 的内核锁机制，所以别自讨没趣问维护者什么时候会从 OpenBSD 重新 import。不会的。

我那反复进行但完全不科学的调查表明，大约 80% 运行包过滤器的 FreeBSD 用户使用的是 PF。

附：衣着。

***

**MICHAEL W LUCAS**（<https://mwl.io>）著书过多，包括全新的第三版《Absolute FreeBSD》、《PAM Mastery》、《Butterfly Stomp Waltz》。George Neville-Neil 贿赂他写这个专栏，Lucas 至今仍在等付款。请把问题寄至 <letters@freebsdjournal.org>。来信将按其令专栏作家困惑、背叛或迷惘的顺序作答，并可能为了他自己的消遣而编辑。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20190102-freebsd-ru-men/we-get-letters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
