GCP HA VPN で BGP セッションが Waiting for peer のまま止まる：アドレスペアの入れ替わり
Cloud VPN の BGP セッションが Waiting for peer で止まるときは、トンネル側とピア側のアドレスが入れ替わっていることが多いです。作り直す前にペアを確認してください。
Cloud VPN トンネル上で BGP セッションが Established に到達しない場合、ふつうはルーティングの問題ではなく配線の問題です：互いを鏡写しにするはずの二つのアドレスが逆順に入力されているか、一本目のトンネルのペアが二本目に流用されています。トンネル自体は完全に健全なままセッションが Waiting for peer で止まることがあります。IPsec と BGP は同じ二つの端点の間の別々のネゴシエーションだからです。何かを作り直す前に、どちらが壊れているのかを決めてください。
ほとんどのケースは一つの問いで決まります：ピア側の機器は Cloud Router のアドレスをそもそも見ているのでしょうか。
トンネルの状態とセッションの状態は別の確認項目です
まず IKE と ESP です。トンネルが確立していなければ中の話は意味がなく、BGP アドレスの議論は時期尚早です。トンネルの状態と詳細状態を読み、次に同じトンネルについてルーターの BGP ピア状態を読みます。
トンネルが起動していて BGP ピアが停止しているなら、障害はセッションに絞られます：ピアアドレス、ASN、あるいは内部アドレスに届く TCP 179 のいずれかです。トンネルが起動し、セッションも起動していて、それでも VPC にルートがない のが三つ目のケースです。アドレスを変えても、セッションはすでに動作していてプレフィックスが広告されていないか優先されていないだけなので効きません。この三つを切り分けることが作業の大半です。
各トンネルには両端を埋めた専用の /30 が必要です
HA VPN の各トンネルは 169.254.0.0/16 から link-local の /30 を一つ受け取り、片方のアドレスを Cloud Router のインターフェースに、もう片方をピアに置きます。ピアの欄には必ず遠端を書き、ルーター自身のアドレスは絶対に書きません。
トンネルが二本なら Cloud Router のインターフェースも二つで、それぞれ別の /30 を持ちます。トンネル 0 のペアをトンネル 1 に流用するのが、要約表では整って見えて OPEN パケットで破綻する誤りです。
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
ペアはコンソールの要約ではなくルーターのリソースから読みます。要約はピアアドレスを読み間違えやすい列に並べており、インターフェースの ipRange とピアの peerIpAddress が同じ /30 の反対側の端を指している必要があります。
入れ替わりは作り直しの最中に起きます
トンネルを作り直すときにペアが交差します。古いトンネルのピアアドレスを新しいトンネルのインターフェース欄に写してしまったり、新しいセッションを前のセッションのピアに向けてしまったりします。どちらでも Cloud Router は、いまや自分自身であるアドレスか、背後にトンネルのないアドレスへ OPEN パケットを送ります。
コンソールを開く前に、トンネル名、インターフェース、ルーターアドレス、ピアアドレス、ピア ASN というペアを書き出します。そのうえで二本のトンネルを一度で作成し、二本目が一本目の残り物で埋まらないようにします。
セッションが待つ理由はほかにも三つあります
一つ目はピア ASN です：両側が相手側の ASN で設定されている必要があり、食い違うとピアには届いても確立しません。二つ目はピア自身のファイアウォールで、トンネルインターフェース上の TCP 179 を許可する必要があり、IKE や ESP のルールでは足りません。三つ目は、隣接として設定したアドレスとは別の送信元アドレスから応答するピアです。
判断材料はピア自身のログです。BGP の要約にそのアドレスの隣接が並んでいなければパケットは届いておらず、ペアか経路が誤っています。隣接が Active か Connect に留まっているならパケットは届いていて、セッションのパラメーターが食い違っています。
パケットが流れる順に確認します
外側へ向かって進めます：トンネル状態、次にルーターの BGP ピア状態、次にピアの BGP 要約、最後にルートです。最初の二つが健全なら Cloud VPN 側の編集をやめ、ピア側の機器を触ります。ルーターがピアを停止と報告し、手元の機器に隣接がなければ、ペアが誤っているか BGP ポートがフィルターされています。ピアのトンネルインターフェースでのパケットキャプチャーが、OPEN パケットはそこに届くかまったく届かないかのどちらかだから一目で決めます。
gcloud compute routers get-status ROUTER --region=REGION はピアの状態を使用中のアドレスの隣に表示し、比べるべきペアはまさにこれです。
セッションが確立したら、学習したプレフィックスが VPC のルートテーブルに現れること、両側のホストが一台ずつ応答することを確認します。そのうえで最終的なペアをトンネル名の隣に記録し、次の作り直しがコンソールの要約ではなく検証済みの表から始まるようにします。