VPNクライアントのアドレスプールを適合するように計画する方法

VPNサーバーのプール欄から始め、表計算ソフトからは始めません。そこに入力した内容が、その後接続するすべてのクライアントの内部アドレス空間になり、それらのクライアントが到達するLAN、その背後のルーティング済みサイト、クライアントが自宅ですでに持っているアドレスと共存する必要があります。プールを保存したらすぐに一台のクライアントを接続し、その最初の接続で値が実際に機能するかどうかを確かめてください。そこから手順は外へ広がり、クライアントが受け取ったアドレス、応答がたどる経路、そして残す記録へと進みます。

どのクライアントも接続する前に、プール欄から始めます

製品ごとに見せ方が違うので、実際にアドレスを割り当てるオブジェクトを見つけます。OpenVPNには次の空きアドレスを配るサーバー側のプール指令があり、IKEv2ゲートウェイにはピア設定に紐づくプール節があり、WireGuardにはどちらもありません（各ピアが自分の設定ファイルに自分のアドレスを持つためです）。プール指令とピアごとのアドレスは交換できず、間違った方を編集すると残りの手順が無駄になります。

欄を特定したら、オフィスのLAN、ルーティング済みの各サイト、クラウドVPC、そして現役の他のプールという、すでに存在する範囲を列挙します。重複はプレフィックスの計算で決まり、ホスト番号が見慣れているかどうかでは決まらないので、集約をそれぞれの範囲と比較します。どちらも10.xに見える二つの範囲は、集約が交差しなければ無害で、交差すればサポート案件になります。

次に、アドレスが誰が接続するかの関数なのか、いつ接続するかの関数なのかを決めます。動的割り当ては空いているものを配り、識別子ごとの割り当ては固定アドレスを資格情報に結びつけます。後で再接続がどうあるべきかを変えるので、選択は書き留めてください。

クライアントが実際に受け取ったアドレスを読みます

一台のクライアントを接続し、プールが約束したことではなく、トンネルが報告することを読みます。クライアントは接続状態に内部アドレスを表示し、Linuxではインターフェースがそれを直接持っています。

そのアドレスを保存した範囲と比較します。範囲の外なら、編集したのとは別の割り当て経路を見ています。プレフィックス長も確認してください（/32を持つクライアントにはオリンクのピアがなく、すべての宛先を既定ルート経由で送ります）。

ip -4 addr show tun0
ip route get 192.168.50.20

同じ範囲を使う家庭用ルーターから接続したクライアントは接続できても、ほとんど何にも届きません。クライアントはそのプレフィックスのローカルルートを保持するため、トンネルのアドレスが背後のネットワークと衝突し、トラフィックが誤ったインターフェースから出ます。このケースはサーバー側では修復できず、文書化された対処は家庭内ネットワークの再採番か、衝突がまれに留まるほど遠いプール範囲の選択です。障害と対処の両方を記録してください（ヘルプデスクが再び遭遇します）。

同じクライアントを再接続してアドレスを観察します。動的プールは同じ値を返すことも別の値を返すこともあり、どちらも正しい一方、アドレスを変える識別子ごとのプールは結びつきを守っていません。この確認は数秒で済み、最初の節で記録したモードが現行のモードかどうかを決めます。

サービスからの応答を戻る経路でたどります

プールは、応答がそこへ戻れるときだけ機能します。LAN上のサービスは内部アドレスに応答するので、そのゲートウェイにはプールへのルートか、サービス手前の変換が必要です。要求がトンネルを通って届き、応答が別の経路で出ていくとき、ステートフルファイアウォールや逆経路チェックがそれを落とし、クライアントには接続したまま固まるサービスが見えます。ホストごとのルートを足すのではなく、プールを集約可能な一つのブロックとしてルーティング設計に置いてください。

変換はシステムの残りが見るものを変えます。送信元が書き換えられると、ホストのファイアウォールとアプリケーションログのアドレスは変換後のものになるので、プールのアドレスに対して書かれた規則は何にも一致せず、ログの行をクライアントまでたどれません。strongSwanの転送に関する文書は、IKEv2ゲートウェイについてその経路のサーバー側半分を扱っています。DNSも同じ制約を負い、クライアントが到達できないアドレスに解決する名前は、後で別の場所で失敗します。

二台のクライアント、そして一件の失効

同時に二台のクライアントを接続し、両方のアドレスを読みます。それらは別個で使用可能でプール内になければならず、それぞれが想定されたサービスに届く必要があります。重複アドレスを配るプールは、最初の一台のテストではなく、たいていここで現れます。

もう一方のクライアントを接続したまま片方の資格情報を失効させ、残ったクライアントからサービスを試します。もう一方のセッションを乱す失効は共有状態を示し、多くの場合、資格情報やアドレスが機器間で使い回されています。失効したクライアントを再接続し、解放されたアドレスが渡されるのではなく拒否されることを確認します。

拒否されるべき宛先で終えます。すべてに届くクライアントは接続されただけで、試験されていません。

四つの値を、次の変更が見つけられる場所に書きます

記録は短く、プールの範囲とプレフィックス、割り当てモード、使用中の戻り経路または変換、そしてそれらの宛先に応答するDNSスコープです。チケットではなくサーバー設定の隣に置き、日付を付けます。後で四つのうち一つを変える人は残り三つを目の前に必要とします（プールのサイズ変更はルートを壊し、ルートの変更はDNSの応答を壊すためです）。

所有権の注記も一緒に置き、トンネルの範囲はVPNサーバーに属すこと、LANのDHCPスコープで作った予約はトンネル内のクライアントのために何も予約しないことを示します。この一行が、誰かが予約を追加してトンネルのアドレスがそれに従うと期待する、最も多い手戻りを防ぎます。