GCE の VPN 変更前にシリアルリカバリ経路を用意する

Compute Engine VM の VPN ルートを変更すると、締め出される可能性があります。ルートに触れる前に、クラウド権限、シリアル出力、ゲストログインを証明してください。

同じインターフェース上の二つ目の SSH ウィンドウはリカバリ経路ではありません。これから変更するルート、ファイアウォールルール、デーモンを共有するため、必要なまさにその瞬間に失敗します。Compute Engine VM の VPN ルートを編集する前に、シリアルコンソールを使えること、その出力を読めること、ゲストが実際にログインを提供することの三つを証明してください。以下の確認はその順序で、最も安価なものから実行するので、欠けた権限は重要になる前に見つかります。

ステップ 1: クラウド側の権限を確認する

正確な VM、プロジェクト、ゾーンを特定し、組織が承認したシリアルアクセスポリシーを確認します。管理者には該当する権限が必要で、有効なプロジェクトと組織の管理下で、そのインスタンスの対話型シリアルアクセスを有効にする必要があります。

一台のマシンを準備するために組織ポリシーを弱めたり、プロジェクト全体でコンソールアクセスを有効にしたりしないでください。実験の前に、停止中ではなく、所有者に許可された仕組みを整えてもらいましょう。

ステップ 2: 出力を読めることを証明する

シリアル出力の読み取りは最も安価な確認であり、ゲストのログインに触れずにトランスポートを試します:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

識別子を置き換え、許可されたポートを使用します。起動メッセージとコンソールのやり取りから、チャネルが機能していることが分かります。しかしシェルを取得できることは証明しません。だからこのステップは次のステップと分けられています。

ステップ 3: 対話型ログインを取得できることを証明する

接続コマンドはプレビューではなく、実際のセッションを開きます:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

ライブコンソールとして扱い、認証情報を入力する前にエンドポイントを確認してください。すべてのキー入力がインスタンスに届くからです。

ここで、完全に見えた計画が崩れます。クラウド権限は一つの境界であり、Linux のログインプロンプトはもう一つの境界で、前者を通過しても後者については何も分かりません。

ステップ 4: ゲストが受け入れる認証情報を用意する

Google が提供する Linux イメージは、既定ではローカルのパスワードベースのログインを有効にしません。そのためシリアルセッションはログインプロンプトに到達してもそこで止まり、誰も設定していない認証情報を待つことがあります。

承認されたリカバリアカウント、または展開で使用している文書化されたゲストログイン方式が存在し、テストされている必要があります。ネットワーク経由で機能する SSH キーは、コンソールのパスワードプロンプトを自動的に満たすわけではないので、このケースをカバーしていると仮定せず、実際の OS Login とキーの配置を確認してください。

リカバリ認証情報は非公開に保ってください。公開の startup-script の例に貼り付けられた root パスワードは、起こるのを待っている二つ目のインシデントです。

ステップ 5: 所有者とロールバックを記録する

何かを変更する前に、動作しているネットワーク構成を保存し、誰が管理しているか、どの VPN サービスが関係しているか、ロールバックをどう実行するかを書き留めます。動作中のセッションから、現在のルート、ルール、サービスの状態を取得してください。

この記録が、コンソールはプロンプトを与えるだけだからこそ、リカバリ経路を修理に変えます。変更の前に書き、後から記憶で書かないでください。wiki からコピーしたロールバックはロールバックではありません。バージョン番号付きの推測です。

ステップ 6: 変更後に検証する

既存の SSH セッションは、新しい接続をブロックするポリシーを生き延びることがあるため、新しい通常の管理セッションでテストしてください。次に、変更した VPN の動作を別途テストします。

両方の確認が通るまでリカバリ経路を開いたままにし、その後はアクセスポリシーに従って閉じてください。SSH がすでに失われ、コンソールログインも準備していない場合は、シリアルアクセスを安全網とみなすのをやめ、承認されたアカウントリカバリまたはインスタンス修復のワークフローを開始してください。別の VM をジャンプホストとして立てても、ゲストの経路も欠けた認証情報も直りません。

関連記事