今回実現したいこと
通常、同一リージョン内のVCN同士であればビューを使って他のVCNのゾーンをまとめて紐づけるとお互いに名前解決ができるようになって便利です。ただし、異なるテナンシに各VCNが存在しているような場合は残念ながらビューを使った関連付けができません。
そのような場合にはDNSクエリをフォワーディングするためのリゾルバ・ルールを設定することでお互いに名前解決ができるようにすることが可能です。
今回は、複数のVCNでフォワーディング設定を行う場合を想定し、Hub & Spoke構成でフォワーディング設定をしていきます。全てのVCNでたすき掛けのようにフォワーディング設定してもいいのですが、数が多かったり、増えたりする場合に対応工数がかさんでしまいます。Hub & Spoke構成にしておけば追加や削除時の変更箇所が最小限で済みます。
以下のようにHubとなるVCN経由で2つのSpoke VCN間で相互にDNS問い合わせがフォワーディングできるように構成を行っていきます。
事前準備
今回は以下の3つのVCNを利用します。
-
VCN名：tk_tokyo_vcn2 ←これをHubにします。
- VCN CIDR：10.2.0.0/16
- DNSドメイン名：tktokyovnc2.oraclevcn.com
-
VCN名：tk_validate_vcn ←これがSpokeになります。
- VCN CIDR：10.0.0.0/16
- DNSドメイン名：tkvalidatevcn.oraclevcn.com
-
VCN名：tk_spoke_vcn ←これがSpokeになります。
-
VCN CIDR：10.3.0.0/16
-
DNSドメイン名：tkspokevcntest.oraclevcn.com
-
すべて同じDRGにアタッチしてDRG経由でのVCNピアリングの設定をしておきます。今回はHub経由の通信とするため、Spoke同士の直接のルートは入れません。
各VCNのパブリック・サブネット、プライベート・サブネットともに、以下のルート・ルールを追加しておきます。
- Hub VCN tk_tokyo_vcn2のルート表に追加するルール
宛先 ターゲットタイプ ターゲット 10.0.0.0/16 動的ルーティングゲートウェイ tk_drg 10.3.0.0/16 動的ルーティングゲートウェイ tk_drg
- 2つのSpoke VCN（tk_validate_vcnとtk_spoketest_vcn）のルート表に追加するルール
宛先 ターゲットタイプ ターゲット 10.2.0.0/16 動的ルーティングゲートウェイ tk_drg
また、全てのVCNのセキュリティ・リストでUDP port 53（DNS問い合わせ）を許可しておきます。
リゾルバ・エンドポイントの作成
各VCNのプライベート・リゾルバでリスニング・エンドポイントと転送エンドポイントをそれぞれ作成します。すべて各VCN内のプライベート・サブネットに配置します。
このようにできあがりました。
-
Hub VCN：tk_tokyo_vcn2
- 転送エンドポイント：tk_vcn_forward 10.2.1.55
- リスニング・エンドポイント：tk_vcn_listen 10.2.1.13
-
Spoke VCN1：tk_validate_vcn
- 転送エンドポイント：vali_forward 10.0.1.78
- リスニング・エンドポイント：vali_listen 10.0.1.242
-
Spoke VCN2：tk_spoke_vcn
- 転送エンドポイント：spokevcn_forward 10.3.1.44
- リスニング・エンドポイント：spokevcn_listen 10.3.1.91
リゾルバ・ルールの作成
続いて、各リゾルバのルールの管理で以下のようにリゾルバ・ルールを作成します。
- Hub VCN側のリゾルバ・ルール1
- ルール条件：ドメイン
- ドメイン：tkvalidatevcn.oraclevcn.com
- ルール・アクション：転送
- ソース・エンドポイント：作成した転送エンドポイントを選択
- 宛先IPアドレス：10.0.1.242
- Hub VCN側のリゾルバ・ルール2
- ルール条件：ドメイン
- ドメイン：tkspoketestvcn.oraclevcn.com
- ルール・アクション：転送
- ソース・エンドポイント：作成した転送エンドポイントを選択
- 宛先IPアドレス：10.3.1.91
作成できるとこのようになります。
Spoke側の2つのリゾルバでは以下のようにoraclevcn.comドメインの名前解決をHubにフォワードします。
- Spoke VCN側のリゾルバ・ルール
- ルール条件：ドメイン
- ドメイン：oraclevcn.com
- ルール・アクション：転送
- ソース・エンドポイント：作成した転送ポイントを指定
- 宛先IPアドレス：10.2.1.13
作成するとこのようになります。
もう一つのSpokeでも同じ設定をします。
各VCN内のインスタンスから名前解決を実施
各VCN内に適当なコンピュート・インスタンスを作成します。今回はパブリック・サブネットにインスタンスを作成しました。
また、各インスタンスの詳細画面から、各インスタンスのFQDNを確認しておきます。
では、さっそく各インスタンスから名前解決を実行してみます。
まずはHub VCN（tk_tokyo_vcn2）から、両方のSpoke VCN内のインスタンスの名前解決ができることを確認します。
[opc@tk-inst3-tokyo:2024-12-05T05:46:08 ~]$dig +noall +ans tk-validate-test.sub04300430330.tkvalidatevcn.oraclevcn.com
tk-validate-test.sub04300430330.tkvalidatevcn.oraclevcn.com. 300 IN A 10.0.0.156
[opc@tk-inst3-tokyo:2024-12-05T05:49:06 ~]$
[opc@tk-inst3-tokyo:2024-12-05T05:49:08 ~]$dig +noall +ans tk-spoke-inst.sub12050321550.tkspokevcntest.oraclevcn.com
tk-spoke-inst.sub12050321550.tkspokevcntest.oraclevcn.com. 105 IN A 10.3.0.210
[opc@tk-inst3-tokyo:2024-12-05T05:49:16 ~]$
反対方向で、各Spoke VCNからHub VCN内のインスタンスの名前解決ができることも確認します。
[opc@tk-validate-test ~]$ dig +noall +ans tk-inst3-tokyo.sub01090522420.tktokyovnc2.oraclevcn.com
tk-inst3-tokyo.sub01090522420.tktokyovnc2.oraclevcn.com. 300 IN A 10.2.0.153
[opc@tk-validate-test ~]$
[opc@tk-spoke-inst ~]$ dig +noall +ans tk-inst3-tokyo.sub01090522420.tktokyovnc2.oraclevcn.com
tk-inst3-tokyo.sub01090522420.tktokyovnc2.oraclevcn.com. 300 IN A 10.2.0.153
[opc@tk-spoke-inst ~]$
続いて、Spoke VCN同士で名前解決ができることを確認します。
[opc@tk-validate-test ~]$ dig +noall +ans tk-spoke-inst.sub12050321550.tkspokevcntest.oraclevcn.com
tk-spoke-inst.sub12050321550.tkspokevcntest.oraclevcn.com. 242 IN A 10.3.0.210
[opc@tk-validate-test ~]$
[opc@tk-spoke-inst ~]$ dig +noall +ans tk-validate-test.sub04300430330.tkvalidatevcn.oraclevcn.com
tk-validate-test.sub04300430330.tkvalidatevcn.oraclevcn.com. 217 IN A 10.0.0.156
[opc@tk-spoke-inst ~]$
全て問題なく名前解決できました！