セグメントが重複する拠点をAWS Site-to-Site VPNで接続する(step3)

はじめに

こんにちは、株式会社エーピーコミュニケーションズの松尾です。
本記事は、同じセグメントを持つ複数拠点間のVPN接続を検証していくシリーズ第3回目です。

具体的には、拠点のIPアドレス帯が192.168.0.0/20で重複している状況で、AWSとのVPN接続を経由して拠点間の通信状況を確認していきます。VPNはClient VPNではなくSite-to-Site VPNです。

ステップ1：本社～AWSの接続（ステップ1の記事はこちら）
ステップ2：大阪支店～AWSの接続（ステップ2の記事はこちら）
ステップ3：福岡支店～AWSの接続（本記事）

本記事はステップ3です。拠点内のセグメントが重複している状態の「福岡支店」を構築して「本社」と疎通できること、「大阪支店」と通信できないことを確認していきます。

検証構成

ステップ3は次のような流れで構築していきます。

ステップ1と同様の手順で「福岡支店」の環境を構築
「福岡支店」～「クラウド共有サーバ」間が疎通可能であることを確認
「福岡支店」～「本社」間が疎通可能であることを確認
「福岡支店」～「大阪支店」間が疎通不可能であることを確認

ステップ3後の構成図です。※諸事情によりステップ2から大阪支店内のインスタンスIPと、本社のnasのIPが変わっています。

「福岡支店」の構築

ステップ1の「本社」と同様なため詳細手順はは割愛していきます。ポイントとしては「本社」と同じセグメント（192.168.0.0/20）のサブネットを作成することぐらい。

カスタマーゲートウェイ

fukuoka-vyosとfukuoka-pcを構築したら、「福岡支店」用のカスタマーゲートウェイを作成していきます。 ASNは「クラウド共有サーバ」や「本社」とも異なる値、今回は65002に設定することがポイント。ASNが異なることでルート情報が交換されるためです。ここまでのASNを整理すると、

「クラウド共有サーバ」：ASN65000
「本社」：ASN65001
「大阪支店」：ASN65002
「福岡支店」：ASN65002

となり、大阪支店と福岡支店のみがASNが同一のため、プライベートゲートウェイのBGPでルートが交換されなくなるはずです。

Site-to-Site VPN

カスタマーゲートウェイは「福岡支店」用に作成したものを指定。

Site-to-Site VPNの設定をダウンロードしてfukuoka-vyosへ設定していきます。コンフィグレーションの変更箇所は以下。

変更前

set vpn ipsec site-to-site peer <Tunnel用IP1> local-address '34.XXX.XXX.XXX'
set vpn ipsec site-to-site peer <Tunnel用IP2> local-address '34.XXX.XXX.XXX'

set protocols bgp 65002 network 0.0.0.0/0

変更後

set vpn ipsec site-to-site peer <Tunnel用IP1> local-address '<仮想ルータのプライベートIPアドレス>'
set vpn ipsec site-to-site peer <Tunnel用IP2> local-address '<仮想ルータのプライベートIPアドレス>'

set protocols bgp 65002 network 172.16.32.0/20

NAT用の設定も追加していきます。

BGP広報ルートの追加設定

set protocols static route 172.16.32.0/20 next-hop 192.168.14.208

送信元NAT設定

set nat source rule 100 outbound-interface vti0
set nat source rule 100 source address '192.168.0.0/20'
set nat source rule 100 translation address '172.16.32.0/20'

set nat source rule 200 outbound-interface vti1
set nat source rule 200 source address '192.168.0.0/20'
set nat source rule 200 translation address '172.16.32.0/20'

commitとsave後、BGPステータスをshow ip bgp summaryで確認してみます。続いてマネコン上でもステータスを確認。

次はルートが正しいことを確認していきます。「クラウド共有サーバ」のVPCで「福岡支店」から広報されたルートが見えていることを確認します。

セキュリティグループの編集

fukuoka-pcとfukuoka-vyosのセキュリティグループを修正していきます。
まずはfukuoka-pc。他の拠点全てのNAT後セグメント（172.16.0.0/16）を許可します。

fukuoka-vyosは、自拠点の実アドレス（192.168.0.0/20）と他の拠点全てのNAT後セグメント（172.16.0.0/16）を許可しておきます。

ルートテーブルの編集

「福岡支店」のサブネットに紐づいているルートテーブルは手動で更新する必要があるので修正していきます。

「本社」のサブネットに紐づいているルートテーブルも手動で更新する必要があるので修正していきます。

疎通確認

「福岡支店」～「クラウド共有サーバ」

