【Google Cloud】Cloud VPN×YAMAHAルータ　接続トラブルシューティング奮闘記

こんにちは。エヌデーデーの金子です。

Google Cloudを活用している皆様、オンプレミスとの接続は快調でしょうか。

本記事では、Google CloudとオンプレミスのネットワークをCloud VPNにつなげた際に起きた事象と対応を記載します。

。。。といってもそこまでカッチリした技術検証をできているわけでもないので、すべてのケースで本記事と同じ対応で接続不全が解消するとは限らない点をご了承ください。

「YAMAHAルータを使ってCloud VPNを繋げたいのだけど、よくわからないエラーが起きて困っている」という人に届いてくれればなぁ、という思いで執筆します。

Google Cloudとオンプレミスネットワークを繋げるには

Google Cloudとオンプレミス環境のネットワークを繋げる場合、Cloud VPNかCloud Interconnectを選択することになります。

後者は専用線接続であり低レイテンシですので本番環境に推奨されます。

ですがそこまで大規模な通信が発生しないのであれば、Cloud VPNでも十分な容量かつセキュアな接続をより低いコストで構築することが出来ます。（※選定の際には通信の上限やGoogle Cloudへの接続を参考にしてみてください。）

今回は、Cloud VPNで対向をYAMAHAルータ（RTX1220）として構成していきます。

構成

以下のようにVPNを構成します。
HA VPNを採用し、トンネルを2本貼った冗長構成をとります。
オンプレ側はグローバルIPを持つゲートウェイの下に、ipsec VPN設定を行うヤマハRTX1220が設置されています。

Cloud HA VPN 全体構成

オンプレ側RTX1220設定値

RTX1220には以下の設定がされています。暗号化方式はikev2でやってみます。

（※赤字が「Cloud HA VPN 全体構成」の図に対応する設定値）


console prompt RTX1220
ip route default gateway X.X.X.X
ip lan1 address ***********
ip lan1 proxyarp on
ip lan2 address ***********
ip lan2 proxyarp on
tunnel select 1
 ipsec tunnel 1
  ipsec sa policy 1 1 esp aes-cbc sha-hmac anti-replay-check=off
  ipsec ike version 1 2
  ipsec ike always-on 1 on
  ipsec ike duration ipsec-sa 1 10800
  ipsec ike duration ike-sa 1 36000
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike keepalive log 1 on
  ipsec ike keepalive use 1 auto
  ipsec ike local address 1 Y.Y.Y.Y
  ipsec ike local name 1 Y.Y.Y.Y ipv4-addr
  ipsec ike nat-traversal 1 on
  ipsec ike pfs 1 on
  ipsec ike pre-shared-key 1 text ikev2事前共有鍵１
  ipsec ike remote address 1 A.A.A.A
  ipsec ike remote name 1 A.A.A.A ipv4-addr
 ip tunnel address 169.254.0.2
 ip tunnel remote address 169.254.0.1
 ip tunnel tcp mss limit auto
 tunnel enable 1
tunnel select 2
 ipsec tunnel 2
  ipsec sa policy 2 2 esp aes-cbc sha-hmac anti-replay-check=off
  ipsec ike version 2 2
  ipsec ike always-on 2 on
  ipsec ike duration ipsec-sa 2 10800
  ipsec ike duration ike-sa 2 36000
  ipsec ike encryption 2 aes-cbc
  ipsec ike group 2 modp1024
  ipsec ike hash 2 sha
  ipsec ike keepalive use 2 auto
  ipsec ike local address 2 Y.Y.Y.Y
  ipsec ike local name 2 Y.Y.Y.Y ipv4-addr
  ipsec ike nat-traversal 2 on
  ipsec ike pfs 2 on
  ipsec ike pre-shared-key 2 text ikev2事前共有鍵２
  ipsec ike remote address 2 B.B.B.B
  ipsec ike remote name 2 B.B.B.B ipv4-addr
 ip tunnel address 169.254.1.2
 ip tunnel remote address 169.254.1.1
 ip tunnel tcp mss limit auto
 tunnel enable 2
bgp use on
bgp autonomous-system 65000
bgp neighbor 1 64999 169.254.0.1 hold-time=30 metric=1000 local-address=169.254.0.2
bgp neighbor 2 64999 169.254.1.1 hold-time=30 metric=1010 local-address=169.254.1.2
bgp import filter 1 include ******************
bgp import 64999 static filter 1
ipsec auto refresh on

