VPN 利用者に必要なのはプリンター 1 台で、LAN 全体ではない

ルールは正しく見えるのに、プリンターは依然として拒否する。あるいはプリンターは動くが、同じ利用者がファイルサーバーにも到達できてしまい、こちらのほうが悪い。どちらの結果も通常は同じ原因から来る：狭いルールが、より広い何かをすでに許可していたルールセットに追加されたのだ。実際の順序を読めば、新しいルールを書く前に結果を説明できる。

症状：狭いルールが何も変えなかった

専用の VPN プール、プリンターのアドレス一つ、TCP 631 の許可ルールというのは妥当な設計だ。それがまったく変化を生まないとき、最初に疑うべきは、トラフィックがそのルールに一度も届いていないことだ。ルールは、評価順でその位置に到達したトラフィックについてのみ判断する。フィールドは確認しやすく、失敗の原因になることはまれだ。

反対の症状は見落としやすい。印刷ジョブは成功し、この利用者が決して到達すべきでないファイル共有への接続も成功する。つまり、より前の何かがすでに LAN を許可していたということだ。

どちらの症状も、新しいルールのフィールドではなく順序を指している。一方は決して一致しなかったルールであり、もう一方は早すぎる段階で一致したルールだ。

トラフィックが実際に当たるルールセット

pfSense はインターフェースごとにルールを評価し、OpenVPN には独自のタブがあり、そのルールはすべてのサーバーとクライアントのインスタンスに適用される。これらのルールは、特定の OpenVPN インターフェースに割り当てられたルールより先に処理される。したがって OpenVPN タブに残された広い許可は、インターフェースのタブが何と言おうと、この利用者にも適用される。この順序を変更記録にコピーすれば、レビューは GUI を開かずに確認できる。

だからこそ、新しい狭い許可はアクセスを差し引くことができない。ファイアウォールのルールは許可を追加するものであり、以前の一致から許可を奪うことはない。

実際の一覧を上から読み、トラフィックに一致する最初のルールで止める。その最初の一致が判断であり、その下にあるものはすべてそのフローにとって到達不能だ。

印刷ジョブから許可ルールを書く

プリンターからではなく、ジョブから始める。利用者が必要とするのはプリンターのアドレス上の印刷サービスであり、ルールはそのアドレス、そのプロトコル、そのポートを指定する。VPN プールのエイリアスとプリンターのエイリアスが、ルールを読みやすく保つ。

ウィザードを満足させるために検出用や管理用のポートを追加したくなる気持ちを抑える。プリンター全体を許可するルールは、印刷キューを許可するルールとは別のポリシーだ。

プリンター自身の認証はそのまま残す。ネットワークの許可はその代わりにはならない。キュー単位のアカウントが、誰が何を印刷できるかを制御する正しい手段だ。

六つの値が意図のすべてを担う：アクションとしての許可、ファミリーとしての IPv4、プロトコルとしての TCP、送信元としてのプールのエイリアス、宛先としてのプリンターのエイリアス、ポートとしての 631 だ。この六つを超えるものは、要求されたものとは別のポリシーである。

LAN の許可なしでクライアントに経路を与える

クライアントにはプリンターのアドレスへのルートが必要であり、オフィス側には VPN プールへの応答経路が必要だ。単一の /32 をプッシュするとクライアント設定が狭く保たれ、トラブルシューティングに役立つ。これは認可の境界ではない、クライアントは自分でルートを追加できるからだ。

キューを名前で指定するなら、リゾルバーへの依存を別途定義する。一つの名前を解決するために LAN 全体を許可するのは、ジョブが必要とするよりはるかに大きな変更だ。

プールへ戻すルーティングと送信元の変換のどちらかを意識して選ぶ。どちらも機能し、それぞれがログから別のものを隠す。

ジョブだけでなく拒否も試す

VPN 利用者から小さく機密性のないジョブを一つ送信し、次に拒否されるべき LAN リソースとファイアウォール自身の管理ページを試す。三つのテストは同じセッションに属する、ポリシー全体を見る唯一の方法だからだ。印刷ジョブの成功だけでは、境界についてほとんど何も証明できない。

導入をプリンター専用と呼ぶ前に、IPv6 と他のアクティブな VPN 経路を確認する。一方のアドレスファミリーで狭いルールセットが、もう一方では完全に開いていることがある。