自宅と Google Cloud を VPN でつなぎマネージド DB と通信してみた
TL;DR
この記事では、個人でも安価に手に入れられる高機能ルーター EdgeRouter X を使って、自宅ネットワークと Google Cloud の VPC を Site-to-Site VPN でつなぎ、手元の PC からプライベート IP 経由で Cloud SQL インスタンスに接続するまでの道のりを紹介するものです。
はじめに
この記事は、Google Cloud Japan Customer Engineer Advent Calendar 2020 の 17 日目の記事です。（間に合っていれば・・・）
こんにちは、Google Cloud で Data Management Specialist というロールをやっている佐藤です。データ マネジメントってデータ管理？具体的になにやってんの？って感じのロール名ですが、要は DB スペシャリスト + その周辺をメインでやってます。
そんなわけで僕は RDBMS を触ることが多く、Cloud SQL など各種マネージド DB を使って検証することが結構あります。そうすると、家の手元の PC から、Cloud SQL とかのプライベート IP アドレスにつなぎたいなって思うことがよくあるんですよね。
API に対して gRPC で通信する Cloud Spanner といったクラウド ネイティブな DB と異なり、Cloud SQL の中身は MySQL だったり PostgreSQL だったり SQL Server といわゆる一般的な RDBMS です。各種ドライバ経由で Cloud SQL のインスタンスが持っている IP アドレスに対してコネクションを張って通信をすることになります。他にも mysql コマンドや psql コマンドを使って DB に接続したりしますよね。
リモートワーク需要が高まる昨今ですが、自宅で仕事してると、さっとクラウド上の DB に接続して検証したくなるわけですが、自宅と雲の中の間にはインターネットという分厚い壁があるため、そのままではパブリック IP 経由で通信しなければなりません。実業務などではよくオンプレ環境とクラウドを VPN でつないで、プライベート IP 接続するってことがありますよね。だったらやはり家からつなぐときも、手元のコンソールからプライベート IP アドレス指定で、mysql コマンドや psql コマンド使いたいなと思っちゃいますよね。あとなんなら自宅との間で DB レプリケーション組みたいなと。
よしじゃあ、家のネットワークと Google Cloud 上の自分の VPC を直接つないでしまいましょう！
目次
- 1. Cloud SQL が Cloud VPN に対応していた話
- 2. 自宅と Google Cloud を VPN でつなぐ 1 歩目
- 3. VPN トンネルの作成 : Google Cloud 側の設定
- 4. VPN トンネルの作成 : 自宅側（ER-X）の設定
- 5. 自宅から プライベート IP での Cloud SQL への接続
1. Cloud SQL が Cloud VPN に対応していた話
もう 1 年前のことなのですが、Cloud SQL のリリースノートに以下のような記載がひっそりと現れました。
上記のリンク先は Cloud SQL のドキュメント「外部ソースから接続する」のページでした。
1. VPC ネットワークが Cloud VPN トンネル、または Dedicated Interconnect か Partner Interconnect の相互接続アタッチメント（VLAN）を使用してオンプレミス ネットワークに接続されていることを確認します。
2. プライベート サービス接続によって生成されるピアリング接続を特定します。
・cloudsql-mysql-googleapis-com
・cloudsql-postgres-googleapis-com
・servicenetworking-googleapis-com3. すべてのピアリング接続を更新して、カスタムルートのエクスポートを有効にします。
4. プライベート サービス接続に使用される割り振り範囲を特定します。
5. Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）の BGP セッションを管理する Cloud Router の割り振り範囲用に Cloud Router のカスタムルート アドバタイズを作成します。
これだけだと何がどう VPN に対応したのか分かりづらいですね。ただ VPN を張るだけだと、VPN 越しに Cloud SQL に接続できなかったということでしょうか？はい、実はそうなんです。それは Cloud SQL のインスタンスが、ユーザーの VPC 内には無いからという背景があります。
Cloud SQL インスタンスはユーザーの VPC 内ではなく、専用の VPC に構築されます。そしてユーザーの VPC とピアリングすることで、ネットワーク的に疎通ができるようになり、GCE 上で動作するアプリなどから通信できるようになります。
VPC ネットワーク ピアリングの画面を見てみると、 Cloud SQL 用の VPC とピアリングしてる情報を見ることができます。下の図の赤枠は Cloud SQL for MySQL 用の VPC ですが、他にも PostgreSQL や Redis の VPC などが表示されていることがわかります。
さて、過去は VPN 対応していなかったとはどういうことでしょうか？
オンプレミス環境と VPN で接続した場合、以下の図のようになります。オンプレとユーザーの VPC、ユーザーの VPC と Cloud SQL の VPC はそれぞれピアリングしている状態なのですが、オンプレと Cloud SQL の VPC が直接ピアリングしているわけではありません。間接的にネットワーク経路があるだけです。このような推移的ピアリングはそのままでは通信できないのです。
通信できるのは、ダイレクト ピアリングしたネットワークだけです。推移的ピアリングはサポートされていません。たとえば、VPC ネットワーク N1 が N2 と N3 にピアリングされ、N2 と N3 が直接接続されていない場合、VPC ネットワーク N2 は VPC ネットワーク ピアリング経由で VPC ネットワーク N3 と通信できません。
https://cloud.google.com/vpc/docs/vpc-peering/?hl=ja#restrictions
これを通信できるようにする機能が「カスタムルートのインポートとエクスポート」です。この機能は VPC がもってるカスタムルート（ VPC のサブネット自体の経路以外の、ユーザーが静的に設定した経路や、Cloud VPN、Cloud Interconnect 等で使う BGP により動的に広告された経路）を、他の VPC にエクスポートしたりインポートしたりすることができます。この機能を併用することで、ようやく Cloud SQL の VPC とオンプレミス環境が、互いにネットワークの経路情報を知ることができ、通信ができるようになるわけです。
ここの詳細は、昨年のアドベントカレンダー「GCP の細かすぎて伝わらないハイブリッドネットワーキング — VPC ピアリング カスタム経路 import export」にて触れられていますので、併せて御覧ください。
2. 自宅と Google Cloud を VPN でつなぐ 1 歩目
さて Google Cloud に VPN を張ることができれば Cloud SQL に接続できそうだということが分かったので、さっそく VPN を試してみましょう。
Google Cloud に VPN 接続するサービスといえば Cloud VPN ですね。Cloud VPN を使うにはどんな要件があるのでしょうか？
Cloud VPN では、このセクションに記載されている要件に従って、サイト間の IPsec VPN 接続のみがサポートされます。クライアントからゲートウェイへ（モバイル通信）のシナリオはサポートしていません。つまり、Cloud VPN は、クライアント PC がクライアント VPN ソフトウェアを使用して VPN に「ダイヤルイン」する必要があるケースをサポートしていません。
クラウド VPN は IPsec のみをサポートします。他の VPN テクノロジー（SSL VPN など）はサポートされていません。
https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview#specifications
残念ながらクライアント VPN ソフトウェアなどは提供されていないため、クライアント PC から直接 VPN 接続することはできなそうです。となると IPSec VPN に対応したルーターを入手して、家のネットワークに接続すれば良さそうです。しかしそれができそうなのって業務用のルーターだったりして、個人ではハードルが高いイメージがありました。
2.1 IPSec VPN 対応の安価なルーター EdgeRouter X の入手
EdgeRouter X （以下 ER-X と省略）とは Ubiquiti 社から発売されている、安価で高性能なルーターで、個人でもネット販売で容易に入手可能です。5 ポートのギガビット イーサネット（RJ45）を備えており、今回 Cloud VPN と接続するために必要な Site-to-Site VPN を実現する機能も組み込まれています。もしこの記事を読んで、自分の家でも試してみたいという方は、数千円で販売されていますので探してみてください。（電源アダプタが付属してないパターンがあるらしいので、付属が明記されているものをおすすめします。）
2.2 ER-X の初期設定
ER-X は高機能なルーターです。今回はその中でも VPN の機能を使うだけという贅沢な使い方をしています。もちろん他にも様々な使い方ができるので、興味がある人は詳細な使い方は各自調べてみてください。ここでは、VPN 周り以外で最低限必要な設定だけの言及にとどめます。
箱から出した ER-X を電源つないでみましょう。特に電源ボタンとかはないので、電源につなげばそのまま起動します。デフォルト設定では、eth0 にだけ 192.168.1.1 の IP アドレスが設定されているので、Ethernet ケーブル挿すと接続できます。ログイン情報は以下のとおりです。
eth0 の IP アドレス : 192.168.1.1
初期管理者 ID : ubnt
初期管理者 Password : ubnt一般的な家庭用ルーターはブラウザで接続して GUI で設定することがほとんどですが、ER-X は業務用ルーターの様にコマンドラインで設定ができます。SSH で接続ができますので、早速接続して設定していきましょう。
あとは Linux ライクにコマンドを実行できるのですが、configure でルーターの設定モードに入り、commit でその設定を反映するという形になります。モードを抜けるには exit 、または何か設定を変えてしまったが保存せずに抜けたいときは exit discard です。なお commit しただけだとまだメモリ上での反映であり、永続化はされていません。save すると永続化されて、再起動しても設定残ります。その他、show で現在の設定一覧を確認したり、なにか設定を変更した後 commit 前に compare することで、変更差分を確認できます。
初期 IP アドレスが家のネットワークのものと合ってないので、まずはそこを修正しましょう。僕の家では 192.168.1.0/24 のネットワークを使っているので、192.168.1.1 は家のブロードバンド ルーターのアドレスなので困ります。ER-X の IP は 192.168.1.250 にすることにします。ここはみなさんの家の環境に合わせて設定しましょう。
実際のコマンドは以下のとおりです。まず configure で設定変更モードに入り、今のアドレスを delete し、新しいアドレスを set します。そして変更を commit します。
configure
delete interfaces ethernet eth0 address
set interfaces ethernet eth0 address 192.168.1.250/24
commitIP アドレス部分は適宜皆さんの家で適切なものに置き換えてください。これで commit をすると、直後に ER-X の eth0 に設定されていた IP アドレス変更が反映されて一旦接続が切れてしまいます。再度 SSH して新しい IP アドレスに接続し直しましょう。
このままだと外の世界に出られないので、デフォルトゲートとして、自宅のブロードバンド ルーターなどを設定しましょう。うちのデフォルトゲート（0.0.0.0/0）は 192.168.1.1 ですので、それを設定しています。また configure して設定変更モードに移り、各種設定を入れていきます。
conigure
set protocols static route 0.0.0.0/0 next-hop 192.168.1.1あとはいくつか最低限の入れたほうがよさそうな設定を入れてみます。今後使う上でログの時刻がずれてると大変なので、タイムゾーンや NTP による時刻合わせをしておきましょう。また ER-X には特定の処理を行う専用チップが内蔵されているのですが、それを有効にしないと活用してくれないので、それも有効にします。デフォルトユーザー ubnt はパスワードをとりあえず変えてあります。実際にはこのデフォルト アカウントを無効化して、新規でユーザーを作るなどでも良いでしょう。そこは各自でやっておいてください。なお plaintext-password となってますが、実際には保存時は暗号化されます。
そして一連の変更を commit して save しましょう。
# TimeZone と NTP の設定
set system time-zone Asia/Tokyo
set system ntp server time.google.com
delete system ntp server 0.ubnt.pool.ntp.org
delete system ntp server 1.ubnt.pool.ntp.org
delete system ntp server 2.ubnt.pool.ntp.org
delete system ntp server 3.ubnt.pool.ntp.org# デフォルト ユーザーのパスワード変更
set system login user ubnt authentication plaintext-password 任意の文字列# ハードウェア オフロード周りの有効化
set system offload hwnat enable
set system offload ipsec enable# 変更を反映
commit# 変更を保存（永続化）
save
commit すると、オフロードの有効化について、再起動しないと有効にならないよとメッセージが出てるので、save した後に、ここで一旦再起動（電源の抜き差しで OK）しておきましょう。なお、なんか WARNING 出てますが、今回は IPv4 による site-to-site IPsec VPN を使うのでこの警告内容の対象外ですので、無視してかまいません。
これで今あなたの家のネットワークには、ER-X がぽつんと設置された状態です、ここに Google Cloud 直結の VPN を設定してみましょう。
3. VPN トンネルの作成 : Google Cloud 側の設定
さて早速 VPN トンネルを作成していきましょう。まずは Google Cloud 側の設定です。VPN を接続したいプロジェクトを開き、Google Cloud コンソールのサイドメニューより、「ハイブリッド接続」の「VPN」を選び、「VPN 接続を作成」を選びます。すでに VPN を作成したことがあれば一覧画面になってしまっていると思いますので、その場合は上部メニューの「VPN 設定ウィザード」をクリックします。ウィザードが起動するので、それに従い VPN を作成します。
Cloud VPN の作成には現在オプションが 2 種類あります。HA VPN と Classic VPN です。現在 HA VPN が推奨となっておりますので、今回はこちらを使いたいと思います。
Classic VPN の部分的なサポート終了
Google では、信頼性と可用性に優れた VPN 接続を提供するため、Classic VPN のほとんどの機能を HA VPN に移行し、HA VPN への移行を推奨しています（この機能は 2019 年 9 月から提供されています）。
https://cloud.google.com/network-connectivity/docs/vpn/deprecations/classic-vpn-deprecation?hl=JA
作成は、ウィザードに従い、4 つの手順で進めることができます。なおドキュメント「ピア VPN への HA VPN ゲートウェイとトンネルペアの作成」をあわせて御覧ください。
このウィザードの中で、以下の図にある 4 つのコンポーネントの設定を行います。
- VPN ゲートウェイ
- ピア VPN ゲートウェイ
- Cloud Router
- VPN トンネル
3.1 VPN ゲートウェイの作成
VPN ゲートウェイとは、Cloud VPN の Google Cloud 側の接続用ゲートウェイになります。このゲートウェイは、VPC 側の特定のリージョン及びネットワークと紐づきます。今回は、東京リージョンの、default ネットワークに設定してみます。作成すると、自動的に接続用のパブリック IP が払い出されます。
以下の通り 2 つの IP アドレスが設定されたのがわかります。HA VPN は可用性のために、2 つのインターフェースを使って 2 本の VPN トンネルを張るのが正しい使い方です。
今回は設定を簡単にするために、片方の IP アドレスを使って 1 本のトンネルだけを作っています。なお 1 本のトンネルだけだと実際には HA VPN の高可用性成分の恩恵に預かれない点はご注意ください。可用性が求められる環境で使う際は、正しく HA VPN を構成してくださいね！（今回手抜きでごめんなさい）
3.2 ピア VPN ゲートウェイの作成
続いてピア VPN ゲートウェイの作成です。ピア VPN ゲートウェイとは、ここの記事内においては自宅側のゲートウェイのことです。自宅側のパブリック IP アドレスをあらかじめ調べておき、ここで設定します。
ピア VPN ゲートウェイも複数のインターフェースを想定することができます。今回は自宅には 1 つのパブリック IP しか持っていないため、「1 つのインターフェース」を選択肢、自宅のパブリック IP アドレスを入力します。
3.3 Cloud Router の作成
続いて Cloud Router の設定です。Cloud Router は、VPN トンネル設置が完了後、自宅ネットワークと Google Cloud の VPC ネットワークの経路情報をやり取りするために必要になります。ウィザードに従って前の手順を終えると、ルーティング オプションの項目で Cloud Router を選択する画面があります。新規に VPN 用の Cloud Router を作成します。
ルーターには、ASN ( AS Number / AS 番号)というものを設定します。HA VPN では経路制御プロトコルに BGP を使っており、BGP では経路制御行う組織ごとに ASN と呼ばれるユニークな番号を持っています。
本当にインターネットの世界で BGP を使って経路情報をやり取りする際は、世界でユニークな ASN というものが必要なのですが、今回は閉じたプライベート ネットワークですので、プライベート ASN の範囲から好きなものを使うことができます。パブリック IP と プライベート IP みたいな感じですね。
ドキュメントにある通り、ここでは 64512を Cloud Router 側の ASN に割り当ててみます。後ほど自宅ネットワーク側にも今設定したものとは異なるプライベート ASN を設定する必要があります。
新しい Cloud Router を作成するには、新しいルーターの [名前]、[説明]、[Google ASN] を指定します。ネットワーク内の他の場所では使用していない任意のプライベート ASN（
64512～65534、4200000000～4294967294）を使用できます。Google ASN は同じ Cloud Router のすべての BGP セッションで使用され、後からの変更はできません。https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#creating-ha-gw-peer-tunnel
3.4 VPN トンネルの追加
そしていよいよ VPN トンネル自体の追加を行います。トンネル自体の設定項目はほとんどなくて、IKE バージョンとして「IKEv2」を選び、IKE 事前共有キーとして、自分で任意の文字列を入力するか、「生成してコピー」をクリックしてランダムなキーを生成してください。
3.5 BGP の構成
続いて出てくるのが、 BGP セッションの構成画面になります。これは VPN トンネルが開通したあと、そこで家のネットワークと VPC とのネットワーク経路交換の設定になります。「構成」をクリックして、BGP セッションの作成画面に移ります。
ここでまた Cloud Router の設定で登場した ASN(AS 番号) が登場します。先ほど Cloud Router の ASN として 64512 を入力しましたが、ここで入力するのはピア ASN すなわち、自宅ネットワーク側の ASN です。ここでもプライベート ASN の範囲で任意の番号を入力します。今回は 65100 としました。この番号は後ほど ER-X の設定で必要なので覚えておいてくださいね。
BGP セッションではもう 1 つ設定項目があります、BGP IP です。BGP IP とは、VPN トンネル内の両端にある仮想インターフェースの IP アドレスです。BGP IP に使えるアドレスの要件として、ドキュメントには以下の記述があります。
・各 BGP IP アドレスは、169.254.0.0/16 内に収まる同じ /30 CIDR に属している必要があります。
・各 BGP IP アドレスには、/30 CIDR の最初のアドレス（ネットワーク）または最後のアドレス（ブロードキャスト）を使用できません。
・BGP セッションの各 BGP IP アドレス範囲は、VPC ネットワークのすべてのリージョンの Cloud Router 間で一意でなければなりません。https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#creating-ha-gw-peer-tunnel
ここでは 169.254.10.1 と169.254.10.2 をそれぞれ設定してみることにしました。なお BGP ピア IP とは、後ほど ER-X 側の仮想インターフェースに設定する IP アドレスですので、こちらも ASN と同様設定内容を覚えておいてください。
3.6 一旦 VPN トンネルの設定が完了
以上で Google Cloud 側の設定は完了です。
しかしまだ自宅側に一切設定を行っていないので、当然トンネルはまだつながっておらず VPN は完成してません。実はこの時点で Cloud VPN ゲートウェイからは、定期的にピアゲートウェイの IP に対して接続を行おうと繰り返しています。VPN ゲートウェイのログを確認するとその様子を見ることができます。しかし自宅側はまだ設定していないため、この接続に誰も応答を返してくれません。結果として以下のように「受信パケットがありません」というステータスが続きます。
続いて自宅の ER-X 側に VPN の設定を行っていきたいと思います。
4. VPN トンネルの作成 : 自宅側（ER-X）の設定
続いて ER-X の設定です。Cloud VPN に接続してくるルーターの機器は多岐に渡るため、ベンダーや機種ごとに設定方法は異なります。Cloud VPN は IPSec ESP トンネルモードで動作するため、それに合った設定を行う必要があります。設定全体のお話はドキュメント「ピア VPN ゲートウェイの構成」に記載があり、基本これにあった設定を各ルーターで行う形です。
こちらにドキュメント「Cloud VPN でのサードパーティ VPN の使用」に代表的なルーターの設定例の記載がありますが ER-X 用のものはなさそうです。一応 VyOS 向けのコンフィグ例はあり、VyOS と ER-X が採用している Vyatta は同じ系統のものなので、参考にはなりそうです。また ER-X の公式ドキュメントにある「EdgeRouter VPN Configuration」に、Google Cloud 用のものではないのですが Site-to-Site VPN 用の設定例がいくつかあるので、こちらも参考になりそうです。
4.1 VPN の設定
それらの情報から、 ER-X から Cloud VPN に VPN 接続を行う、以下のような設定を書いてみました。あくまで一例に過ぎません。
# IPSec 用の firewall / NAT ポリシーを自動設定する機能を有効に
set vpn ipsec auto-firewall-nat-exclude enable# IKE の設定
set vpn ipsec ike-group GCP-IKE key-exchange ikev2
set vpn ipsec ike-group GCP-IKE lifetime 36000
set vpn ipsec ike-group GCP-IKE proposal 1 encryption aes256
set vpn ipsec ike-group GCP-IKE proposal 1 hash sha1
set vpn ipsec ike-group GCP-IKE proposal 1 dh-group 14
set vpn ipsec ike-group GCP-IKE dead-peer-detection action restart
set vpn ipsec ike-group GCP-IKE dead-peer-detection interval 30
set vpn ipsec ike-group GCP-IKE dead-peer-detection timeout 120# ESP の設定
set vpn ipsec esp-group GCP-ESP lifetime 10800
set vpn ipsec esp-group GCP-ESP pfs enable
set vpn ipsec esp-group GCP-ESP proposal 1 encryption aes256
set vpn ipsec esp-group GCP-ESP proposal 1 hash sha1# IPSec トンネルの設定
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> authentication id <ピアゲートウェイの IP アドレス（つまり家）>
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> authentication mode pre-shared-secret
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> authentication pre-shared-secret <IKE 事前共有キー>
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> description 'ipsec-gcp'
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> connection-type respond
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> local-address <ER-X の IP アドレス>
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> ike-group GCP-IKE
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> vti esp-group GCP-ESP
set vpn ipsec site-to-site peer <VPN ゲートウェイの IP> vti bind vti0
set interfaces vti vti0 address 169.254.10.2/30
1行目は、ER-X が持ってる、IPSec 用の firewall / NAT ポリシーを自動化する機能です、一応 ON にしておきます。
IPSec による VPN では、SA と呼ばれるコネクションを確立しますが、そこで SA 構築に必要な鍵交換の仕組みに IKE を、実際通信を行う際 VPN トンネルの暗号化の仕組みに ESP と呼ばれるものを使います。ここではそれぞれの暗号化に何を使うかとか、有効期限はどのくらいにするかといった設定を入れています。実際には、ここでは Cloud VPN と ルーターの双方が対応しているものから適したものを選びます。
IKE の設定として一連のこの設定を GCP-IKE という名前をつけています。ESP についても同様で、一連の設定に GCP-ESP という名前をつけています。そしてこの設定を持って、IPSec トンネルの設定を行っています。
set vpn ipsec site-to-site peer で始まる、IPSec トンネルの設定が、今回の VPN 接続固有の設定です。
- VPN ゲートウェイの IP：set vpn ipsec site-to-site peer に続けてこの IP を入力します。各自の値を入力してください。
- ピア ゲートウェイの IP：自宅のパブリック IP のことで、これを authentication id として利用します。
- IKE 事前共有 キー：先ほど VPN トンネルの設定で自動生成したキーです。pre-shared-secret に入力します。
- ER-X の IP アドレス：ER-X のローカルのアドレスで、この記事の例では 192.168.1.250 になります。local-address に設定します。
- 仮想インターフェース vti0：BGP セッションの ER-X 側終端で、この記事の例では 169.254.10.2 のアドレスを利用しています。
- 接続方式：connection-type respond としていて、接続の開始はピア（Cloud VPN）からの通信を待つようにしています。
上記コマンドを流しきって commit しましょう。そうするとトンネルの設定は完了です。さてこれでつながるでしょうか？先ほど VPN ゲートウェイから接続に来ているという話をしました。ER-X まで通信が届けば、ER-X が応答を返し、VPN トンネルが張られるはずです。
4.2 NAT 利用時の注意
今回僕が例に出してる家のネットワークもそうですが、この記事の例では、ER-X は家のメインのルーターの裏に隠れており、インターネットから直接到達できません。このままでは ER-X が VPN ゲートウェイと会話できないため、適切に NAT などの設定を、家のブロードバンド ルーターに設定してあげる必要があります。
Classic VPN ゲートウェイと HA VPN ゲートウェイでは、外部の（インターネット ルーティング可能な）IPv4 アドレスを使用します。これらのアドレスに許可されるのは ESP、UDP 500、UDP 4500 のトラフィックのみです。これは、Classic VPN 用に構成した Cloud VPN アドレス、または HA VPN 用に自動的に割り当てられたアドレスに適用されます。https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview?hl=JA#specifications
- ESP (IP 50)
- UDP 500
- UDP 4500
この 3 つについて、ER-X のプライベート IP に転送されるような設定が必要です。NAT を使って VPN ゲートウェイのアドレスから来たこれらのパケットを、ER-X に転送するルールを設定しましょう。
また家でお使いのルーターによっては、「IPSec パススルー」「IPSec ALG」などという設定があり、それらを有効にする必要がある場合もあります。特に ESP は TCP でも UDP でもなく、プロトコルとしての IP のポート 50 による通信であり、ブロードバンド ルーターによっては直接 NAT で転送設定ができない場合があります。IPSec パススルーといった設定はそのような環境で、ESP パケットを通過させる設定になります。お使いのブロードバンド ルーターの説明書を確認してみてください。
なお、一番楽なのは ER-X のアドレスを DMZ (外から来た未知の通信をすべて ER-X に届ける)に設定してしまうことです。もしこれを使う場合は、今何も考えていない ER-X のセキュリティを考えないといけません。特に最低限 ubnt/ubnt のデフォルトユーザーは使用不可にしましょう。
さて、これらの転送設定が完了してしばらくすると、Cloud VPN のコンソールに変化が現れます。VPN トンネルのステータスが「確立済み」になりました。これで無事設定完了・・・というわけにはいきません。最後の砦 BGP の設定が残っています。
4.3 BGP によるルーティング設定
ER-X にすべき BGP の設定は 2 種類あります。1 つが BGP セッションの設定で、もう 1 つが何の経路を交換（インポート、エクスポート）するかというものです。
僕の例では、自宅のネットワークは 192.168.1.0/24 ですの、この経路をエクスポートする必要があります。一方で VPC からは、今回 VPN の設定と紐付けてた default ネットワークの IP アドレス範囲をインポートする必要があります。また今回の最終目標は Cloud SQL と接続するため、Cloud SQL の経路も受け取る必要があります。
今回は自分の VPC とつなぐので事故は起こりにくいですが、意図しない経路を受け取ってしまったり、意図しない経路を広告してしまうと、通信が全くできなくなってしまうことがあるため、あらかじめ必要なものだけを交換する設定をします。
現在自分の VPC ではどのようなネットワーク範囲が使われているのでしょうか？ VPC ネットワークから確認することができます。東京リージョン（asia-northeast1）は 10.146.0.0/20 のレンジが使われているようです。
続いて Cloud SQL で使われている VPC の IP アドレス範囲を確認してみましょう。Cloud SQL のプライベート IP には、「プライベート サービス接続」であらかじめ設定された IP アドレスの範囲が利用されます。
えっ、設定した記憶ない？もし自分で明示的に設定していない場合、おそらく初めて Cloud SQL インスタンスにプライベート IP を設定しようとしたときに、案内に従って気が付かないうちに作られてしまっていると思います。
この範囲は、VPC ネットワークから該当ネットワーク（今回は default）を開き、VPC ネットワークの詳細画面から、確認することができます。
これによると僕の環境では 10.35.32.0/20 が Cloud SQL 含む、いくつかのマネージド サービスのプライベート IP に使われる範囲になっているようです。
これらをインポート及びエクスポートするポリシーを記載します。
# エクスポートする経路のポリシー
set policy prefix-list BGP-HOME rule 100 action permit
set policy prefix-list BGP-HOME rule 100 description permit-localsubnet
set policy prefix-list BGP-HOME rule 100 prefix 192.168.1.0/24# インポートする経路のポリシー
set policy prefix-list BGP-GCP-VPC rule 100 action permit
set policy prefix-list BGP-GCP-VPC rule 100 description permit-google-managed-services
set policy prefix-list BGP-GCP-VPC rule 100 le 32
set policy prefix-list BGP-GCP-VPC rule 100 prefix 10.35.32.0/20set policy prefix-list BGP-GCP-VPC rule 101 action permit
set policy prefix-list BGP-GCP-VPC rule 101 description permit-gcp-vpc-tokyo
set policy prefix-list BGP-GCP-VPC rule 101 le 32
set policy prefix-list BGP-GCP-VPC rule 101 prefix 10.146.0.0/20
そしてこのポリシーを使い、ER-X 側の BGP の設定を完了したいと思います。必要な情報は、先ほど覚えておいてくださいねと書いた、以下の ASN と BGP IP です。
- Cloud Router：ASN 64512, BGP IP 169.254.10.1
- 自宅（ER-X）：ASN 65100, BGP IP 169.254.10.2
# ポリシーに対してエクスポート及びインポートを行う
set protocols bgp 65100 neighbor 169.254.10.1 prefix-list export BGP-HOME
set protocols bgp 65100 neighbor 169.254.10.1 prefix-list import BGP-GCP-VPC# BGP セッションのキープアライブとホールドタイム
set protocols bgp 65100 timers holdtime 60
set protocols bgp 65100 timers keepalive 20# Cloud Router 側の ASN と BGP IP
set protocols bgp 65100 neighbor 169.254.10.1 remote-as 64512
set protocols bgp 65100 neighbor 169.254.10.1 soft-reconfiguration inbound# 自宅のネットワーク
set protocols bgp 65100 network 192.168.1.0/24
上記の設定を ER-X に流し込み commit します。さて Cloud VPN のコンソールを確認してみましょう。うまく行けば、無事「BGP が確立されました」というステータスに変わります。
4.4 VPN トンネル経由で東京リージョンの GCE に接続テスト
さてこれで BGP によって、VPC と自宅ネットワークの経路交換が行われるはずです。さっそく ER-X で経路情報を確認してみましょう。configure から exit で抜けると、netstat など通常のコマンドが実行できます。netstat -nr で確認してみると…？
10.146.0.0/20 の経路が降ってきてる事がわかります。僕の VPC の東京リージョンには接続できそうですね。
おっと、ちょっとまってください、これはあくまで ER-X 上で確認した経路です。このままでは手元の PC からは接続できません。だって手元の PC は ER-X が雲の向こうへつながってることを知らないので、デフォルトゲート（インターネット方面）に抜けちゃいますね。ですので、最後の仕上げとして、自分の PC にその経路を追加してあげる必要があります。
例えば macOS や Windows で先ほどのネットワーク範囲宛の通信を ER-X のトンネルに送るなら、以下のコマンドをそれぞれの OS のターミナルで実行するとできます。ただこれ一時的な設定で macOS や Windowsを再起動すると消えちゃうので気をつけてください。Windows は route -p オプションで永続化できるみたいです。
# macOS のターミナルで、ER-X への静的経路を追加する
sudo route add -net 10.35.32.0/20 192.168.1.250
sudo route add -net 10.146.0.0/20 192.168.1.250# Windows のコマンド プロンプトで、ER-X への静的経路を追加する
route add 10.35.32.0 mask 255.255.240.0 192.168.1.250
route add 10.146.0.0 mask 255.255.240.0 192.168.1.250
すると上記のネットワーク範囲は、ER-X に送られ、ER-X の経路情報で VPN トンネルに送られ、Google Cloud 世界へ送られます。結果、東京リージョンにある GCE に以下のようにプライベート IP での接続に成功しました。
余談ですが、ER-X 自体がデフォルトゲートになってしまえば、各 PC にわざわざ静的経路を入れる必要なく楽ですよね。つまりいっそのこと家のブロードバンド ルーターを ER-X で置き換えるのが一番構成シンプルになります。ちなみにうちでは、最終的に ER-X をインターネット接続にも使うルーターとして使っています。各家庭のネットワーク事情は様々で、完全なリプレイスは容易ではないので、今回は一旦家のネットワークにほぼ手を入れずに ER-X を単に追加でネットワークに設置するという形で紹介しました。
5. 自宅から プライベート IP での Cloud SQL への接続
ここまでくるのに結構かかってしまいましたが、ここからが本当にやりたかったことです。自宅の PC から Cloud SQL につなぎましょう。先ほどの経路情報ですでにお気づきの方もいるかも知れませんが、実は今届いてる経路は、東京リージョンの VPC の default ネットワークのものだけで、Cloud SQL 専用 VPC への経路 10.35.32.0/20 が届いてないようです。
ここで、冒頭で引用した、Cloud SQL が VPN に対応したときのドキュメントの記述を読み返してみましょう。
1. VPC ネットワークが Cloud VPN トンネル、または Dedicated Interconnect か Partner Interconnect の相互接続アタッチメント（VLAN）を使用してオンプレミス ネットワークに接続されていることを確認します。
2. プライベート サービス接続によって生成されるピアリング接続を特定します。
・cloudsql-mysql-googleapis-com
・cloudsql-postgres-googleapis-com
・servicenetworking-googleapis-com3. すべてのピアリング接続を更新して、カスタムルートのエクスポートを有効にします。
4. プライベート サービス接続に使用される割り振り範囲を特定します。
5. Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）の BGP セッションを管理する Cloud Router の割り振り範囲用に Cloud Router のカスタムルート アドバタイズを作成します。
よく見るとこの時点でまだ 1. しか完了していないですよね。これから 2~5 の手順をやっていく必要がありますね。
5.1 Cloud SQL の VPC へのカスタムルートのエクスポート
Cloud SQL のピアリングを特定し、カスタムルートのエクスポートを有効にする必要がありそうです。
Google Cloud のコンソールから「VPC ネットワーク ピアリング」を開くと、以下の図の様に、複数のピアリングが見えると思います。
例えば、cloudsql-mysql-googleapis-com は、Cloud SQL for MySQL のインスタンスが起動する VPC です。ここをクリックして詳細を開いてみましょう。詳細画面の上に「編集」の文字があるのでそこをクリックします。ここに「カスタムルートをエクスポートする」というチェックボックスがあるので、ここにチェックを入れて保存します。
これでどうなったのでしょうか？保存後に表示される cloudsql-mysql-googleapis-com の詳細画面から、エクスポート済みのルートというタブを見てみましょう。新たに動的ルートとして 192.168.1.0/24 つまり、自宅ネットワークへの経路が、Cloud SQL の VPC に対してエクスポートされていることがわかります。
これで、Cloud SQL から自宅ネットワークへは通れるようになりました。次は逆、自宅から Cloud SQL までの経路です。
5.2 Cloud Router から自宅へのカスタムルートのエクスポート
手順には、プライベート サービス接続に使用される割り振り範囲を特定しろとかかれてりますが、これはすでに特定済みで 10.35.32.0/20 でしたね。これを使って Cloud Router の割り振り範囲用に Cloud Router のカスタムルート アドバタイズを作成すれば良いようです。
Cloud Router の画面から、今回作った VPN 用のルーターを選択しましょう。
編集をクリックし、アドバタイズされたルートのラジオボタンから「カスタムルートの作成」を選択します。そして「Cloud Router に表示されるすべてのサブネットにアドバタイズする」にチェックを入れます。
その上でカスタム範囲として、プライベート サービス接続の範囲である 10.35.32.0/20 を入力して保存します。
再び ER-X で経路情報を確認してみましょう。すると、無事 10.35.32.0/20 の経路が表示されています。これでようやく Cloud SQL へ接続する準備が整いました。
5.3 プライベート IP だけを持つ Cloud SQL for MySQL に mysql コマンドで接続を試す
さっそく試してみましょう。せっかくなので新しいインスタンスを作成してみましょう。パブリック IP は割り当てず、プライベート IP だけを設定しています。
インスタンスの作成が完了しました。このインスタンスには、プライベート IP アドレスとして 10.35.32.195 が割り当てられたようです。これももちろん 10.35.32.0/20 の範囲になっていますね。プライベート サービス接続機能によって、この機能を利用するマネージド サービスは、プライベート IP の割り当てから、必要に応じて VPC のピアリングまで、これらをよしなに行ってくれるわけです。便利ですね！
さあやっとここまで来ました。自宅の PC から、mysql コマンドで プライベート IP アドレス指定で接続してみましょう。
無事繋がりました！
余談ですが ER-X 上で tcpdump をしてみると、プライベート IP アドレスで通信している様子が見えます。
これで無事自宅の PC とCloud SQL インスタンスが、プライベート IP で直接通信できるようになったわけですね。
5.4 その他の利用例
これを組み合わせて、自宅（オンプレミス環境）のデータベース（MySQL や PostgreSQL）と、Cloud SQL で、プライベート IP を使ったレプリケーションを組むことなんかもできちゃいます。
データベースのレプリケーションについては、MySQL や PostgreSQL ネイティブのものがありますが、それを簡単に設定させてくれる Database Migration Service と呼ばれるサービスが、先日発表されました。
おわりに
おかしい、データベースの話をするはずが、9 割ネットワークの話に・・・。
VPN 越しの DB 接続の話として、今回書きたかったんですが触れてないところとして、Cloud Memorystore との接続（プライベート サービス接続を使っているかいなかで注意がある）や、Cloud Spanner （API に接続するので工夫を加えないと VPN を通らずインターネットからつなぎに行ってしまう）などがあります。これらについてもまた時間を見つけて記載したいと思います。