問題：BGPセッションが維持できない

さて上記の構成と設定値で接続をしてみたところ、以下の事象が起きました。

・13:30ごろに両トンネルとも疎通確認済み

・15:32ごろ、「BGP Event: BGP peering with 169.254.xxx.xxx went down with reason: HOLD_TIMER_EXPIRED」でBGPピアリングが2本ともダウンし、オンプレ広報ルートがCloud Routerから削除されている。

Cloud Routerのログ

接続した直後は問題ないですが、おおむね2時間後にBGPセッションが維持できずにダウンしてしまいます。

オンプレ側ルータを再起動してリフレッシュすると接続が復元しますが、また一定時間経過後にダウン、という具合でした。

ざっとyamahaの設定ドキュメントとオンプレルータの設定値を見返して、以下の対処をしました。

オンプレ側のNAT構成

今回のオンプレ側の上位ゲートウェイは、グローバルIPアドレスの専有が都合上不可能で、RTXと1対1NATができない状態でした。

この構成は以下の記事を参照するに不可能なのでは。。？と考えましたが、「上位ルーターの配下にVPN接続用途のルーターが複数存在している場合、Google Cloudでは接続がサポートされていない」という話のようです。

Cloud VPN > 高度な構成 > UDP カプセル化

Cloud VPN では、NAT トラバーサル（NAT-T）に UDP カプセル化を使用し、1 対 1 の NAT のみをサポートしています。NAT 背後の外部（パブリック）IP アドレスがない宛先に、IPsec トラフィックが到達できるようにするには、NAT-T が必要です。1 対多の NAT やポートベースのアドレス変換はサポートされていません。つまり、Cloud VPN は、単一の外部 IP アドレスを共有する複数のピア VPN ゲートウェイには接続できません。

VPN接続用のルータはRTXのみであるので、いったんこの構成で問題ないだろう、と判断しました。

また今回、RTXに設定されるipsecのlocal address（以下）はRTXのプライベートIPを設定していました。
ここは1対1NATまたはルータ自体にグローバルIPが振られる場合はグローバルIPの指定となり、基本的に世に出回っている設定例はそのようなものしかなかったのです。

  ipsec ike local address 2 Y.Y.Y.Y
  ipsec ike local name 2 Y.Y.Y.Y ipv4-addr

しかしここは回線上のIPが1つしかなく、RTX側からみるとプライベートな構成であるため、最終的にこのままで大丈夫そうでした。

keepaliveとholdtime

yamahaはBGPごとにhold-timeを設定し、keepaliveはhold-timeの値の1/3で設定されます。
Google CloudのBGPセッションはキープアライブがデフォルト20秒で設定され、hold-timeはその3倍で自動設定されます。

RTXには以下のように設定されていたため、keepaliveが10秒でクラウド側とズレが生じていました。

bgp neighbor 1 64999 169.254.0.1 hold-time=30 metric=1000 local-address=169.254.0.2
bgp neighbor 2 64999 169.254.1.1 hold-time=30 metric=1010 local-address=169.254.1.2

さてこれを一致するように修正をかけましたが、特に改善は見られず。

（※今回の問題解決には至りませんでしたが、keepaliveの間隔はオンプレとGoogle Cloudで一致させるように設定するのが安全です。）

【参考資料】
BGP タイマーの管理 > キープアライブタイマー
YAMAHA設定資料 > 29.12 BGP による接続先の設定

オンプレ側が提案している暗号化方式

Cloud VPNは、オンプレ側とGoogle Cloud側とで暗号化を提案・選択することでSecurity Associations（SA）を確立します。

サポートされている IKE の暗号　＞　提案の順序
YAMAHA設定資料 > 29.12 BGP による接続先の設定
YAMAHA設定資料 > 15.48.2 SA のポリシーの定義
を参照すると、RTX設定値はこのような暗号化方式をクラウド側に提案しているように見受けます。

暗号化整合性Diffie-Hellman（DH）
AES256-CBCHMAC-SHA-1modp1024
 ipsec tunnel 1
  ipsec sa policy 1 1 esp aes-cbc sha-hmac anti-replay-check=off
  ipsec ike version 1 2
  ipsec ike always-on 1 on
  ipsec ike duration ipsec-sa 1 10800
  ipsec ike duration ike-sa 1 36000
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha

