NAT は VPN サーバー側かルーター側か？どちらでも機能する

ラップトップで接続をデフォルトルートとして設定するのは誰もが覚えている手順であり、まさにゲートウェイでは何も変えない手順です。クライアントは今、インターネット要求をトンネルへ送りますが、それが建物の外へ出るかどうかは、転送、変換ポイント、そしてクライアントのプライベートアドレスに届く戻り経路にかかっています。二つの構成はその三つをすべて供給できますが、仕事を置く場所が異なり、誰も応答方向を担当しないときには両方とも同じ静かな仕方で失敗します。どちらを選ぶかは、クライアントプールを誰が見るべきかという問いです。

神話：クライアントのルートが出口を作る

強制トンネリングはクライアント側のポリシーであり、トラフィックが物理アダプターではなく VPN アダプターへ向かうことを決めます。Microsoft の VPN ルーティングのドキュメントはその分割と強制の挙動を説明しており、それはクライアントのルートテーブルについての記述であって、サーバーの転送規則についてのものではありません。クライアントから見ればトンネルはインターネットが住む場所であり、ゲートウェイから見ればパケットは上流の誰も聞いたことのないアドレスから届いたのです。どちらの側も単独では誤設定ではないため、ラップトップの前の人には障害が壊れたサーバーのように見えます。

その不一致こそが、この記事の残りが解く問題の全体です。何かがクライアントのプライベートアドレスを戻せるようにしなければならず、選択はどこで行うかです。

まず戻り経路を描く

設定に触れる前に実在のアドレスで経路を書き出し、候補となる二つの変換ポイントに印を付けます。このラボでは 10.70.0.0/24 の VPN プールを使い、クライアントが 10.70.0.37 に、サーバーの LAN アドレスが 172.16.40.10 に、ルーターが 172.16.40.1 に、公開出口が 203.0.113.40 にあります。

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

すでにインターネットを閲覧しているサーバーは、自分自身の経路を証明するだけです。クライアントの代わりに転送されるパケットは別の判断であり、同じマシン上の転送ポリシーが下すもので、ふつう欠けているのはこちらです。図の上で三つの判断点を印付ければ、会話は一度にそのうちの一つに集中します。

オプション A：VPN サーバーで変換する

ここではサーバーがパケットをルーターへ渡す前にクライアントの送信元を自分の LAN アドレスへ変換し、ルーターは出ていく経路で通常の変換を適用します。応答では、ルーターのマッピングがサーバーのアドレスを戻し、サーバーのマッピングがクライアントのアドレスを戻します。直列のステートフル変換が二つあっても正常で実行可能であり、両方が記録されている限り問題はなく、ルーターがプールへのルートを必要とすることは決してなく、それがこの構成の魅力です。

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT があると決めつけるのではなく、サーバーがすでに何を持っているかを見るためにこれらの読み取りを使ってください。ブログからコピーした Linux の masquerade ルールは Windows の構成ではなく、VPN リスナーに対するホストファイアウォールの許可は、クライアントの要求を先へ転送する許可と同じポリシーではありません。配備の異なる部分が両者を有効にすることが多いため、サーバーの転送の役割はその管理画面から確認し、そのうえで変換は別に見てください。

オプション B：プールをルーターへ運ぶ

第二の構成では、サーバーがクライアントの本当の送信元アドレスを転送し、ルーターがそれを変換します。これによりクライアントプールは境界で見えたままになり、トラフィックポリシーやログ、検査がルーターにある場合に役立ちます。また、ルーターには 10.70.0.0/24 に対する 172.16.40.10 を指す戻りルートと、そのプレフィックスを実際に含むインターネットポリシーが必要で、LAN サブネット向けに書かれた規則が黙ってプールまで広がることはありません。

境界の機器が意図されたポリシーの所有者であり、ルーティングと変換のテーブルに別のプレフィックスを受け入れられる場合にこれを選びます。プールを上流に対して見えなくしておきたい場合や、ルーターを同じチームが管理していない場合はサーバー側の変換を選びます。どちらの選択肢もクライアントのチェックボックスから導かれるものではなく、一般にどちらかがより安全ということもなく、両者は可視性と保守を異なる場所に置くのです。

DNS、IPv6、受け入れを明示する

アドレス変換は名前解決を直しません。クライアントは VPN プロファイルとともに配布されたリゾルバー、特定の名前空間のためのプライベートなリゾルバー、または承認された公開リゾルバーを使えますが、そのポリシー下で到達できないリゾルバーはルーティングが機能した後も失敗し続けます。名前とアドレスを別々にテストし、二つの失敗が一つの報告に混ざらないようにしてください。

IPv6 は設計の中で独自の段落を必要とします。動く IPv4 変換は、IPv6 のクライアントにルート、有効な公開送信元、トンネルが落ちたときにそれらを遮断するポリシーがあるかどうかについては何も語りません。それを述べないままにすると、半分のクライアントは静かにゲートウェイを迂回し、残りの半分は機能するという状態になります。

受け入れにあたっては、許可されたクライアント要求とその応答を二つの境界にわたって追跡し、その時点で各境界が見るべきアドレスを書き留めます。その記録があるからこそ、次のプール変更は、失われた戻りルートを誰が持つかという議論ではなく、五分の編集になります。次の技術者が最初に見つけるのはプロファイルなので、記録はチケットではなくクライアントプロファイルと一緒に保管してください。