複数NICのGCP VM：応答が誤ったインターフェースから出る理由

Compute Engine VMに二つ目のインターフェースを接続すると、別のネットワーク接続が増えるだけで、対称な戻り経路ができるわけではありません。ゲストは今でも自身のルートとルールからインターフェースと送信元アドレスを選びます。その後Google Cloudは、パケットが出たインターフェースを中心にVPCルーティングとファイアウォールポリシーを適用します。この二つの判断が食い違うと、リクエストは一方のNICに届き、応答はもう一方から出て、支店には半開の会話が見えます。

経路を五つの手順でたどると、ポリシールールを書く前に食い違いが現れます。

手順1：クラウドのNICをゲストのデバイスに対応付ける

クラウドはインターフェースをnic0、nic1などと名付け、ゲスト側では一致する必要のないデバイス名が見えます。何よりも先に、インスタンスのメタデータかインターフェース自身のアドレスから対応関係を解きます。DHCPが提供する通常のデフォルトルートはnic0に関連付けられているため、インターネット向きの経路が偶然勝つことがよくあります。推測したデバイス名に対してポリシーを書くことが、正しいルールを誤ったインターフェースに置く原因です。

アドレス、デバイス名、それぞれが属するVPCを記録してください。その三列の対応表が、以降のすべての手順の入力です。

手順2：二つのルーティング判断に名前を付ける

最初の判断はゲストに属し、このパケットにどのインターフェースとどの送信元アドレスを使うかを決めます。二つ目はクラウドに属し、VPCのルートとファイアウォールポリシーがそのインターフェースの周りで何を許すかを決めます。

VPN向きのVPCで見えるルートは、そのNICを選ぶゲストのルートにはなりません。クラウドのルートはネットワークが届けられるものを示し、ゲストのルートはパケットが何をするかを決めます。

手順3：戻り経路のポリシーを選ぶ

支店プレフィックスの小さく安定した集合には、ゲストの明示的な宛先ルートが最も簡単な表現で、それらのプレフィックスへの応答はVPN向きのインターフェースから出ます。複数のサービスが意図的に異なるローカル送信元アドレスを使う場合、インターフェースごとにテーブルを選ぶ送信元ベースのルールが、各応答を正しい文脈に保ちます。複数インターフェースのドキュメントは、こうした設計が前提とするNICの命名とデフォルトルートの挙動を説明しています。

各テーブルには有効な接続ルートとネクストホップ、さらに問い合わせを受ける宛先が必要です。不完全なテーブルを指すルールは戻り経路の設計ではありません。サブネットの見た目からEthernetゲートウェイを考案せず、そのNICの文書化されたゲートウェイを使ってください。

手順4：ゲスト自身のフィルターを確認する

サーバーがどこで待ち受け、応答がどのローカル送信元を運ぶかを確認します。全アドレスで待ち受けるリスナーはルーティングポリシーを上書きしないため、全アドレスにバインドしても応答が出るインターフェースは変わりません。

Linuxでは、意図した設計に対して逆経路検証を見直します。最初の一手として全体で無効にすると、ルーティングの不具合をスプーフィングの露出と交換し、探していた非対称性を隠してしまいます。

手順5：経路ごとに一つのフローを試す

許可された支店のリクエストと無関係なインターネットのリクエストを別々に検証し、それぞれ実際の送信元と宛先で確かめます。可能なら両方のインターフェースでキャプチャしてください、有用な証拠はどちらのインターフェースが応答を運んだかにあるからです。その後、クラウド側のポリシーが設計した経路を尊重したことを確認します。成功したリクエスト一つは一つのフローを証明するだけで、対称な設計を証明しません。

二つのテストは、異なるルートと異なるファイアウォールルールを通るので、メモで分けておいてください。

二つ目のNICが与えないもの

二つ目のインターフェースはネットワーク接続と別のアドレスを追加します。自動の対称ルーティングを追加するわけでも、ファイアウォールポリシーを迂回するわけでもありません。それをルーティングの修正と見なすことが、マルチNIC設計に後から誰も説明できないルールが溜まる理由です。

VMが他のマシンのトラフィックを転送する必要があるなら、転送を許可するクラウド設定とそれに伴うゲストのフィルターも含めて、そのルーターの役割を明示的に計画してください。