GCP Cloud VPN の障害と対応経緯について
こんにちは。エヌデーデーでGCPの運用を担当している田中です。
2020/7/22から発生していたCloud VPNの障害により、GCPと社内ネットワークの通信が切断される事象が発生しました。
現在は無事に復旧しておりますので、本事象と対応の経緯についてお話したいと思います。
事象の経緯
弊社では、GCP上の２つのVPCから、それぞれ別々のオンプレミスルーターにVPN接続する構成をとっておりましたが、2020/7/22 17時頃から、各VPNが切断される事象が発生しました。
HA（高可用性） VPNの構成をとっており、それぞれ２本ずつVPNトンネルを張っていたのですが、全てのトンネルのBGPセッションが停止状態に。
VPNゲートウェイのログを確認したところ、以下の様なログが確認されました。
tried 1 shared key for 'xx.xx.xx.xx’ – 'xx.xx.xx.xx’, but MAC mismatched
どうやら、pre-shared key が一致していないことが原因で、VPNが切断されてしまったとのこと。
pre-shared key 含む Cloud VPN 周り、及びオンプレミスのルーター共に設定を変更した覚えがないため、GCP側で仕様変更があったのではないかと思い、Google社に問い合わせを行いました。
対応の経緯
対応１
ブログやTwitterで検索すると、ちらほらと同様の事象の情報が出てきました。
事象が発生している方々の共通点は、オンプレミスでYAMAHAルーターを利用しているということ。
弊社の環境でも例外に漏れずYAMAHAルーターを利用していました。
そんな中、Google社から「IKEのバージョンをv1に下げる」ことで復旧した事例の紹介があったため、IKEv2からIKEv1に変更する方法を試してみることに。
結果、GCPのコンソール上ではBGPセッションのステータスが「確立」されたように見える（図１）ものの、VPCネットワークのルートが正常にアドバタイズされていない （図２） ような状態となり、VPNの復旧には至りませんでした。
対応２
再度問い合わせを行ったところ「他のユーザーからも同様の報告を受け、切り戻しを実施した」との連絡が。
そこで、Cloud Router、VPNゲートウェイ、VPNトンネルを作り直し、IKEv2で再接続してみることに。
しかし、結果は変わらず、対応１と同様の状態となりました。
Cloud VPNのトラブルシューティング を参照しながら、ログ等を確認してみるものの原因を特定できず。
そもそも、YAMAHAルーターとの接続が非推奨になっているのではないかと疑い、 Cloud VPN でのサードパーティVPNの使用 ドキュメントを確認しましたが、以下の様な記載があるのみで、下記の条件に合致しているYAMAHAルーターが非推奨扱いになっているようには見受けられませんでした。（この記事の執筆時点の情報となります。）
IPSEC と IKE バージョン 1 または 2 をサポートするすべてのサードパーティ デバイスまたはサービスは、Cloud VPN に対応しています。
対応３
幸いVPNの切断による業務影響はほとんどなかったため、為す術なく対応保留としていたところ、突然、VPN接続設定を行っていた２つVPCの内、片VPCのBGPルートが正常にアドバタイズされるようになり、VPNが復旧していることに気が付きました。
数日のタイムラグがあった後、自然にもう一方のVPNも復旧しました。
Google社に問い合わせを行ったところ、再度修正リリースが行われていたことを確認しました。
結局のところ、Cloud Router、VPNゲートウェイ、VPNトンネルの再作成と、オンプレミスルーターの再設定は行ったものの、IKEはv2のままで、事象発生前の設定から何も変更しない状態で復旧した形となりました。
まとめ
2020/7/22 あたりから VPN に問題が発生しており、現在も不安定であるという方がいましたら、今一度、事象発生前の状態（IKEv2）に戻してみることで復旧するかもしれません。
クラウドサービスを利用することで、オンプレミスでは考えられないくらい自由に、そして手軽に、高機能なサービスを利用できる反面、ユーザー側ではコントロールできない部分が多く存在することも事実です。
高い可用性が求められるシステムをクラウドに構築する場合は、一つ一つのリソースやサービスに依存しすぎないよう、可能な限りリスクを分散できるような構成とすることが大事であると痛感しました。