VPN クライアントと LAN：分離ゾーンを使うべき場面

トンネルインターフェースを LAN ゾーンに入れるのは、動く VPN への最短経路であり、たいていは誤った既定値です。それはリモートクライアントに有線 LAN と同じ信頼を与えますが、作業がそれを求めることはほとんどありません。分離ゾーンは数本のルールを要し、境界を見えるものにします。判断すべきはゾーンの優劣ではなく、あなたの網に当てはまる三つの条件です。

ゾーン名は何も暗号化せず、利用者を認証しません。ファイアウォールの方針モデルのためにインターフェースをまとめるだけです。

ゾーン所属が実際に制御するもの

ゾーンはファイアウォールのモデルにおいてインターフェースや通信をまとめます。その input・output・forward の設定が、それぞれ異なる役割を司ります。input はルーター自身への通信であり、forward はそれを通過して別のホストへ向かう通信です。OpenWrt のゾーンの文書が input・output・forward を別々の設定として扱うのは、まさにこの理由によります。

VPN ゾーンから LAN ゾーンへの許可は、自動的に逆向きの許可にはなりません。forward のルールは向きを持ち、クライアントからサーバーへの通信を許すルールはサーバーからクライアントへのセッションを許しません。サーバーへ接続を開けるクライアントは、サーバーが逆方向に接続を開けるクライアントではありません。

この区別こそ分離ゾーンを有用にする理由であり、向きと役割をそれぞれ明示できます。向きはルールの横に書いてください。

判断その一：input、forward、それとも両方

リモートクライアントがルーターから DNS を必要とするなら、そのサービスに限って input を許可します。ファイルサーバーに届く必要があるなら、その宛先への forward を許可します。ほとんどの VPN 設計は両方を必要としますが、対象のサービスは異なります。

すべてのローカルサービスへの広い input アクセスは、ほぼ決して必要ありません。ルーターの管理は、アプリへのアクセスとは別の判断として扱います。ルーターが DNS に答えるだけでよいなら、その一本の許可を書き、残りは閉じたままにします。

判断その二：リモートクライアントが必要とする資源

ルールを書く前に、クライアントの範囲、宛先、そして VPN が提供すべきサービスを列挙します。宛先の一覧はファイアウォールの移行を越えて残るため、信頼のラベルより役立ちます。

管理用インターフェースは、通常のアプリへのアクセスとは分けておきます。ウィキに届くリモートクライアントが、そのためにルーターの管理画面やハイパーバイザーのコンソールを必要とするわけではありません。

許可した宛先が先へ転送できる場合、ゾーンの境界はファイアウォールで止まり、宛先がその先で何をするかには及びません。

判断その三：境界をどう証明するか

変更のたびに、許可した流れと意図的に拒否した流れを試します。一つのサイトが読み込めることを示しても、意図しない広い許可は明らかになりません。VPN クライアントのアドレス範囲から試し、LAN からは試さず、失敗を期待する向きも含めます。両方の結果をルールの横に記録します。

リモートゾーンの方針を変える前に、ゲートウェイの復旧手段を確保します。実行時の編集ではなく永続的な管理設定を使わないと、次の再起動で古い信頼が戻ります。以前の設定の複製を端末の外に保管しておくことが、最も安い巻き戻しになります。

網が成長したら、所属とルールの目的を文書化します。新しく接続したインターフェースが、便利なゾーン名を付けられたというだけで特権を引き継いではなりません。