1. はじめに
- AWSのネットワーク関連の復習をしている。AWSと外部(オンプレミスなど)を接続した際のお互いの名前解決の方法について確認したかったため、実機での設定を行い基本的な仕組みを理解する。
2. やったこと
- AWS VPCとGCP VPCネットワークがVPNで接続されている環境を用いる。(環境の構築記事: 【初心者】AWS Site-to-Site VPN を使ってみる (GCPとのVPN接続))
- GCP内のインスタンスから、Route 53 Resolver(インバウンドエンドポイント)を用いて、AWS側VPC内の名前解決を行う。
- AWS内のインスタンスから、Route 53 Resolver(アウトバウンドエンドポイント)を用いて、GCP側VPCネットワーク内の名前解決を行う。
3. Route 53 Resolver インバウンド/アウトバウンドエンドポイントとは(自分の理解)
- そもそも Route 53 Resolver とは、VPCを作成すると必ず付属するリゾルバ機能で、x.x.x.2とかのIPアドレス指定で、インスタンスで自動的に使えるように設定されているもの。
- Route 53 Resolver(インバウンドエンドポイント)は、AWS VPCの外部(ダイレクトコネクトやVPNで接続されているオンプレミスやGCPなど)から、VPC内のRoute 53 Resolverを使用して、VPC内の名前解決を可能にするためのエンドポイント。
- Route 53 Resolver(アウトバウンドエンドポイント)は、AWS VPCの内部から、Route 53 Resolverを経由して、インターネット以外の外部(オンプレミスやGCPなど)の名前解決を可能にするためのエンドポイント。
4. 構成図(自分の理解)
5. 手順
5.1 事前準備
サブネットの追加
- 以前の検証で構築した、AWSとGCPがVPN接続されている環境を用いる。(環境の構築記事: 【初心者】AWS Site-to-Site VPN を使ってみる (GCPとのVPN接続))
- 上記の環境ではAWS側のパブリックサブネットが10.0.0.0/24の1個しかなかったが、Route 53 Resolverのインバウンド/アウトバウンドエンドポイントを作成する際、2つのAZが必要になるため、パブリックサブネット 10.0.1.0/24 を別AZで追加する。
プライベートホストゾーンの作成
- Route 53 Resolverの検証上は必須ではないが、利用イメージをわかりやすくするため、プライベートホストゾーン(mksamba-aws.local)を作成し、VPCに紐づける。
- instance.mksamba-aws.local のIPアドレス(10.0.0.27)をAレコードで登録する。
- AWS VPC内のインスタンスにて、instance.mksamba-aws.local が名前解決できることを確認する。
[ec2-user@ip-10-0-0-27 ~]$ nslookup instance.mksamba-aws.local
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: instance.mksamba-aws.local
Address: 10.0.0.27
5.2 インバウンドエンドポイント
インバウンドエンドポイントの作成
- VPC内の2つのサブネット(別々のAZに存在)を指定して、インバウンドエンドポイントを作成する。
- 10.0.0.43, 10.0.1.173 がインバウンドエンドポイントとして作成される。
インバウンドエンドポイントを利用した外部からの名前解決
- VPN接続されたGCP内のインスタンスから、インバウンドエンドポイントを利用してAWS側VPC内の名前解決を行う。
- GCP内のインスタンスにて、インバウンドエンドポイント(10.0.0.43)をDNSサーバとして指定して、instance.mksamba-aws.localの名前解決ができることを確認する。
[mksamba_gcp@instance3 ~]$ ping 10.0.0.43
PING 10.0.0.43 (10.0.0.43) 56(84) bytes of data.
64 bytes from 10.0.0.43: icmp_seq=1 ttl=253 time=9.09 ms
64 bytes from 10.0.0.43: icmp_seq=2 ttl=253 time=7.47 ms
^C
[mksamba_gcp@instance3 ~]$ nslookup instance.mksamba-aws.local
Server: 169.254.169.254
Address: 169.254.169.254#53
** server can't find instance.mksamba-aws.local: NXDOMAIN
[mksamba_gcp@instance3 ~]$ nslookup instance.mksamba-aws.local 10.0.0.43
Server: 10.0.0.43
Address: 10.0.0.43#53
Non-authoritative answer:
Name: instance.mksamba-aws.local
Address: 10.0.0.27
5.3 アウトバウンドエンドポイント
事前準備
-
GCP内インスタンスにDNSサーバ(bind)を構築し、instance.mksamba-gcp.local のIPアドレス(10.1.0.3)をAレコードとして登録する。手順は省略するが、以下のようなサイトを参照。
-
GCP内インスタンス(bindを立てたインスタンス)で、自分自身(10.1.0.3)をDNSサーバとして指定して、instance.mksamba-gcp.local の名前解決が可能なことを確認する。
[mksamba_gcp@instance3 etc]$ nslookup instance.mksamba-gcp.local 10.1.0.3
Server: 10.1.0.3
Address: 10.1.0.3#53
Name: instance.mksamba-gcp.local
Address: 10.1.0.3
- AWS内インスタンスからも、DNSサーバとして10.1.0.3を直接指定すれば、instance.mksamba-gcp.localの名前解決が可能なことを確認する。
[ec2-user@ip-10-0-0-27 ~]$ nslookup instance.mksamba-gcp.local 10.1.0.3
Server: 10.1.0.3
Address: 10.1.0.3#53
Name: instance.mksamba-gcp.local
Address: 10.1.0.3
アウトバウンドエンドポイントの作成
- VPC内の2つのサブネット(別々のAZに存在)を指定して、アウトバウンドエンドポイントを作成する。
- DNSのクエリが「mksamba-gcp.local」ドメインだった場合、GCP側のDNSサーバ(10.1.0.3)にフォワードするようにルールを設定する。
- 10.0.0.241、10.0.1.41がアウトバウンドエンドポイントとして作成される。
アウトバウンドエンドポイントを利用した外部ドメインの名前解決
- AWS内インスタンスから、VPC付属のRoute 53 Resolver (10.0.0.2)を使用して、GCP側のドメインであるinstance.mksamba-gcp.localが名前解決できることを確認する。
[ec2-user@ip-10-0-0-27 ~]$ nslookup instance.mksamba-gcp.local 10.0.0.2
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: instance.mksamba-gcp.local
Address: 10.1.0.3
- アウトバウンドエンドポイントは、インバウンドエンドポイントと違って、アウトバウンドエンドポイントのIPアドレスを指定してもDNSクエリに応答してくれるわけではない。
6. 所感
- 検証環境を作るために、久しぶりにbindの設定をしたりして、DNSに関する全体的な復習になった。