5
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Google Cloud DNS の「DNS転送」を使って GCP 外のネームサーバに DNS クエリを転送する

Last updated at Posted at 2019-10-16

#はじめに

AWS - GCP 間を VPN で繋ぎ、マルチクラウドで色々なアプリケーションを運用していくと、どうしても避けて通れなくなるのが「名前解決」の問題です。

例えば、AWS 側にプライベートドメインを管理するネームサーバを置いている場合、GCP からもそのドメインに所属するサーバについてホスト名(FQDN)でアクセスさせたい場面もあるかと思います。
まだ稼働しているサービスが少ない場合は力業で対応することもできますが、数が多くなってくると徐々にフォローできなくなり破綻してしまいます。

2019年の初頭、Google Cloud DNS の新しい機能「DNS 転送」が発表されました(投稿時点ではまだベータ版)ので、それを使ってこの問題を解決してみます。

構成

以前投稿した「AWSとGCP間をVPN接続してみた」をベース構成とします。
(AWS-GCP間が Cloud VPN で接続され、BGP によってルートテーブルを相互にアドバタイズしている)

また本投稿では DNS サーバは AWS EC2 上の AD サーバ 2台(10.2.0.101、10.2.0.102)により、プライベートドメイン example.local の名前解決ができる環境を想定しています。(下図参照)

以上の構成で GCP 側にある GCE VM インスタンスや GKE 上の Pod から送信された example.local 宛の DNS リクエストクエリを、dc1.example.local(または dc2.example.local)にゾーン転送し、名前解決できるように実装することを目標とします。

Topology.png

実装

Cloud DNS に 転送ゾーンを登録

Cloud DNS に転送ゾーンを登録するには gcloud beta dns managed-zones create コマンドを実行します。
ポイントは --visibilityprivate を指定すること(限定公開ゾーンといいます。限定公開ゾーンでなければ転送ゾーンを作成できません)、--forwarding-targets に DNS リスエストクエリの転送先となる DNS サーバの IP アドレス を指定することです。

gcloud beta dns managed-zones create private-example-zone \
    --dns-name="example.local" \
    --description="Private example zone forwarding" \
    --visibility="private" \
    --networks="test-vpc" \
    --forwarding-targets="10.2.0.101,10.2.0.102"

Cloud Router にカスタムルート アドバタイズを追加

公式の「転送ゾーンの作成」には、要件として次の記載があります。

ネームサーバーに適用されるオンプレミス ネットワークのファイアウォール ルールで、35.199.192.0/19 からのパケットを許可します。
(中略)
VPC ネットワーク内の GCP VM から送信されたすべてのクエリは、35.199.192.0/19 でプロキシされます。

つまり GCE 内から送信された DNS リクエストクエリが Cloud DNS の転送ゾーンと一致した場合、35.199.192.0/19 が GCP VMインスタンスの代理で、オンプレミスネームサーバにリクエストクエリパケットを転送するようです。

最初にこの記載を見たとき、「んん? 35.199.192.0/19 に属する DNS Proxy が、インターネットを介して転送先DNSサーバにリクエストクエリを送信するのか?」と思い込んでいましたが(どう見てもグローバル IP アドレスなので)、どうやらそうでは無いようです。

よくよく見ると要件の中ほどには、次のような記載がありました。

VPC ネットワークからの DNS クエリに対する応答は 35.199.192.0/19 に返す必要がありますが、インターネット経由で送信することはできません。静的ルーティングを使用する Cloud VPN トンネルの場合は、オンプレミス ネットワーク内に、宛先が 35.199.192.0/19 でネクストホップが VPN トンネルのルートを手動で作成する必要があります。

つまり、35.199.192.0/19 に属する DNS Proxy と転送先DNSサーバ(今回はAWS EC2 側)間の通信は、Cloud VPN のトンネル内を通せば良い、ということです。

今回の構成では AWS - GCP 間のルーティングは BGP を利用しているので、GCP から AWS に対し 35.199.192.0/19 のルートを、 Cloud Router からアドバタイズすることにします。

次のコマンドで Cloud Router にカスタムルート アドバタイズを追加します。

gcloud compute routers update vpn-router \
    --advertisement-mode custom \
    --set-advertisement-groups all_subnets \
    --set-advertisement-ranges 35.199.192.0/19

ポイントは、--advertisement-modecustom を指定すること(しないと、カスタムルートを追加することができません)、--set-advertisement-groups all_subnets オプションを追加すること(Cloud Router にアタッチされている VPC に属するサブネットへのルートもアドバタイズ)です。

転送先 DNS サーバのファイアウォールルールを変更

リクエストクエリの転送先となる(AWS EC2上の)AD サーバのセキュリティポリシーに対し、送信元 IP アドレス 35.199.192.0/19、UDP 53 番ポートを許可するよう設定を変更します。(方法は割愛します)

確認

GCE上の VM インスタンスや GKE 上の Pod から、xxx.example.local の名前解決ができるか確認します。(dignslookupping 等)

5
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?