ある Azure VM にトンネルが必要なとき：ゲストクライアントか VPN ゲートウェイか

ある Azure VM 上のひとつのワークロードが、トンネル経由でプライベートネットワークに到達する必要があるとします。設計を決める問いは、どの VPN 製品が優れているかではなく、その経路を他のマシンが将来必要とするかどうかです。まずこれに答えると、残りのアーキテクチャはおおむね自然に決まります。ここを誤ると、誰も文書化していないルーターに静かになってしまった VM を引き継ぐことになります。

似て見える二つの役割

VM はエンドポイントにも中継点にもなれます。違いはインストールするソフトウェアではなく、トンネルを誰が使うかです。エンドポイントとしてなら、ゲストは自分のプロセス用にクライアントを動かします。中継点としてなら、他のワークロードのパケットを転送するため、VM はネットワークトポロジの一部になります。

単一 VM の要望の多くは、二つ目の役割の言葉をまとった一つ目の役割です。「この VM がうちの VPN だ」と言うとき、実際にはその上のアプリケーションが向こう側のデータベースに届く必要がある、という意味だったりします。

条件その一：他の何かが向こう側を必要とするか

答えが「いいえ」なら、ゲストにクライアントを入れて設計をやめてください。その選択に管理ゲートウェイは不要で、VM が隣接マシンのゲートウェイになるわけでもありません。ひとつのオペレーティングシステムの中にルートを足すだけです。

答えが「はい」、あるいは一年以内にほぼ「はい」なら、いまネットワーク設計として扱ってください。他の VM が中継 VM に届くのは、サブネットのルートテーブルがそこへ送り、NIC が転送トラフィックを受け入れる場合だけです。したがって作業は ルートテーブルと転送の許可 であり、クライアントの追加インストールではありません。

条件その二：管理経路を保てるか

広いルートを入れる VPN クライアントは、VM の管理に使う経路を奪うことがあります。トンネルの宛先リストが管理ネットワークと重なると、クライアントが接続した瞬間に SSH や RDP のセッションが切れ、修復はシリアルコンソールか再構築でしか行えません。

前と後で確認してください。Linux では ip route get <management-ip> が、カーネルが今どのインターフェースと送信元を使うかを示します。トンネルを張った状態の答えと比べてください。宛先を明示した分割トンネルのほうがデフォルトルートより説明しやすく、たいていはワークロードが本当に必要としているものです。

条件その三：真夜中に誰がパッチを当てるか

ゲストクライアントは、あなたのオペレーティングシステム、クライアントのバージョン、証明書です。VM とそのパッチサイクルをすでに運用しているなら問題ありません。VM がトンネルを保持するためだけに存在するなら、割の悪い取引です。ゲストクライアントのほうが安いと言う前に、パッチの工数を数えてください。再起動が要るクライアント更新は、トンネルを保つためだけに存在するマシンに対して自分で予定した停止です。

管理ゲートウェイはその保守をプラットフォーム側へ移します。ID、認可、背後のネットワーク経路は引き続きあなたの担当ですが、クライアント更新のためにマシンを再起動することはありません。

管理ゲートウェイがやらないこと

Azure VPN Gateway は VNet の接続サービスであり、独自のサイト間接続とポイント対サイト接続を持ちます。ゲストの VPN ソフトウェアを禁じる規則ではなく、ひとつのアプリケーションが必要とするクライアントの代替品でもありません。

与えるのはネットワーク層の接続で、多くのワークロードがルーティング経由で到達できます。与えないのは、ある VM 上のひとつのプロセスだけが使い、そのプロセスの ID に限定されたトンネルです。この限定は陳謝すべき欠点ではなく、ゲストクライアント設計の要点そのものです。ひとつのアプリケーション、ひとつのルート、ひとつの資格情報、サブネットの他の VM への影響はありません。

つまり比較は管理対ソフトウェアではありません。ネットワーク範囲の接続対プロセス範囲の接続であり、後者はひとつのプロセスだけが必要とするなら正当です。

必要になる前に成長の道筋を描く

要件が VM ひとつからサブネットへ広がるなら、クライアントの許可プレフィックスを広げるのではなく設計を作り直してください。都合のよいセッションを文書化されていないルーターとして使い回すと、すべての利用者がその VM の寿命、資格情報、パッチ時間帯に縛られます。

接続がワークロード範囲ではなくネットワーク範囲になった時点で、正しい出発点は Azure VPN Gateway の概要 です。

選ぶ前に三行書いてください。向こう側を必要とするのは何か、VM を管理するのは誰か、トンネルにパッチを当てるのは誰か。三つすべてがひとつのワークロードを指すなら、ゲストクライアントが正直な設計です。どれかひとつでもサブネットを指すなら、いまネットワーク層を設計してください。