VPN 経由の Google API: サブネットではなく VIP をルーティングする
VPC サブネットへのルートは API の VIP を選択しない。正しい名前を解決し、VIP プレフィックスを広告し、VPC の戻り経路を保ち、そのうえで HTTPS を検証する。
SSH でオンプレミスのサーバーに入り、トンネルを上げると、プライベート VM は応答するが、最初の Google API 呼び出しはルートがないために失敗する。VM のサブネットと API の VIP は別の宛先であり、片方のルートがもう片方を選ぶことはない。プライベート API 呼び出しが動くには三つの条件がそろう必要がある。API 名が VIP に解決すること、VIP プレフィックスがトンネル越しに広告されること、そして VPC が応答を返す方法を知っていることだ。ping はそのどれも教えてくれないし、サブネット内のマシンへの SSH が通っていても同じである。
API の VIP は別個の宛先である
Google はオンプレミスからの API アクセス用に専用の VIP を公開しており、API 名に対して DNS が返すべきなのはそのアドレスである。どちらも小さなプレフィックスで、どちらも RFC 1918 の空間ではない:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
公開アドレスに見えても、ルートがトンネルを出るべきという意味ではない 通常のインターネット向けには。プレフィックスが存在するのは、オンプレミスのクライアントが任意の出口点ではなく、サポートされた経路で Google のフロントエンドに到達できるようにするためだ。トンネルに属する宛先として扱い、調べるホストとして扱わないこと。インターネット向け出口用に書かれたファイアウォール規則は通常これらを落とし、呼び出しが始まる前に失敗するよくある理由がこれである。
どのエンドポイントに届くかは DNS が決める
選んだエンドポイントについて Google が文書化しているレコードにオンプレミスのリゾルバーを向け、アプリケーションが必要とする名前がその VIP で応答するようにする。単に googleapis.com をマッピングするだけでは一覧にならない。パッケージレジストリ、コンテナレジストリ、移行コネクタにはそれぞれ文書化された名前がある。制限付き VIP もすべてのサービスを運ぶわけではないので、解決できても未対応の名前はあるので、リゾルバーに触る前に、アプリケーションが実際に接続するドメインを書き出しておく。
サービス名の代わりに VPC の VM アドレスを推測するのは修正ではなく、別のクライアントが失敗するまで DNS の抜けを隠すだけである。
VIP プレフィックスを広告し、残りは保つ
BGP ベースの接続では、Cloud Router が選択した VIP プレフィックスを広告し、オンプレミスのルーターが意図したセッション越しにその範囲を学習できるようにする必要がある。VPC サブネットだけを広告してもその範囲は加わらず、オンプレミスのルーターはそれらのアドレスに既定の経路を使い続ける。ルーティングテーブル上のプレフィックスだけが、広告がセッションを越えた証拠である。
新しいものを足す間も既存の広告は保持すべきで、ルーターレベルとピアレベルのオプションは到達範囲が異なり、集合を入れ替えると既に動いていたネットワークを撤回しかねない。そのうえで、ルーター全体ではなく各セッションで実際の広告を確認する。欠けたプレフィックスと撤回されたプレフィックスはオンプレミス側からは同じに見えるので、省略と退行を分けるのはセッションの表示である。
VPC 側には独自のルートと戻り経路が要る
VPC の内側では、VIP への経路は次ホップに既定のインターネットゲートウェイを使う必要があり、名前とは裏腹にその通信は Google のネットワーク内にとどまる。VPC には VPN 経由でオンプレミスの送信元へ戻るルートも必要で、これは広告したプレフィックスとは別のオブジェクトである。トンネルとクライアントが同じリージョンにない場合は、文書化されたリージョナルルーティングの要件を考慮する。
戻り経路は独立に確認する。要求方向が通っていても、応答方向の破損は隠れるので、二つの方向、二つの経路があり、それぞれが独自の症状で失敗する。
要求を試し、そのうえで拒否を読む
ICMP エコーはこれらの VIP から応答を得ないので、失敗した ping は何も証明せず、成功した ping もほとんど証明しない。実際のクライアントから名前の応答と選択された経路を調べ、そのうえで目的のサービスへ認可された HTTPS 要求を送る。要求がサービスに届いて拒否されたなら、資格情報、IAM、該当するサービス境界ポリシーを見る。
プライベートルーティングは API の認可を与えず、ID に何が許されるかも変えないので、トランスポートの成功と認可された応答は別の結果であり、両方が必要である。IPv6 の経路も明示しておくこと。IPv4 プレフィックスを設定しても、IPv6 を優先するクライアントについては何も言えない。
Google の オンプレミス向け Private Google Access ガイド は DNS レコードとルーティング要件をまとめて扱っているので、リゾルバーと広告の設定はフォーラムの投稿ではなくこのガイドと比べる。そのうえで同じ要求をもう一度実行し、応答と経路を同じチケットに記録する。