はじめに
異なるリージョン内にある2つのVCNをDRGを用いて接続し（リモート・ピアリング）、VCN間で相互に名前解決を行うための手順を備忘録的に記します。
こちらの図のように、Tokyoリージョンに「VCNTokyo1（10.1.0.0/16）」、Osakaリージョンに「VCNOsaka1（10.3.0.0/16）」という2つのVCNがある想定です。
1.動的ルーティング・ゲートウェイ（DRG）の作成
動的ルーティング・ゲートウェイを作成し、VCNにアタッチします。
まず、Tokyoリージョンに動的ルーティング・ゲートウェイを作成します。
コンソールの動的ルーティング・ゲートウェイに移動します。
「動的ルーティング・ゲートウェイの作成」をクリックします。
「名前」に「DRGTokyo」と入力して「動的ルーティング・ゲートウェイの作成」をクリックします。
動的ルーティング・ゲートウェイ「DRGTokyo」が作成されました。
作成した動的ルーティング・ゲートウェイをVCNにアタッチします。
「仮想クラウド・ネットワーク・アタッチメントの作成」をクリックします。
任意の名前を入力し、仮想クラウド・ネットワークとして「VCNTokyo1」を選択して、「仮想クラウド・ネットワーク・アタッチメントの作成」をクリックします。
仮想クラウド・ネットワーク・アタッチメントが作成され、動的ルーティング・ゲートウェイがVCNにアタッチされました。
同様に、Osakaリージョンに動的ルーティング・ゲートウェイ「DRGOsaka」を作成し、VCNOsaka1にアタッチします。
2.リモート・ピアリング接続の作成
リモート・ピアリング接続を構成し、VCNTokyo1とVCNOsaka1を接続します。
まずはTokyoリージョン側にリモート・ピアリング接続を作成します。
動的ルーティング・ゲートウェイ「DRGTokyo」の詳細画面のリソース欄の「リモート・リモート・ピアリング接続アタッチメント」をクリックします。
「リモート・ピアリング接続の作成」をクリックします。
任意の名前を入力し、「リモート・ピアリング接続の作成」をクリックします。
リモート・ピアリング接続アタッチメントが作成されました。
リモート・ピアリング接続名をクリックします。
リモート・ピアリング接続の詳細情報が表示されるので、リモート・ピアリング接続のOCIDをコピーしておきます。
次にOsakaリージョン側にリモート・ピアリング接続を作成します。
動的ルーティング・ゲートウェイ「DRGOsaka」の詳細画面のリソース欄の「リモート・リモート・ピアリング接続アタッチメント」をクリックします。
「リモート・ピアリング接続の作成」をクリックします。
任意の名前を入力し、「リモート・ピアリング接続の作成」をクリックします。
リモート・ピアリング接続アタッチメントが作成されました。
リモート・ピアリング接続名をクリックします。
リモート・ピアリング接続の詳細情報が表示されるので、「接続の確立」をクリックします。
「リージョン」に「ap-tokyo-1」を選択、「リモート・ピアリング接続OCID」に先ほどコピーしておいたDRGTokyo1のリモート・ピアリング接続のOCIDを入力し、「接続の確立」をクリックします。
ピア・ステータスが「新規（ピアリングなし）」から「保留中」に変わります。
数分待つと、ピア・ステータスが「ピアリング済」に変わり、DRGTokyo1とDRGOsaka1の間のリモート・ピアリング接続が確立されました。
3.ルート表へのルート・ルールの追加
別のVCNへのトラフィックを動的ルーティング・ゲートウェイにルーティングするためのルート・ルールをルート表に追加します。
まずはTokyoリージョンにある「VCNTokyo1」からOsakaリージョンにある「VCNOsaka1」へのトラフィックを「DRGTokyo」にルーティングするためのルート・ルールを「VCNTokyo1」のルート表に追加します。
Tokyoリージョンにある「VCNTokyo1」の詳細画面のリソース欄の「ルート表」をクリックします。
ルート表名をクリックします。
「ルート・ルールの追加」をクリックします。
ターゲット・タイプに「動的ルーティング・ゲートウェイ」を選択、宛先CIDRブロックにVCNOsaka1のCIDR「10.3.0.0/16」を入力し、「ルート・ルールの追加」をクリックします。
VCNOsaka1へのトラフィックをDRGTokyoにルーティングするルート・ルールが追加されました。
同様にOsakaリージョンにある「VCNOsaka1」からTokyoリージョンにある「VCNTokyo1」へのトラフィックを「DRGOSaka」にルーティングするためのルート・ルールを「VCNOsaka1」のルート表に追加します。
Osakaリージョンにある「VCNOsaka1」の詳細画面のリソース欄の「ルート表」をクリックします。
ルート表名をクリックします。
「ルート・ルールの追加」をクリックします。
ターゲット・タイプに「動的ルーティング・ゲートウェイ」を選択、宛先CIDRブロックにVCNTokyo1のCIDR「10.1.0.0/16」を入力し、「ルート・ルールの追加」をクリックします。
VCNTokyo1へのトラフィックをDRGOsakaにルーティングするルート・ルールが追加されました。
4.VCN間のトラフィックを許可するセキュリティ・ルールの追加
別のVCNからの受信トラフィックを許可するセキュリティ・ルールをセキィリティ・リストに追加します。
まず、VCNTokyo1のセキュリティ・リストに、VCNOsaka1からのトラフィックを許可するセキュリティ・ルールを追加します。
VCNTokyo1の詳細画面に移動します。
リソース欄の「セキュリティ・リスト」をクリックします。
セキュリティ・リスト名をクリックします。
セキュリティ・リストの詳細画面が表示されます。
「イングレス・ルールの追加」をクリックします。
今回は、VCNOsaka1（10.3.0.0/16）からVCNTokyo1への全てのネットワークアクセスを許可するルールを追加します。
ソース・タイプとして「CIDR」を選択、ソースCIDRにVCNOsaka1のCIDRである「10.3.0.0/16」を入力します。IPプロトコルとして「すべてのプロトコル」を選択して、「イングレス・ルールの追加」をクリックします。
VCNOsaka1（10.3.0.0/16）からVCNTokyo1への全てのトラフィックを許可するイングレス・ルールが追加されました。
同様に、VCNOsaka1のセキュリティ・リストに、VCNTokyo1からのトラフィックを許可するセキュリティ・ルールを追加します。
VCNOsaka1の詳細画面に移動します。
リソース欄の「セキュリティ・リスト」をクリックします。
セキュリティ・リスト名をクリックします。
セキュリティ・リストの詳細画面が表示されます。
「イングレス・ルールの追加」をクリックします。
今回は、VCNOsaka1（10.3.0.0/16）からVCNTokyo1への全てのネットワークアクセスを許可するルールを追加します。
ソース・タイプとして「CIDR」を選択、ソースCIDRにVCNTokyo1のCIDRである「10.1.0.0/16」を入力します。IPプロトコルとして「すべてのプロトコル」を選択して、「イングレス・ルールの追加」をクリックします。
VCNTokyo1（10.3.0.0/16）からVCNOsaka1への全てのトラフィックを許可するイングレス・ルールが追加されました。
5.VCN間のネットワーク疎通確認
VCNTokyo1内にあるServer1からVCNOsaka1内にあるServer3（10.3.1.100）に対してpingを実行してみます。
[opc@server1 ~]$ ping -c 5 10.3.1.100
PING 10.3.1.100 (10.3.1.100) 56(84) bytes of data.
64 bytes from 10.3.1.100: icmp_seq=1 ttl=62 time=8.77 ms
64 bytes from 10.3.1.100: icmp_seq=2 ttl=62 time=8.63 ms
64 bytes from 10.3.1.100: icmp_seq=3 ttl=62 time=8.70 ms
64 bytes from 10.3.1.100: icmp_seq=4 ttl=62 time=8.73 ms
64 bytes from 10.3.1.100: icmp_seq=5 ttl=62 time=8.76 ms
--- 10.3.1.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 8.636/8.723/8.771/0.077 ms
[opc@server1 ~]$
VCNOsaka1内にあるServer3からVCNTokyo1内にあるServer1（10.1.1.100）に対してpingを実行してみます。
[opc@server3 ~]$ ping -c 5 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=62 time=8.63 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=62 time=8.63 ms
64 bytes from 10.1.1.100: icmp_seq=3 ttl=62 time=8.60 ms
64 bytes from 10.1.1.100: icmp_seq=4 ttl=62 time=8.66 ms
64 bytes from 10.1.1.100: icmp_seq=5 ttl=62 time=8.66 ms
--- 10.1.1.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 8.600/8.639/8.667/0.104 ms
[opc@server3 ~]$
VCNTokyo1とVCNOsaka1の間のネットワーク疎通が確認できました。
VCNTokyo1内にあるServer1のFQDNを確認します。
[opc@server1 ~]$ hostname -A
server1.subnettokyo1.vcntokyo1.oraclevcn.com
[opc@server1 ~]$
VCNOsaka1内にあるServer3のFQDNを確認します。
[opc@server3 ~]$ hostname -A
server3.subnetosaka1.vcnosaka1.oraclevcn.com
[opc@server3 ~]$
Server1からServer3に対してFQDNを使用してpingを実行してみます。
[opc@server1 ~]$ ping -c 5 server3.subnetosaka1.vcnosaka1.oraclevcn.com
ping: server3.subnetosaka1.vcnosaka1.oraclevcn.com: Name or service not known
[opc@server1 ~]$
Server3からServer1に対してFQDNを使用してpingを実行してみます。
[opc@server3 ~]$ ping -c 5 server1.subnettokyo1.vcntokyo1.oraclevcn.com
ping: server1.subnettokyo1.vcntokyo1.oraclevcn.com: Name or service not known
[opc@server3 ~]$
いずれの場合も、別のVCNにあるホストの名前解決ができないため、pingコマンドが失敗しました。
6.プライベートDNSリゾルバのエンドポイントの作成
異なるリージョンにあるVCN間でプライベートDNSの相互参照を行うために、それぞれのVCNにプライベートDNSリゾルバのエンドポイントを作成します。
最初にTokyoリージョン側のプライベートDNSリゾルバのエンドポイント作成します。
VCNTokyo1の詳細画面の「DNSリゾルバ」の名前をクリックします。
プライベートDNSリゾルバの詳細画面が表示されます。
リソース欄の「エンドポイント」をクリックします。
最初にDNSリクエストのリスニング用のエンドポイントを作成します。
「エンドポイントの作成」をクリックします。
任意の名前を入力し、エンドポイントを作成するサブネットとして「SubnetTokyo1」を選択します。
エンドポイント・タイプとして「リスニング」を選択し、リスニングIPアドレスにSubnetTokyo1上のプライベートIPアドレス（ここでは10.1.1.254）を入力して、「エンドポイントの作成」をクリックします。
リスニング用のエンドポイントが作成されました。
次にDNSリクエストの転送用のエンドポイントを作成します。
「エンドポイントの作成」をクリックします。
任意の名前を入力し、エンドポイントを作成するサブネットとして「SubnetTokyo1」を選択します。
エンドポイント・タイプとして「転送」を選択し、転送IPアドレスにSubnetTokyo1上のプライベートIPアドレス（ここでは10.1.1.253）を入力して、「エンドポイントの作成」をクリックします。
転送用のエンドポイントが作成されました。
次にOsakaリージョン側のプライベートDNSリゾルバのエンドポイント作成します。
VCNOsaka1の詳細画面の「DNSリゾルバ」の名前をクリックします。
プライベートDNSリゾルバの詳細画面が表示されます。
リソース欄の「エンドポイント」をクリックします。
最初にDNSリクエストのリスニング用のエンドポイントを作成します。
「エンドポイントの作成」をクリックします。
任意の名前を入力し、エンドポイントを作成するサブネットとして「SubnetOsaka1」を選択します。
エンドポイント・タイプとして「リスニング」を選択し、リスニングIPアドレスにSubnetOsaka1上のプライベートIPアドレス（ここでは10.3.1.254）を入力して、「エンドポイントの作成」をクリックします。
リスニング用のエンドポイントが作成されました。
次にDNSリクエストの転送用のエンドポイントを作成します。
「エンドポイントの作成」をクリックします。
任意の名前を入力し、エンドポイントを作成するサブネットとして「SubnetOsaka1」を選択します。
エンドポイント・タイプとして「転送」を選択し、転送IPアドレスにSubnetOsaka1上のプライベートIPアドレス（ここでは10.3.1.253）を入力して、「エンドポイントの作成」をクリックします。
転送用のエンドポイントが作成されました。
7.プライベートDNSリゾルバへのリクエスト転送ルールの追加
VCN間でDNSリクエストを転送するためのリクエスト転送ルールをプライベートDNSリゾルバに追加します。
FQDNのドメイン名に応じて、DNSリクエストをどの転送エンドポイントを経由してどのリスニングエンドポイントに転送するのかを指定します。
最初にVCNTokyo1内からのVCNOsaka1内のホストに対するDNSリクエストをVCNOsaka1のプライベートDNSに転送するルールを作成します。
VCNTokyo1の詳細画面の「DNSリゾルバ」の名前をクリックします。
プライベートDNSリゾルバの詳細画面が表示されます。
リソース欄の「ルール」をクリックします。
「ルールの管理」をクリックします。
ルール条件として「ドメイン」を選択し、ドメインにVCNOsaka1のドメイン名「vcnosaka1.oraclevcn.com」を入力します。
（ドメイン名入力後にEnterキーを押さないと入力内容が反映されないので注意が必要です。）
ソースエンドポイントとして先ほど作成したVCNTokyo1の転送エンドポイントを選択し、宛先IPアドレスにVCNOsaka1のリスニング用エンドポイントのIPアドレス「10.3.1.254」を入力して「変更の保存」をクリックします。
VCNTokyo1内からのVCNOsaka1内のホストに対するDNSリクエストをVCNOsaka1のプライベートDNSに転送するルールが作成されました。
次にVCNOsaka1内からのVCNTokyo1内のホストに対するDNSリクエストをVCNTokyo1のプライベートDNSに転送するルールを作成します。
VCNOsaka1の詳細画面の「DNSリゾルバ」の名前をクリックします。
プライベートDNSリゾルバの詳細画面が表示されます。
リソース欄の「ルール」をクリックします。
「ルールの管理」をクリックします。
ルール条件として「ドメイン」を選択し、ドメインにVCNTokyo1のドメイン名「vcntokyo1.oraclevcn.com」を入力します。
（ドメイン名入力後にEnterキーを押さないと入力内容が反映されないので注意が必要です。）
ソースエンドポイントとして先ほど作成したVCNOsaka1の転送エンドポイントを選択し、宛先IPアドレスにVCNTokyo1のリスニング用エンドポイントのIPアドレス「10.1.1.254」を入力して「変更の保存」をクリックします。
VCNOsaka1内からのVCNTokyo1内のホストに対するDNSリクエストをVCNTokyo1のプライベートDNSに転送するルールが作成されました。
8.VCN間でのFQDNでのアクセス確認
再度、Server1からServer3（server3.subnetosaka1.vcnosaka1.oraclevcn.com）に対して、FQDNを使用してpingを実行してみます。
[opc@server1 ~]$ ping -c 5 server3.subnetosaka1.vcnosaka1.oraclevcn.com
PING server3.subnetosaka1.vcnosaka1.oraclevcn.com (10.3.1.100) 56(84) bytes of data.
64 bytes from 10.3.1.100 (10.3.1.100): icmp_seq=1 ttl=62 time=8.94 ms
64 bytes from 10.3.1.100 (10.3.1.100): icmp_seq=2 ttl=62 time=9.03 ms
64 bytes from 10.3.1.100 (10.3.1.100): icmp_seq=3 ttl=62 time=8.96 ms
64 bytes from 10.3.1.100 (10.3.1.100): icmp_seq=4 ttl=62 time=8.97 ms
64 bytes from 10.3.1.100 (10.3.1.100): icmp_seq=5 ttl=62 time=9.00 ms
--- server3.subnetosaka1.vcnosaka1.oraclevcn.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 8.942/8.984/9.031/0.031 ms
[opc@server1 ~]$
TokyoリージョンにあるVCNTokyo1内のインスタンスから、OsakaリージョンにあるVCNOsaka1内のインスタンスに、ホスト名（FQDN）を使用してアクセスできました。
Server3からServer1（server1.subnettokyo1.vcntokyo1.oraclevcn.com）に対してFQDNを使用してpingを実行してみます。
[opc@server3 ~]$ ping -c 5 server1.subnettokyo1.vcntokyo1.oraclevcn.com
PING server1.subnettokyo1.vcntokyo1.oraclevcn.com (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100 (10.1.1.100): icmp_seq=1 ttl=62 time=8.61 ms
64 bytes from 10.1.1.100 (10.1.1.100): icmp_seq=2 ttl=62 time=8.63 ms
64 bytes from 10.1.1.100 (10.1.1.100): icmp_seq=3 ttl=62 time=8.52 ms
64 bytes from 10.1.1.100 (10.1.1.100): icmp_seq=4 ttl=62 time=8.63 ms
64 bytes from 10.1.1.100 (10.1.1.100): icmp_seq=5 ttl=62 time=8.58 ms
--- server1.subnettokyo1.vcntokyo1.oraclevcn.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 8.525/8.597/8.634/0.124 ms
[opc@server3 ~]$
OsakaリージョンにあるVCNOsaka1内のインスタンスから、TokyoリージョンにあるVCNTokyo1内のインスタンスに、ホスト名（FQDN）を使用してアクセスできました。