[ec2-user@ip-192-168-12-7 ~]$ ping 10.0.1.112
PING 10.0.1.112 (10.0.1.112) 56(84) bytes of data.
64 bytes from 10.0.1.112: icmp_seq=1 ttl=126 time=157 ms
64 bytes from 10.0.1.112: icmp_seq=2 ttl=126 time=156 ms
64 bytes from 10.0.1.112: icmp_seq=3 ttl=126 time=155 ms
64 bytes from 10.0.1.112: icmp_seq=4 ttl=126 time=156 ms
64 bytes from 10.0.1.112: icmp_seq=5 ttl=126 time=155 ms
^C
--- 10.0.1.112 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 155.343/156.009/157.438/0.751 ms
[ec2-user@ip-192-168-12-7 ~]$

「福岡支店」～「本社」

・fukuoka-pcからhonsya-nasのNAT用IPへPING

[ec2-user@ip-192-168-6-103 ~]$ ping 200.0.0.1
PING 200.0.0.1 (200.0.0.1) 56(84) bytes of data.
64 bytes from 200.0.0.1: icmp_seq=1 ttl=125 time=299 ms
64 bytes from 200.0.0.1: icmp_seq=2 ttl=125 time=304 ms
64 bytes from 200.0.0.1: icmp_seq=3 ttl=125 time=300 ms
64 bytes from 200.0.0.1: icmp_seq=4 ttl=125 time=299 ms
64 bytes from 200.0.0.1: icmp_seq=5 ttl=125 time=299 ms
^C
--- 200.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 298.963/300.136/303.746/1.814 ms
[ec2-user@ip-192-168-6-103 ~]$

VPN間のルートテーブルを見てみる

それぞれのルートを確認してみましょう。

福岡支店のBGPルート

vyatta@vyatta:~$ show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

B>* 10.0.0.0/16 [20/100] via 169.254.47.149, vti0, 00:56:31
B>* 172.16.0.0/20 [20/100] via 169.254.47.149, vti0, 00:18:31
B>* 200.0.0.0/24 [20/100] via 169.254.47.149, vti0, 00:18:31
vyatta@vyatta:~$

クラウド共有サーバ（10.0.0.0/16）、本社（200.0.0.0/24、172.16.0.0/20）へのルートだけが見えています。大阪支店（172.16.16.0/20）へのルートはありません。

大阪支店のBGPルート

vyatta@vyatta:~$ show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

B>* 10.0.0.0/16 [20/100] via 169.254.106.13, vti0, 01:10:52
B>* 172.16.0.0/20 [20/100] via 169.254.106.13, vti0, 00:20:51
B>* 200.0.0.0/24 [20/100] via 169.254.106.13, vti0, 00:20:51
vyatta@vyatta:~$

クラウド共有サーバ（10.0.0.0/16）、本社（200.0.0.0/24、172.16.0.0/20）へのルートだけが見えています。福岡支店（172.16.32.0/20）へのルートはありません。

本社のBGPルート

vyatta@vyatta:~$ show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

B>* 10.0.0.0/16 [20/100] via 169.254.191.37, vti0, 00:24:38
B>* 172.16.16.0/20 [20/100] via 169.254.191.37, vti0, 00:24:38
B>* 172.16.32.0/20 [20/100] via 169.254.191.37, vti0, 00:24:38
vyatta@vyatta:~$

クラウド共有サーバ（10.0.0.0/16）、福岡支店（172.16.32.0/20）、大阪支店（172.16.16.0/20）のルートが見えています。

クラウド共有サーバのBGPルート

プライベートゲートウェイは内部のルートは見ることが出来ないので、サブネットのルートテーブルを見ていきます。

クラウド共有サーバ（10.0.0.0/16）はローカルとして認識、本社（200.0.0.0/24、172.16.0.0/20）、福岡支店（172.16.32.0/20）、大阪支店（172.16.16.0/20）へのルートが見えていることが分かります。

つまり、プライベートゲートウェイ側では全てのカスタマーゲートウェイからのルートがあるものの、カスタマーゲートウェイのASNが同一の場合は通信が出来ないようになっていることが分かります。

まとめ

ルータをシュミレートできるVYOSを活用して検証してみました。VYOSの操作を知る必要はあるもののサイト間VPNの動作確認を全てAWS上で完結できる点は大きなメリットでした。
サブネットのルートテーブルと、VYOSのルートテーブル、両方を漏れなく設定、確認していく必要がありますが、サイト間VPNでのルーティングは理解が深まったと思います。
本来は拠点ごとに異なるセグメントになるよう設計するのが正しいですが、やむを得ず接続する必要がある場合には参考にしていただければと思います。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！ご興味持っていただけましたらぜひお声がけください。

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。