しかしGoogle Cloud側で暗号化方式の採択をする際のログが以下のように出力され、selected proposalが安定しません。

selected proposal:ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
selected proposal:ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
selected proposal:ESP:AES_GCM_16_128/MODP_2048/NO_EXT_SEQ
textPayload意味
No proposal was selected.オンプレ側から提案された暗号化方式をGoogle Cloud側が採択できていない
could not decrypt payloadsペイロードの複合に失敗している
integrity check failed整合性チェックに失敗している

YAMAHA設定資料 > 15.44 折衝パラメーターを制限するか否かの設定によるとipsec ike proposal-limitationがoffのとき、サポート可能な折衝パラメーター全てを提案するとのこと。。

これがデフォルトoffとのことで、onの設定に切り替えました。

しかしこれも問題解決には至らず。

最終対応：暗号化方式の変更

結局「ルーティングの問題ではなく暗号化の問題である」「IKE_SAは正常更新されているがIPSecのCHILD_SA更新に何らかの理由で失敗している」という推測の下、暗号化方式をikev2からikev1に変更しました。

すると、安定したようです。最終的なRTXの設定値は以下です。

ip route default gateway X.X.X.X
ip lan1 address ******************
ip lan1 proxyarp on
ip lan2 address ******************
ip lan2 proxyarp on
tunnel select 1
 ipsec tunnel 1
  ipsec sa policy 1 1 esp aes-cbc sha-hmac anti-replay-check=off
  ipsec ike version 1 1
  ipsec ike always-on 1 on
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike keepalive log 1 on
  ipsec ike keepalive use 1 on icmp-echo 169.254.0.1
  ipsec ike local address 1 Y.Y.Y.Y
  ipsec ike local id 1 LANインターフェースのIP
  ipsec ike nat-traversal 1 on
  ipsec ike backward-compatibility 1 2
  ipsec ike pfs 1 on
  ipsec ike pre-shared-key 1 text ikev1事前共有鍵１
  ipsec ike remote address 1 A.A.A.A
  ipsec ike remote id 1 A.A.A.A
 ip tunnel address 169.254.0.2/30
 ip tunnel remote address 169.254.0.1
 ip tunnel mtu 1460
 ip tunnel tcp mss limit auto
 tunnel enable 1
tunnel select 2
 ipsec tunnel 2
  ipsec sa policy 2 2 esp aes-cbc sha-hmac anti-replay-check=off
  ipsec ike version 2 1
  ipsec ike always-on 2 on
  ipsec ike encryption 2 aes-cbc
  ipsec ike group 2 modp1024
  ipsec ike hash 2 sha
  ipsec ike keepalive log 2 on
  ipsec ike keepalive use 2 on icmp-echo 169.254.1.1
  ipsec ike local address 2 Y.Y.Y.Y
  ipsec ike local id 2 LANインターフェースのIP
  ipsec ike nat-traversal 2 on
  ipsec ike backward-compatibility 2 2
  ipsec ike pfs 2 on
  ipsec ike pre-shared-key 2 text ikev1事前共有鍵2
  ipsec ike remote address 2 B.B.B.B
  ipsec ike remote id 2 B.B.B.B
 ip tunnel address 169.254.1.2/30
 ip tunnel remote address 169.254.1.1
 ip tunnel mtu 1460
 ip tunnel tcp mss limit auto
 tunnel enable 2
bgp use on
bgp autonomous-system 65000
bgp log neighbor packet
bgp neighbor 1 64999 169.254.0.1 hold-time=60 metric=1000 local-address=169.254.0.2
bgp neighbor 2 64999 169.254.1.1 hold-time=60 metric=1010 local-address=169.254.1.2
bgp import filter 1 include ******************
bgp import 64999 static filter 1
ipsec auto refresh on

ikev2の設定方法に問題があったのか、まだYAMAHAのルータのikev2は安定していないのか、定かではありませんが。。。

同じように悩んでいる方は、暗号化方式をikev1に落としてみると解決するかもしれません。

問題：VPN通信時に、特定の通信パケットがドロップする

さてCloud VPNとBGPセッションは安定しました。
その後、以下のような問題が発生しました。

・Google Cloud⇒オンプレデータベースへのクエリリクエストのパケットドロップが発生する。
・SELECT TOP (10000) * from table　は応答がある。
・SELECT column1 ,…..,(全カラム指定) column60 from table は応答がないままリンク通信エラー。

