別のNATを足す前に、プライベートLAN間をルーティングする

内部ファイアウォールが二台、プライベートな通過セグメントが一本、そして各LANの数台のホストを相手側と通信させたいという要望。反射的にVPNを立てたり、二層目のNATを足したりするが、どちらの反射も問題の大きさに比べて高くつく。通常のルーティングで足りるのは、三つの条件が揃うときだ。アドレス範囲が重複していないこと、双方が相手LANへ戻りトラフィックを送れること、通過セグメントがそのデータにとって十分に信頼できること。何かを設計する前にこの三つを確認する。どれか一つが欠けるだけで答えが変わる。

設計を決める三つの条件

第一の条件はアドレス空間だ。両方のLANが同じRFC 1918ブロックを使っているなら、ルーティングでは区別できず、変換は任意ではなく避けられないものになる。第二は戻り経路である。AからBへの経路は、BがAのLANへの到達方法を知らなければ役に立たない。非対称な知識こそ、ルーティング設計が応答を静かに落とす最も一般的な理由だ。

第三は信頼だ。ルーティングはパケットを運ぶが、保護はしない。一棟の建物内のプライベートな通過セグメントは、プロバイダへの引き渡しや、共有キャンパスバックボーンを横断する回線とは別物である。セグメントが信頼できないなら、答えは二台のファイアウォール間のトンネルであり、以下のルーティング計画はその内側でもそのまま当てはまる。

三つが同じ方向を向くときだけ、単純な設計が勝つ。どれか一つが破綻したら、変換で覆い隠すのではなく、その条件そのものを明示的に直す。NATは失敗を隠すだけで、解決はしない。

通過網の上に経路計画を組み立てる

各ファイアウォールに共有セグメント上のアドレスを与え、遠隔LANごとに一本の具体的な経路を追加する。既存設定のほかの部分は動かす必要がなく、とくにインターネット向けのデフォルト経路は今ある場所に正確に留めなければならない。デフォルト経路を対向ファイアウォールに置き換えると、無関係な宛先まで通過網経由で送ることになり、求められている変更よりはるかに大きい。pfSenseのスタティックルーティングのドキュメントもこのプラットフォームについて同じ「経路＋ゲートウェイ」モデルを説明しており、実際に使うファイアウォールにも同等の設定がある。

ファイアウォールAは10.30.0.0/24を、ファイアウォールBは10.40.0.0/24を受け持ち、二つの通過アドレスは192.0.2.0/24上にある。各LANのホストはローカルのファイアウォールをゲートウェイとして使い続けるので、新しい状態は両側に一本ずつの経路だけだ。Linuxベースのファイアウォールでは同じ計画がこうなる。転送を有効にしなければ、経路は解決してもパケットは破棄される。

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

フィルタリングと変換を分けて考える

ルーティングとポリシーは別の制御であり、多くのルーティング設計が実際に失敗するのは後者のほうだ。パケットが実際に越える入口境界で、具体的な送信元・宛先・サービスを許可する。WANのようなインターフェース名は名前であって、信頼についての宣言ではない。プライベート通信を運ぶ通過ポートでも、プライベートアドレスのブロックが既定で有効なことがある。

そのうえで、NATが起きていないと結論づける前に外向きの変換を見る。自動の外向きルールは、変換するつもりのなかった通信まで書き換えることがあり、相手側が自らのポリシーとログに必要とする送信元アドレスを壊してしまう。選択したフローが元のアドレスを保っていることを確認し、まだ必要とする通信のためにインターネット向けの変換ルールはそのまま残す。

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

NATが正直な答えになるとき

変換が正当化されるのは、アドレス範囲が本当に重複していて再採番ができない場合、あるいはポリシー上、片側がサブネットではなく単一アドレスを見る必要がある場合だ。そうした場合の意図的な一対一やポート限定のマッピングは、結果が分かったうえでの設計判断であり、場当たり的な回避策ではない。

声に出して言うべき結果は、相手側が個々の送信元を見ることも絞ることもできなくなることだ。ログは変換後のアドレスに潰れ、ホスト単位のポリシーは機能しなくなり、トラブルシュートはその瞬間にどの内部ホストがフローを持っていたかを追う作業になる。対象の通信でそれが問題にならないなら、NATで構わない。

通過網そのものが誤った前提であるとき

共有セグメントがプロバイダ、共有スイッチファブリック、あるいは第三者が通信を読める経路をまたぐなら、ルーティングだけでは完全な答えにならない。二台のファイアウォール間のトンネルは機密性と相手認証を与え、その内側の経路表は通過網に書いたはずの同じ表である。

これは第一節の信頼の問いから決めるべきで、VPNのほうが安全という習慣から決めてはいけない。すでにプライベートなセグメントの上にトンネルを張ると、得るものなしに運用コストと障害モードが一つ増える。信頼できないセグメントの上でルーティングすると、機密性を、払えない簡潔さと引き換えにすることになる。三つの条件のどれが選択を決めたのかを書き残せば、次のエンジニアが蒸し返さずに済む。