VPN の Cloud Router ページを開くと、169.254.0.0/16 内のアドレスを持つ BGP セッションがこちらを見返しています。自然な反応は、そのアドレスを VM のどこかに置いてセッションが上がるのを待つことです。その反応は特定の意味で間違っています。このペアは IPsec トンネルが作る論理リンクに属するもので、マシンの通常のネットワークインターフェースのものではありません。NIC に何を足しても、トンネルが BGP を運ぶようにはなりません。

ペアをホストに足すのではなく、スタックを下って追いかけてください。

コンソールがペアを表示する場所から始める

セッションページには Cloud Router の BGP アドレスとピアアドレスが並び、IPv4 の HA VPN ではどちらも link-local です。その隣にはトンネルを終端する外側のゲートウェイアドレスがあります。これらは別のオブジェクトです。link-local ペアは内側に住み、ゲートウェイアドレスは外側に住み、他の何かが動く前に経路化できていなければなりません。

設定ファイルを開く前に三つとも書き留めてください。混同することがそのまま障害の形だからです。

それを運ぶトンネルまで下りていく

link-local ペアが意味を持つのは、二つのゲートウェイの間に IPsec のセキュリティアソシエーションが存在してからです。Google 側では HA VPN のトンネルが二つのインターフェース上でそれを作ります。自分の側ではピアが交渉したものがそれです。まず swanctl --list-sas でデータアソシエーションを確認し、どのトンネルがどのインターフェースで上がっているかを記録してください。死んだトンネルの上で健全な BGP セッションはありえず、希望的な設定のまま死んだトンネルは日常だからです。

BGP パケットは内側の IP トラフィックです。外側のネットワークは決してそれを見ないので、どのスイッチも二つのアドレスを一つの VLAN に置く必要はありません。

次に Linux 側のピアを合わせて設定する

サポートされたトンネル設計を選び、内側のアドレスはそれに決めさせてください。ルートベースのインターフェースでは、ルーティングエントリと交渉済みのトラフィックセレクタが一致している必要があります。インターフェース名だけでは何も許可しないからです。BIRD を内側のローカルアドレスと Cloud Router の内側アドレスに向け、セッションページの AS 番号を設定し、保護された経路の中で TCP 179 を許可します。遠い外側アドレスへのルートは物理アップリンクに残し、トンネルが自身のトランスポートを捕まえないようにしてください。

自分自身をルーティングするトンネルはハンドシェイク付きのループであり、一時間はファイアウォールの問題のように見えます。

全体を一度にではなく、各段階を順に確認する

段階をたどります。セキュリティアソシエーションが上がっている、内側のピアがトンネルアドレスから到達できる、BGP セッションが確立している、プレフィックスが受け入れられている、そしてワークロードのプレフィックスが実際に使われている。birdc show protocols が答えるのは三つ目の問いだけで、それ以外ではありません。だから人々は早々に勝利を宣言するのです。

確立した隣接は、両側が必要なプレフィックスを広告したことや、それらのルートが優先としてインストールされたことを約束しません。

セッションが確立していてトラフィックがまだ誤った経路を通るなら、広告されたプレフィックスと、ルーティングテーブルがそれをどう扱うかを比べてください。別の場所にあるより具体的なルートや、別経路を優先する設定は、動く BGP セッションと役に立たない転送をもたらします。

これを Router Appliance に適用する前に止まる

Network Connectivity Center Router Appliance は別の接続モデルです。その Cloud Router ピアは HA VPN の link-local ペアではなく、VPC とサブネットの配置から得た内部アドレスを使います。本当の目的がルーティング VM との BGP なら、link-local セッションをコピーせず、その製品のインターフェース要件に従ってください。

link-local のスコープは今も書いてある通りの意味です。論理トンネルがこの隣接を提供するのであって、任意の link-local 宛先を VPC 越しにルーティングすることを許すものではありません。

関連記事