レスポンスが重たい処理は返ってくるけど、リクエストがちょっと長い処理は落ちる、という事象です。
ここからVPCとCloud VPNのMTU（最大伝送単位）が原因でパケットが欠損しているのではないか？という話になりました。

Cloud VPNは暗号化方式でトンネル内のMTUに制約があるようです。

今回VPNはAES-CBCで暗号化しているので、MTU に関する考慮事項 > AEAD 以外の暗号のペイロード MTUを見る感じ、VPNのMTUは1374バイト。一方、VPCのMTUは1460（デフォルト）でした。このズレが原因でパケットの断片化が失敗しているのでは？という推理です。

実際にGoogle Cloud 上のVMインスタンスからpingで確認をしてみると。。

user@instance:~$ ping -c 4 -M do -s 1460 通信先IP
PING 通信先IP (通信先IP) 1460(1488) bytes of data.
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460

user@instance:~$ ping -c 4 -M do -s 1432 通信先IP
PING 通信先IP (通信先IP) 1432(1460) bytes of data.
--- 通信先IP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3064ms

user@instance:~$ ping -c 4 -M do -s 1346 通信先IP
PING 通信先IP (通信先IP) 1346(1374) bytes of data.
from 通信先IP: icmp_seq=1 ttl=125 time=9.38 ms
from 通信先IP: icmp_seq=2 ttl=125 time=7.67 ms
from 通信先IP: icmp_seq=3 ttl=125 time=7.94 ms
from 通信先IP: icmp_seq=4 ttl=125 time=7.86 ms

1346(1374バイト – ヘッダ分28バイト)の通信は通り、それ以外は通ってないように見受けます。

ということで、VPCのMTUを1374バイトに設定することにしました。
VPC ネットワークの MTU 設定を変更する

VPCのMTUを変更する場合、VPCに所属するインスタンスを一度すべて停止する必要があります。
またVPCピアリングや他のネットワークとの接続がある場合、それらのネットワークのMTUも変更の考慮する必要があるので、注意が必要です。

問題：Cloud RunサービスからオンプレIP範囲帯への接続が安定しない

さて、MTUも解決して、ひと段落。

続いて起きたのがCloud Runサービスからオンプレへの接続がどうも安定しない、という問題です。

今回の案件ではCloud RunからDirect VPC Egressを使ってVPN接続しているVPCを通り、オンプレに接続する要件がありました。この接続が安定しないのです。

「○○したら接続が途切れる」といった特定のトリガがあるわけではなく、ほんとうに、不定期で、リンク通信エラーが起きるという事象でした。

Cloud RunがDirect VPC Egressとして通過するサブネットと同じIPアドレス帯に位置するVMインスタンスからは安定して接続ができています。

これについては、接続先オンプレミスのプライベートIPアドレスが、Cloud runの既知の問題として挙げられているIPアドレス範囲帯であることが原因ではないか？ということで対処しています。
Cloud Run の既知の問題 > VPC ネットワークの宛先にアクセスする場合のサブネットの制限

プライベート IP 経由でいずれかの宛先にアクセスする場合、宛先をサブネット 192.168.1.0/24 上にすることはできません。このサブネットを使用すると、Cloud Run が宛先と通信できなくなります。

なるほど。いったんVPNの接続問題とは関係がなさそうだ、という所で対応の詳細は本記事では割愛します。

まとめ

さて、VPCとオンプレミスをCloud VPNとYAMAHAルータで設定をする際に、今回で得た教訓は以下です。

・暗号化方式はikev1が安定した（2024/10現在）
・VPNを貼るYAMAHAルータは、上位ルータと1対1NAT構成でなくとも敷設できた。
（※上位ルータの配下にVPN接続用途のルータが複数存在している場合、サポート外となるので注意）
・Cloud VPNを使う際は、MTUの制限が暗号化方式によって決まるので注意

Cloud VPNの仕様のみならず、実機のメーカーごとの設定仕様/オンプレNWの制約などを抑えておかないとVPN敷設で何かあった時にトラブルシューティングが大変になってしまうことも教訓ですね。

Cloud VPNはお手軽かつ低コストでオンプレとVPCを接続できるサービスですが、採択の際はこの辺りを意識して検討することをおススメします。

Google Cloud,事例,実装例,技術者向けCloud VPN,Google Cloud Platform(GCP),RTX1220

Posted by 金子 悠里