もっとたくさん持ってたらいいな。私は本物の紙で作った控えめな図書館を持ってるんだけど、No Starchの本は質のいい紙と素晴らしい製本で本当に嬉しい。最近のオンデマンド印刷のO'Reillyの本もいくつか持ってるけど、なんか自分で印刷した安っぽいものみたいに感じる。残念ながら高いから、選ぶのにすごく慎重にならざるを得ないんだよね。

そうそう。私のお気に入りは、複雑なシステムプロジェクトをゼロから実装するためのガイドブックだね。Nora Sandlerの「Cコンパイラを書く」とか、Sy Brandの「デバッガを作る」とか。もっとたくさん出してほしいな。

マーシャル・カーク・マックキューシック博士によると（最近のBSDカンファレンスの一つで発表されたことだけど）、No Starch Pressが「FreeBSDオペレーティングシステムの設計と実装」の第3版を今年の後半に出版するらしいよ。

NostarchやLeanpubみたいな出版社から直接電子書籍を買ってるよ。（実際、この本の古い版も持ってる。）著者が直接売ってる本もいくつかあるし、どれもDRMフリーだよ。自分を消費者/読者として尊重しない出版社や販売者は避けるようにしてる。みんなもっと良い条件を求めるべきだよ、そうしないと、購入した本を簡単に削除する独占企業ができちゃうから。

スターチは最高だね！彼らからたくさん学んだよ。

nftablesのドキュメントサイトはすごく良いよ。https://wiki.nftables.org/wiki-nftables/index.php/Main_Page。どんな本にも頼らない方がいいね。

スティーブ・スーリングの「Linux Firewalls」にはnftablesが載ってるよ。基本を知るには良い本だね。

タイトルを読んで、一瞬Pathfinderのエディションを全部見逃したかと思ったよ。

電子書籍リーダーとDRMフリーの電子図書館があるよね。

自分も同じことをしようとしたことがあって、今でもやろうかなって考えてる！OpenBSDを学び始めた頃に買った小さな山の中にこの本の古い版がどこかにあるんだ。最近は全然参照してないけど、棚にあるOpenBSDのエリアはいい感じだよ。

nftablesより遅いよ。

約400のルールを持つpf.confを管理してるけど、直感的で作業してて楽しいよ。ソースコードを編集してるみたいな感じで、最初にホスト、ネットワーク、ポートの宣言があって、次にNATと出口用のセクション、その後に各VLANのpass in/pass outルールがあるんだ。tmuxセッションでpflog0インターフェースをtailして、pass/blockを監視してるし、ルールセットを簡単に編集して再読み込みできる便利な関数を.profileに入れてるよ。function pfedit { vi /etc/pf.conf && \ pfctl -f /etc/pf.conf && \ { c=pfctl -s rules | wc -l | tr -d ' '; printf 'loaded %s rules\n' "$c"; } } これでファイルを編集用に開いて、ルールセットを再読み込み（これでバリデーションもされる）、成功したらルールの数を返してくれるんだ。

彼らのBDFLはBCブレイクが素晴らしいと思ってるみたいで、「もっと良い場所に行ける」って言ってたのを覚えてる。ルールの構文を変えてpfを何度も壊すことを許可してるから、以前の版の本は突然古くなっちゃって、無数のチュートリアルやフォーラムの投稿も同様にね。これだけはM$が正しいと思うけど、ビジネス環境ではそんなことしないよね。自宅ラボ以外でpfを使うことはないな。

何年もLinuxをゲートウェイとして使ってないから、pfとiptablesの比較しかできないけど、二つの大きな違いはルールの適用方法とログの取り方だね。pfのルールはiptablesとはちょっと逆に動く。パケットは全てのルールセットを通過して、最後にマッチしたルールが勝つ感じ。これを「quick」ディレクティブでショートカットできるけど、iptablesから来るとちょっと慣れが必要かも。pfのログはiptablesみたいにsyslogと自動で統合されないから、自分の使い方に合わせたログシステムを設定することが求められるよ。やり方はいくつかあって、プロダクション環境ではどちらにしてもやることになるけど、honelabのセットアップだと余計な心配が増えるね。pfは好きだけど、ファイアウォールに不慣れな人にはあまりおすすめしないかな。

パケットフィルターだけが必要なら問題ないけど、2026年には多くのプロダクション環境がパケットフィルターだけで済むとは思えないな。ホストファイアウォールとしてはもちろん大丈夫だと思うけど、質問はpfをネットワークファイアウォールとして使うことについてだよね。脅威の状況を考えると、通常は脅威保護が必要だよ。少なくとも、レピュテーションリストからのほぼリアルタイムの更新が必要だね。pfでそれをスクリプト化することもできるけど、あんまり楽しくないよ。実際には、プロトコルの解析や、場合によってはボックス上での復号化とペイロード分析ができることが重要だと思う。最近では単にパケットフィルタリングをするだけではあまり意味がないし、コンプライアンスが必要なプロダクション環境や本気で気にするものは、IPSやレイヤー7ファイアウォール機能の背後に置くべきだよ。pfはそれをやらないからね。これを実現するのにPalo AltoやCiscoを使う必要はないけど、パケットフィルタリングだけが必要なら良い選択肢だと思うよ。

iptablesを扱わなくて済むのは嬉しいけど、iptables -Aのクソみたいな内容が無数のチュートリアルやLLM FFNヘッドの重みの中に埋め込まれてるから、これから何十年も頭に留めておかないといけないだろうね。

自分の経験では、PFはフィルタリングやNATの考え方において商用ファイアウォールにもっと近いと思う。Linuxでは、nftablesを使っても「チェーン」の概念があって、これはipchainsの時代まで遡るんだよね。個人的には、これが特に役立つ見方だとは思えないな。PFでは、単に入出力やインターフェースに基づいてポリシーの決定ができるし。あと、プレルーティングやポストルーティングのチェーンにポリシーを適用する理由が、PFの他の場所でより簡単に達成できない限り、役に立つアプリケーションを見たことがないんだ。さらに、設定ファイルからではなく、単にポリシーを挿入したり削除したりするコマンドにはあまり好感を持っていないよ。（nftの「config」ファイルは、実際にはコマンドを順次実行するスクリプトに過ぎない。）そういうのが欲しい人の気持ちはわかるけど（プログラム的な作業が楽になるだろうし）、自分にはあまりメリットがなかったな。まあ、こういうことをやるのは久しぶりだから、細かいところは疎くなってるかもしれないけど、間違ってたら教えてほしいな（笑）。