GCP VPN のルートが一つのリージョンでしか通らない: 動的ルーティングを確認する
グローバル VPC でも、BGP で学習したルートがグローバルになるわけではない。ルーティング モードを確認し、一度だけ変更して、遠端が何を広告するかを検証する。
米国のワークロードは HA VPN 経由でオフィスのプレフィックスに問題なく到達する一方、同じ VPC 内の欧州のワークロードには何も届かない。そのルート テーブルにはこのプレフィックスのエントリがない、トンネルはどれもダウンしておらず、ファイアウォール ルールも変わっていない。トンネルと BGP セッションは双方向で正常だ。VPC が複数リージョンにまたがることは、学習したルートが複数リージョンにまたがることと同じではなく、この差が症状のすべてを説明する。
ここでは二つの性質が混同されている: サブネットがどこにあるか、そして学習したネクスト ホップをどこで使えるか、である。
リージョン スコープの由来
Cloud Router は学習したルートを、VPC の動的ルーティング モードに従うスコープで登録する。リージョン モードでは、あるリージョンで学習したルートを使えるのはそのリージョンのリソースだけであり、欧州のテーブルが壊れたネクスト ホップではなく空になるのはそのためだ。グローバル モードでは、条件を満たす学習ルートが VPC のすべてのリージョンのリソースから利用できるようになる。何かを変える前に現在の値を読むこと、既定はリージョン モードだからである。設定はネットワークにあり、トンネルにもルーターにもない。
インベントリ コマンドは読み取り専用で、これを一行で答える。
gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'
VPC を共有している場合はホスト プロジェクトで実行する。ネットワークはそのプロジェクトに属し、ワークロード プロジェクトの閲覧者ロールではルーティング構成が表示されないことさえある。間違ったプロジェクトからの素早い回答は、回答がないより悪い。
変更は一つのコマンドと一つの方向だけ
切り替えは VPC 全体のコントロール プレーンの編集であり、VM ごとの回避策ではない: gcloud compute networks update VPC_NAME --routing-mode=GLOBAL。これは一方通行でもあり、グローバルに設定したネットワークはリージョンに戻せない。コマンドは確認を求めないので、実行前にもう一度プロジェクト名とネットワーク名を確認すること。この変更には保守記録とネットワーク所有者の承認が必要であり、共有 VPC での軽い試し撃ちではない。
そのネットワーク内のすべての Cloud Router、VPN、Interconnect 接続は新しいスコープを一斉に引き継ぐ。変更依頼で誰も触れなかった接続も含まれる。これまでルートがなかったリージョンも変更が反映された瞬間から受け取り始めるため、この切り替えに段階的な展開はない。
グローバルはスコープであり、保証ではない
適格性と優先度はスコープとは別である。より具体的なプレフィックスと競合するルート、最良パスの選択に敗れるルート、ポリシーで除外されるルートは、以前とまったく同じように振る舞う。グローバル モードはルートを使える場所を広げるが、どのルートが勝つかは決めない。学習したルートはスコープ内にあっても、同じ VPC の静的ルートやより具体的なパスに負けることがある。
この区別が重要になるのは、後からモード変更のせいにしやすいからだ。切り替え後も欧州のサブネットにルートがないなら、問うべきはルートが存在し適格かどうかであり、スコープが効いたかどうかではない。プレフィックスの競合とネクスト ホップの健全性が、次に読むべき二つである。
遠端の広告も変わる
広告の動作も同じ設定に従う。既定の動作では、リージョン モードのルーターは自分のリージョンのサブネットを広告し、グローバル モードは VPC のサブネットをより広く広告する。したがってモードを変えると、自分のリージョンが使えるものだけでなく、遠端が取り込むものも変わる。
カスタム広告リストはモードを変えても広がらない。オンプレミスのルーターが手書きの範囲リストを持っているなら、欧州のプレフィックスはそこに無いままである。その場合、外向きのルートができても戻りの経路は壊れたままになる。エクスポートしたものではなく、遠端が取り込んだものを確認すること。
モードが決して直さないもの
グローバル ルーティングは、公共インターネットへのアクセス、無関係な VPC 間のトランジット、欠けた静的ルートを与えるものではない。ファイアウォール ルールも IAM も変えないので、ポリシーで拒否された接続は拒否されたままである。
こうした失敗はワークロードの内側からは同じに見え、ルート スコープとは何の関係もない。
遠いリージョンから実際のサービスへ試験し、応答が意図したトンネルを通って戻ることを確認する。モード、広告構成、試験した宛先を記録すること。それでも失敗するなら、モードに再び触れる前に、遠端ルーターの BGP テーブルと VPC のルート一覧を突き合わせる。そうすれば次のリージョン間の報告は、モード変更ではなく事実から始まる。