目次
はじめに
こんにちは、株式会社エーピーコミュニケーションズの松尾です。
今回はAWS Site-to-Site VPNで複数の拠点とAWSを接続していきます。目的は2つ、「セグメントが重複する複数拠点とAWSのVPN接続が可能か」「セグメントが重複する拠点間で通信が可能か」を検証することです。
既存拠点にVPNを構築したいがセグメント帯は変更できない、という状況に活用できると思います。
各拠点のルータは仮想ルータ機能を持つVYOSを使っていきます。
図解するとこんなイメージです。 各拠点は192.168.0.0/20で重複しているが、AWSとVPN接続をしたい、形です。VPNはClient VPNではなくSite-to-Site VPNです。
- ステップ1：本社～AWSの接続（ステップ1の記事はこちら）
- ステップ2：大阪支店～AWSの接続（本記事）
- ステップ3：福岡支店～AWSの接続
本記事はステップ2です。 拠点内のセグメントが重複している状態の「大阪支店」を構築して「本社」と疎通できることを確認していきます。
検証構成
ステップ2は次のような流れで構築していきます。
- ステップ1と同様の手順で「大阪支店」の環境を構築
- 「大阪支店」～「クラウド共有サーバ」間が疎通可能であることを確認
- 「大阪支店」～「本社」間が疎通可能であることを確認
ステップ2後の構成図です。想定外でしたが「本社」のVYOSルータの設定変更とhonsya-nasを追加しています。
「大阪支店」の構築
ステップ1の「本社」と同様なため詳細手順はは割愛していきます。 ポイントとしては「本社」と同じセグメント（192.168.0.0/20）のサブネットを作成することぐらい。
カスタマーゲートウェイ
osaka-vyosとosaka-pcを構築したら、「大阪支店」用のカスタマーゲートウェイを作成していきます。
ASNは「クラウド共有サーバ」や「本社」とも異なる値、今回は65002に設定することがポイント。ASNが異なることでルート情報が交換されるためです。
Site-to-Site VPN
カスタマーゲートウェイは「大阪支店」用に作成したものを指定。
Site-to-Site VPNの設定をダウンロードしてosaka-vyosへ設定していきます。 コンフィグレーションの変更箇所は以下。
- 変更前
set vpn ipsec site-to-site peer <Tunnel用IP1> local-address '54.XXX.XXX.XXX' set vpn ipsec site-to-site peer <Tunnel用IP2> local-address '54.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.16.0/20
NAT用の設定も追加していきます。
- BGP広報ルートの追加設定
set protocols static route 172.16.16.0/20 next-hop 192.168.12.175
- 送信元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.16.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.16.0/20'
commitとsave後、BGPステータスをshow ip bgp summaryで確認してみます。
続いてマネコン上でもステータスを確認。
次はルートが正しいことを確認していきます。「クラウド共有サーバ」のVPCで「大阪支店」から広報されたルートが見えていることを確認します。
セキュリティグループの編集
osaka-pcとosaka-vyosのセキュリティグループを修正していきます。
まずはosaka-pc。他の拠点全てのNAT後セグメント（172.16.0.0/16）を許可します。
osaka-vyosは、自拠点の実アドレス（192.168.0.0/20）と他の拠点全てのNAT後セグメント（172.16.0.0/16）を許可しておきます。
「本社」と疎通できない
この状態でosaka-pcからhonsya-pcへ疎通確認してみると、、、疎通出来ません。
切り分けした結果としては、「本社」のVYOSルータのNATが設定不足でした。ステップ1でsourceNATは設定してあるのですが、「大阪支店」からのトラフィックへはdestinationNATの設定が必要だったことが原因です。
色々試した結果、追加する設定は次のとおりでした。
設定としては、200.0.0.1のIPで外部からの通信を待ち受け、192.168.13.104に変換する設定です。インスタンスを新たに構築してプライベートIPが192.168.13.104であることを確認しています。200.0.0.1のIPアドレスは特に意味はないのですが、本来ならプライベートIPアドレスの範囲から割り当てるのが良いですね。
・honsya-vyosへの追加NAT設定
set interfaces loopback lo address 200.0.0.1/24 set protocols bgp 65001 network 200.0.0.1/24 set nat destination rule 90 inbound-interface vti0 set nat destination rule 90 destination address '200.0.0.1' set nat destination rule 90 translation address '192.168.13.104' set nat source rule 90 outbound-interface vti0 set nat source rule 90 source address '192.168.13.104' set nat source rule 90 translation address '200.0.0.1' set nat destination rule 80 inbound-interface vti1 set nat destination rule 80 destination address '200.0.0.1' set nat destination rule 80 translation address '192.168.13.104' set nat source rule 80 outbound-interface vti1 set nat source rule 80 source address '192.168.13.104' set nat source rule 80 translation address '200.0.0.1'
1行目で200.0.0.1をVYOSで指定。他拠点からみた宛先IPになる。
2行目で200.0.0.0/24を広報。
3行目以降でsourceNATとdestinationNATを組み合わせることで双方向NATを実現。VPNインターフェースのvti0とvti1それぞれを指定したNAT設定。
「クラウド共有サーバ」のルートテーブルで200.0.0.0/24が見えることを確認しておきます。
改めて疎通確認
「大阪支店」～「クラウド共有サーバ」
[ec2-user@ip-192-168-9-108 ~]$ [ec2-user@ip-192-168-9-108 ~]$ 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=149 ms 64 bytes from 10.0.1.112: icmp_seq=2 ttl=126 time=148 ms 64 bytes from 10.0.1.112: icmp_seq=3 ttl=126 time=148 ms 64 bytes from 10.0.1.112: icmp_seq=4 ttl=126 time=148 ms 64 bytes from 10.0.1.112: icmp_seq=5 ttl=126 time=148 ms ^C --- 10.0.1.112 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 147.702/148.271/149.007/0.462 ms [ec2-user@ip-192-168-9-108 ~]$
「大阪支店」～「本社」
・osaka-pcからhonsya-nasのNAT用IPへPING
[ec2-user@ip-192-168-9-108 ~]$ 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=290 ms 64 bytes from 200.0.0.1: icmp_seq=2 ttl=125 time=290 ms 64 bytes from 200.0.0.1: icmp_seq=3 ttl=125 time=290 ms 64 bytes from 200.0.0.1: icmp_seq=4 ttl=125 time=289 ms 64 bytes from 200.0.0.1: icmp_seq=5 ttl=125 time=290 ms ^C --- 200.0.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 289.434/289.848/290.293/0.274 ms [ec2-user@ip-192-168-9-108 ~]$
・osaka-vyos
vyatta@vyatta:~$ show nat source translations Pre-NAT Post-NAT Prot Timeout 192.168.9.108 172.16.25.108 icmp 27 vyatta@vyatta:~$
・honsya-vyos
vyatta@vyatta:~$ show nat destination translations Pre-NAT Post-NAT Prot Timeout 200.0.0.1 192.168.13.104 icmp 25 vyatta@vyatta:~$ show nat source translations Pre-NAT Post-NAT Prot Timeout 172.16.25.108 172.16.25.108 icmp 22 vyatta@vyatta:~$
・honsya-nas
[root@ip-192-168-13-104 ~]# tcpdump -i enX0 icmp dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enX0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 06:35:10.155598 IP ip-172-16-25-108.ec2.internal > ip-192-168-13-104.ec2.internal: ICMP echo request, id 8, seq 1, length 64 06:35:10.155624 IP ip-192-168-13-104.ec2.internal > ip-172-16-25-108.ec2.internal: ICMP echo reply, id 8, seq 1, length 64 06:35:11.157273 IP ip-172-16-25-108.ec2.internal > ip-192-168-13-104.ec2.internal: ICMP echo request, id 8, seq 2, length 64 06:35:11.157299 IP ip-192-168-13-104.ec2.internal > ip-172-16-25-108.ec2.internal: ICMP echo reply, id 8, seq 2, length 64 06:35:12.158658 IP ip-172-16-25-108.ec2.internal > ip-192-168-13-104.ec2.internal: ICMP echo request, id 8, seq 3, length 64 06:35:12.158685 IP ip-192-168-13-104.ec2.internal > ip-172-16-25-108.ec2.internal: ICMP echo reply, id 8, seq 3, length 64 06:35:13.160674 IP ip-172-16-25-108.ec2.internal > ip-192-168-13-104.ec2.internal: ICMP echo request, id 8, seq 4, length 64 06:35:13.160699 IP ip-192-168-13-104.ec2.internal > ip-172-16-25-108.ec2.internal: ICMP echo reply, id 8, seq 4, length 64 06:35:14.162078 IP ip-172-16-25-108.ec2.internal > ip-192-168-13-104.ec2.internal: ICMP echo request, id 8, seq 5, length 64 06:35:14.162103 IP ip-192-168-13-104.ec2.internal > ip-172-16-25-108.ec2.internal: ICMP echo reply, id 8, seq 5, length 64 ^C 10 packets captured 11 packets received by filter 0 packets dropped by kernel [root@ip-192-168-13-104 ~]#
ちなみに、「本社」のVYOS設定を変えてしまったので、ステップ1の「本社」と「クラウド共有サーバ」間の疎通状態も改めて確認しておきましたが、正常に通信できています。
[root@ip-192-168-8-158 ~]# 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=144 ms 64 bytes from 10.0.1.112: icmp_seq=2 ttl=126 time=144 ms 64 bytes from 10.0.1.112: icmp_seq=3 ttl=126 time=144 ms 64 bytes from 10.0.1.112: icmp_seq=4 ttl=126 time=144 ms 64 bytes from 10.0.1.112: icmp_seq=5 ttl=126 time=144 ms ^C --- 10.0.1.112 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 143.632/143.815/144.248/0.220 ms [root@ip-192-168-8-158 ~]#
まとめ
AWSリソースレベルは想定通りの設定で問題無かったです。
BGPとしても意図した経路が広報されていて、こちらも想定通りでした。
問題はNATで、「大阪支店」から「本社」への通信は、「本社」VYOSルータに双方向NATが必要だったことに気が付きませんでした。双方向NAT用のサーバとして、honsya-nasを追加で構築して、honsya-nasの実IPアドレスに対して双方向NATを設定する、という形で実装しています。
ステップ2までとしては、やりたいことは実現出来ていますが、ルータのNAT設定が肝要な構成であることを改めて認識した検証でした。
おわりに
私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
