既存の GCE VPN ゲートウェイで IP 転送を有効にする

この VM は IP 転送を有効にせずに作成され、すでに VPN ソフトウェアを実行しています。そこで、フラグを立てたテンプレートから作り直そうと考えるのは自然ですが、その作り直しは不要です。Compute Engine は canIpForward を更新可能なプロパティとして公開しており、文書化された更新手順では再起動ではなく refresh で適用します。フラグが実際に制御する範囲は狭く、これがないと、プラットフォームはインスタンスに到着してもインスタンス自身のアドレス宛てではないパケットを破棄します。他のマシンの通信を転送するゲートウェイはまさにそれを行うため、フラグは有効でなければなりません。それ以降はすべてゲストの設定とルーティングであり、フラグはそこに関与しません。

フラグが許可すること、許可しないこと

転送が無効な場合、プラットフォームはインスタンスを端点として扱います。宛先がインスタンス自身のアドレスであるパケットは配信され、インスタンスが他者のために中継すべきパケットは配信されません。

転送が有効な場合、インスタンスは VPC ルートのネクストホップとして機能できます。これは VPN アプライアンスに必要な役割です。フラグはファイアウォール、ゲストのルーティング、トンネル設定、戻り経路については何も示しません。そして、壊れたゲートウェイにおける true という値は、依然として壊れたゲートウェイです。

現在のプロパティを読み取る

何かを変更する前に、対象のインスタンス、プロジェクト、ゾーンに対して読み取り専用の describe を使い、設定を確認します。

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

false という値が問題になるのは、この VM をネクストホップにする場合だけです。その場合でも、経路の残りの部分は別途確認する必要があります。このプロパティはより長い連鎖の中の一行にすぎないからです。

既存のインスタンスを更新する

Google のインスタンス プロパティの更新手順は、現在のリソースをエクスポートし、プロパティを変更して結果を送信します。これは作成時の --can-ip-forward フラグとは異なるワークフローであり、稼働中の VM で機能するのはこちらです。

まず定義をローカルファイルにエクスポートし、比較用に未変更のコピーを残します。

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

そのエクスポートしたファイルで、プロパティだけを設定し、それ以外は何も変更しません。

canIpForward: true

リソース全体を、フィンガープリントも含めて保持します。ファイルを一行の YAML ドキュメントに置き換えたり、無関係なマシンタイプ、ディスク、インターフェースの編集を同じ送信にまとめたりすると、プロパティの変更が障害になります。

実際の変更が許可される前に、更新の仕組みに対してファイルを検証させ、何が必要になるかを報告させます。

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

この検証実行では転送は有効になりません。無効なプロパティと、必要とされるアクションについて応答を読みます。この独立した変更では、文書化されたアクションは REFRESH です。結果が再起動を求める場合、ファイルには変更しようとしたプロパティ以上の内容が含まれているため、再起動を許可するのではなくファイルを調べます。

レビュー済みのファイルを refresh の制限付きで適用します。

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

操作が完了したことを確認し、describe コマンドを再度実行します。フィンガープリントが一致しなくなっていれば、編集中に他の誰かがインスタンスを変更しています。その場合は、古いファイルを押し通すのではなく、新しいコピーをエクスポートして変更を再確認します。

ゲストは依然としてパケットをルーティングする必要がある

クラウドの権限はアプライアンスをルーターにはしません。VPC ルートが宛先プレフィックスのネクストホップとしてこの VM を選択していること、そしてゲストが自身の転送ポリシーを有効にしてトンネルと正しいインターフェースの間をルーティングしていることを確認します。

ファイアウォール ポリシーは、外側のリスナーだけでなく内側のフローも許可する必要があります。VPN ポートだけを開けても、暗号化されたトランスポートを記述するだけで、その内側のアプリケーション交換については何も示しません。

最後に、宛先にはクライアント プールへの戻り経路が必要です。そうでなければ、設計として送信元を意図的に変換する必要があります。宛先が変換された通信を見る場合は、変換された送信元を確認します。設計がプールを保持する場合は、戻り経路とアクセス ルールでそのプールを確認します。どの設計にするかを決める前に NAT を追加すると、欠けている経路が隠れ、宛先が見るポリシーが変わります。

Linux ゲートウェイでは、カーネルの転送はゲスト設定の一部です。pfSense アプライアンスには独自の同等機能があり、Linux の sysctl コマンドをそこにコピーしても対応する手順にはなりません。

アクセスを必要とするクライアントから検証する

ゲートウェイ自身からではなく、VPN クライアントから一つの対象サービスへテストします。ゲートウェイ上で開始された接続は別の送信元を使い、有効にしたばかりの転送ルールを一度も通しません。

プロパティは、アプライアンスを管理しているあらゆる場所に記録します。手作業で修正した VM は、次に置き換えられたときに元の設定が静かに戻るまで機能し、その失敗は VPN ソフトウェアの回帰のように見えます。

作業の順序は、プロパティを読み、エクスポートして一行を編集し、NO_EFFECT で検証し、REFRESH で適用し、ゲストが転送していることを確認してから、クライアントからテストします。