リモートアクセスクライアントが支店ゲートウェイを担う必要があるとき

VPN に接続したノート PC は本社に到達できます。同じ机のプリンターとファイルサーバーは、それらのパケットをそのトンネルへ転送するものも応答を戻すものもないため、到達できません。クライアントを支店ゲートウェイに変えることは、設定の判断である前にルーティングと責任の判断です。箱に書かれたプロトコル名は、その役割が支えられているかどうかには答えません。

プロトコルのラベルが教えないこと

OpenVPN は、コネクターがサブネット全体を転送する拠点間設計を記述しており、Access Server はゲートウェイの役割と明示的なルーティングでそれを実装します。SSL VPN として売られる別の製品は、リモートユーザー向けの機能だけを提供し、クライアントの背後にあるネットワークを知らせる正規の方法を持たないかもしれません。バージョンも重要で、あるリリースの機能は別のリリースへの約束ではありません。実際に動かしている実装を読み、別製品向けに書かれたレシピは設計ではなく手がかりとして扱ってください。

最初に決めるべき問いは、VPN の所有者が転送の役割をそもそも支えているかどうかです。支えていなければ、クライアント側のルーティングをいくら足しても支えられることにはなりません。

契約の二つの側面: 支店と本社

支店側では、転送、フィルタリング、復旧を一つのホストが担います。支店の各デバイスからの意図的な経路が必要で、トンネルが落ちている間も外部の VPN 接続は下位ネットワーク経由で到達可能でなければなりません。本社側では、誰かが支店サブネットを定義し、ゲートウェイの身元を受け入れ、特定のリソースを許可する必要があります。どちらの半分も単独では機能しません。

戻り経路こそが見落とされる部分です。クライアントのトンネルアドレスは背後のサブネットを知らせないため、本社のルーターにはそのプレフィックスについて VPN ゲートウェイを指す経路が必要です。

ルーティング設計では、集約装置が支店プレフィックスのパケットを転送し、上位 LAN のルーティングが応答の戻し方を知っています。変換設計では、本社が見る送信元が書き換えられ、戻り経路を一つ省ける一方で、どの支店マシンが通信を送ったかが隠れます。そのトレードオフは、変換が入るとアプリケーションログとアクセス規則がデバイスごとの身元を失うため、設計文書に属します。

ルーティングか変換か: 戻り経路を意図的に選ぶ

デバイスごとの身元とホストごとのポリシーが重要で、関係するすべてのルーターで戻り経路を維持できるなら、ルーティングを選びます。

経路を追加できないが、本社が一つの送信元アドレスを見ることを受け入れられるなら、変換を選びます。混在した設計は存在し、考えるのが難しくなるので、どのプレフィックスがルーティングでどれが変換かを書き留めます。そのうえでトンネルの状態を信じるのではなく、両端のキャプチャで選択を検証します。

有用な確認は非対称で、支店デバイスからリソースを要求し、その応答が本社から支店プレフィックスへ向かうことを確かめます。 traceroute -n 10.60.4.20 本社のホストから、その経路が VPN ゲートウェイを通るかどうかを示します。

ログインではなく、インフラとして運用する

誰もログインしていない状態で、ゲートウェイがどう起動し、認証し、更新し、復旧するかを決めます。資格情報の更新、多要素の問い合わせ、スリープの挙動、支店がアクセスを失ったときに誰が応答するかは、すべて運用上の問いになります。一つのネットワーク経路を共有する複数の人が、ゲートウェイ利用者の個人特権を継承してはならないので、リソースの認可、ログの範囲、障害時の方針には名前のある担当者が必要です。各デバイスの登録を避けるためにアカウントを共有するのは設計ではありません。

この構成を、サポートされた拠点ゲートウェイ と同じ要件の下で比較してから決めてください。古いデスクトップの再利用は保守や復旧の作業を消しませんし、中古価格は運用コストを表しません。

承認された計画の下で、対象の支店アプリケーション、その戻り通信、拒否される一つの宛先を検証します。成功とは、名前のある支店の身元と明示的なポリシーを持つ自前のネットワークサービスであり、接続済みと表示するクライアントウィンドウではありません。