マスカレードかポリシールーティングか：VPNゲートウェイ経由のLANトラフィック

LAN全体をVPNトンネルの内側に置くのは簡単な部分だ。遠端がそのクライアントをどう見るかを決めるのは簡単ではない。マスカレードは各LAN送信元をゲートウェイのトンネルアドレスに書き換えるので、遠端は一つのピアに応答する。ポリシールーティングは元のアドレスを保ち、遠端がそこへの到達方法を知っていることを求める。どちらも既定ではない。どちらを選ぶかは、遠端を誰が持つか、端末ごとの識別が重要かで決まる。

二つの設計は異なるものを約束する

マスカレードはLANを一つの見えるホスト、つまりゲートウェイに縮約する。遠隔ネットワークはその一つのアドレスに応答し、ゲートウェイは応答をフローを開始したクライアントへ翻訳して戻す。遠端にはプライベートプレフィックスへの経路が要らない。だからこそこの設計は、それらを運ぶことを拒むプロバイダーでも成り立つ。ゲートウェイはすべての接続の送信元にもなるので、遠端は二つのクライアントを区別できない。

ポリシールーティングは各クライアントのアドレスをそのまま保つ。遠隔ネットワークは実際の送信元を見て、記録し、ホストごとの規則を適用し、応答をそのアドレスへ直接返せる。この可視性こそが要点であり、義務を伴う。遠端にはLANプレフィックスの経路が要り、それはトンネルを通って戻る。規則を有効にする前にその経路を計画すること。トンネルはどちらにせよ上がり、欠けるのは応答だけになる。

失敗の仕方は約束と同じくらい異なる。マスカレードの規則が欠けると、プライベートな送信元のまま出て二度と戻らないパケットになる。戻り経路が欠けるとポリシールーティングでも同じ症状になるが、直すべき場所はゲートウェイではなく遠隔ルーターだ。

マスカレード：遠端に一つのピア

マスカレードの道筋には重要な順序がある。 どのNAT規則も役に立つ前に転送を有効にする必要がある、フィルターテーブルが両方向の通過を許し、そのうえで初めてトンネルインターフェースで変換が適用される。

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

クライアントには依然としてゲートウェイへの経路が要る。ゲートウェイが既定ルーターであるか、遠隔プレフィックスへの専用経路を持っているかのどちらかであり、別のルーターが既定のままならそのルーターにトンネル宛先への静的経路が要る。さもないとゲートウェイが見る前にパケットは誤ったホップへ行く。

DNSは別の判断だ。遠端のリゾルバーは、その応答がクライアントへ戻れる場合にだけ答える。マスカレードでは問い合わせがゲートウェイから来たように見えるので、リゾルバーの戻り経路はすでに満たされている。ポリシールーティングでは、リゾルバーに他の遠隔サービスと同じ戻り経路が要る。

ポリシールーティング：送信元を保ち、戻り経路を加える

ポリシールーティングはテーブルとそれを選ぶ規則から始まる。LANインターフェースから入るトラフィックは専用テーブルへ送られ、そのテーブルがトンネル経由の既定経路を持つ。メインテーブルはそのままなので、ゲートウェイ自身が起こすトラフィックは別の道をたどれる。

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

次に遠端がLANプレフィックスをトンネル経由で戻すようルーティングする必要がある。これはこのゲートウェイではなく遠隔ルーターの設定だ。ゲートウェイは、メインテーブルが予想するのと別のインターフェースに届く応答も受け入れる必要がある。厳格モードがそれらのパケットを落とす場合、緩い逆経路フィルタリング（rp_filterを2に設定）が通常の調整だ。

二つのトンネルが有効なときは、入る各フローにタグを付け、タグにテーブルを選ばせる。入力インターフェースだけを見る規則は両方のトンネルのトラフィックを同じテーブルへ送るので、二番目のトンネルが一番目のフローを奪う。そのタグは再接続をまたいで生き残る接続で試すこと。混在したポリシーはそこで現れる。

所有権と、遠端が何を記録するかで決める

トンネルがプロバイダーで終わるならマスカレードを使う。その事業者はあなたのプライベートLAN範囲をルーティングせず、ゲートウェイの背後の個々のクライアントを区別する理由もない。見えるピアが一つというのがそのポリシーが支える唯一のモデルなので、それを与え、変換は自分の端に置く。プロバイダーは一つのピアを見る。それはまさにそのポリシーが期待するものであり、あなたのクライアントはその単一の識別を引き継ぐ。

両端があなたのもので、遠隔サービスが送信元アドレスで動作するなら、ポリシールーティングは追加の経路に値する。ファイアウォール規則、ユーザーごとのアクセス、監査ログがクライアントを区別できる。遠端に到達性だけが必要なら、マスカレードのほうが単純で、戻り経路の誤りの一群をなくせる。

ハイブリッドな設計は普通だ。自分のネットワーク内はポリシールーティング、プロバイダーの端はマスカレードであり、大事なのはどのホップが変換し、どのホップがルーティングするかを書き留めることだ。一人のクライアントのために誤って加えたNAT規則は、同じ連鎖の全クライアントの送信元を隠す。

一つのクライアントから確認し、次に二つ目のクライアントから確認する

テストはトラフィックが始まる場所で実行する。ホストが使う経路を確認し、パケットがトンネルインターフェースに現れるのを見て、変換のためにconntrackを調べる。この順序が、パケットが意図した道を通ったことを証明する。単にどこかに着いたのではない。

再接続のあとにテストを繰り返す。インターフェースを名指すマスカレード規則は新しいトンネルアドレスでも生き残るが、古いアドレスを名指す規則は生き残らない。次に二台目のLANホストを試すこと。一台で動く設計は、ゲートウェイのポリシーではなくそのマシン自身の経路に依存することが多い。

選んだモデル、変換したか保持した送信元、戻り経路の持ち主をゲートウェイのメモに書く。そうしなければ、次にクライアントやトンネルを足す人が推測する。推測こそが、動いていたLANからVPNへの構成を部分的にする道だ。