目次
はじめに
こんにちは、株式会社エーピーコミュニケーションズの松尾です。
今回は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の接続
- ステップ2：大阪支店～AWSの接続
- ステップ3：福岡支店～AWSの接続
本記事はステップ1になります。
検証構成
ステップ1は次のような流れで構築していきます。
- 東京リージョンへ疎通確認用サーバとして「クラウド共有サーバ」を構築
- 北米リージョンに「本社」としてVPCを構築、VYOSと疎通確認用ECを構築
- 「本社」と「クラウド共有サーバ」間でSite-to-Site VPNを接続
ポイントとしては、「本社」の仮想ルータ（VYOS）で送信元NATをかける点です。
「クラウド共有サーバ」の構築
以下の内容でEC2を構築します。
パブリックサブネットにしてあるのはEC2へログインするため。セキュリティグループは3拠点のNAT後アドレスを集約した172.16.0.0/16とNAT前の192.168.0.0/16を設定。192.168.0.0/16は最終的には不要になる設定の見込み。
- 東京リージョン
- VPC：10.0.0.0/16
- パブリックサブネット：10.0.1.0/24
- Amazon Linux
- セキュリティグループ：ICMPで送信元192.16.0.0/16、172.16.0.0/16を許可。SSHログイン用を許可。
「クラウド共有サーバ」はこれでOK。
「本社」の構築
「仮想ルータ」の構築
以下の内容でEC2を構築します。
AMIはマーケットプレイスでVYOSを使っていきます。検索するといくつか出ていきますが、後述するVPN接続用設定がバージョン6.5になっていたため、近いバージョンの6.6であるAMIを選択しています。
セキュリティグループは自拠点内からと他拠点からの通信を許可したいため、192.168.0.0/20（自拠点）、172.16.0.0/16（他拠点のNAT後アドレスの集約セグメント）を許可。
- バージニア北部リージョン
- VPC：192.168.0.0/16
- パブリックサブネット：192.168.0.0/20
- Netspectrum Vyatta v6.6r1-js200904
- セキュリティグループ：ICMPで送信元192.16.0.0/20、172.16.0.0/16を許可。SSHログイン用を許可
「仮想ルータ」を作成後、”送信元/宛先チェック”を無効化します。これにより他インスタンス発信の通信でも「仮想ルータ」を経由して通信することが可能になります。
次にElastic IPを作成し、「仮想ルータ」へ割り当てます。
VPN接続で利用するカスタマーゲートウェイで指定するグローバルIPアドレスを固定したいためです。
これで「仮想ルータ」はOK。
「本社PC」の構築
以下の内容でEC2を構築します。
セキュリティグループは他拠点からの通信を許可したいため、172.16.0.0/16（他拠点のNAT後アドレスの集約セグメント）を許可。他拠点からの通信が発生するのはステップ3からになります。
- バージニア北部リージョン
- VPC：192.168.0.0/16
- パブリックサブネット：192.168.0.0/20
- Amazon Linux
- セキュリティグループ：ICMPで送信元172.16.0.0/16を許可。SSHログイン用を許可
- ルートテーブル：「クラウド共有サーバ」10.0.0.0/16宛てを「仮想ルータ」をNexthopとして設定
「本社PC」はここまででOK。
「クラウド共有サーバ」と「本社」のVPNリソース作成
仮想プライベートゲートウェイ
東京リージョンで仮想プライベートゲートウェイを作成します。
AS番号は65000を設定しておきます。他拠点と重複しなければ他の値でも問題無いです。
作成した仮想プライベートゲートウェイは東京リージョンのVPCへ”アタッチ”しておきます。
カスタマーゲートウェイ
東京リージョンでカスタマーゲートウェイを作成します。
AS番号は仮想プライベートゲートウェイとは異なる”65001”を設定。
IPアドレスは「仮想ルータ」のElastic IPのIPアドレスを設定していきます。
Site-to-Site VPN
東京リージョンでVPN接続を作成します。
仮想プライベートゲートウェイとカスタマーゲートウェイは作成したリソースを設定。
ルーティングオプションは拠点からのルートを動的に受け取りたいので、”動的”にしておきます。
VPN接続用設定
次に「仮想ルータ」にVPN接続用の設定をしていきます。
VPN接続の”設定をダウンロードする”からVYOSの設定ファイルをダウンロードします。
このサンプルファイルのバージョンに近いAMIを選択しました。
ダウンロードしたファイルは一部編集が必要です。以下の部分を修正していきます。
- 変更前
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 vpn ipsec site-to-site peer <Tunnel用IP1> local-address '<仮想ルータのプライベートIPアドレス>' set vpn ipsec site-to-site peer <Tunnel用IP2> local-address '<仮想ルータのプライベートIPアドレス>'
設定ファイルを修正後、「仮想ルータ」へSSHログイン。
今回使用したAMIのユーザ名は”vyatta”です。
VYOSのコマンドは、”configure”と”exit”でモードを切り替えて設定します。
プロンプトが$のモードではステータス確認や再起動系のコマンド、プロンプトが#のモードでは設定の投入が行えるイメージです。
プロンプトが#のモードで設定ファイルの内容をコピー＆ペーストして設定を投入していきます。途中エラーが無いことを確認しながら設定します。
全て投入した後は、”commit"コマンドで投入した設定を反映します。反映後"save"コマンドで設定保存して設定完了です。
伝播ルートの有効化
「クラウド共有サーバ」のサブネットのルートテーブルで”ルート伝播”を有効化していきます。
本社の仮想ルータで設定した192.168.0.0/20のセグメントが動的に、「クラウド共有サーバ」のルートテーブルへ反映されています。
状態確認
ここまでで「本社」と「クラウド共有サーバ」間がVPNで接続出来ているはずです。いくつか状態を確認しておきます。
- VPNのステータス
VPN接続リソースの詳細にトンネルのステータスが確認できます。アップになっていればVPN接続出来ている状態です。
ちなみにアップになる＝VPN接続＝課金となります
「仮想ルータ」ではVPNの状態をIKEとIPSECステータスとして確認可能。BGPのステータスも確認出来ます。（トンネルIPとBGPネイバーIPはマスクしています）見方は割愛。
vyatta@vyatta:~$ show vpn ike sa
Peer ID / IP Local ID / IP
------------ -------------
52.*.*.* 192.168.12.44
Description: VPC tunnel 1
State Encrypt Hash D-H Grp NAT-T A-Time L-Time
----- ------- ---- ------- ----- ------ ------
up aes128 sha1 2 no 3577 28800
Peer ID / IP Local ID / IP
------------ -------------
54.*.*.* 192.168.12.44
Description: VPC tunnel 2
State Encrypt Hash D-H Grp NAT-T A-Time L-Time
----- ------- ---- ------- ----- ------ ------
up aes128 sha1 2 no 3336 28800
vyatta@vyatta:~$
vyatta@vyatta:~$ show vpn ipsec sa
Peer ID / IP Local ID / IP
------------ -------------
52.*.*.* 192.168.12.44
Description: VPC tunnel 1
Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto
------ ----- ------------- ------- ---- ----- ------ ------ -----
vti up 31.9K/28.0K aes128 sha1 no 3243 3600 all
Peer ID / IP Local ID / IP
------------ -------------
54.*.*.* 192.168.12.44
Description: VPC tunnel 2
Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto
------ ----- ------------- ------- ---- ----- ------ ------ -----
vti up 19.2K/31.7K aes128 sha1 no 3568 3600 all
vyatta@vyatta:~$
vyatta@vyatta:~$ show ip bgp summary
BGP router identifier 192.168.12.44, local AS number 65001
IPv4 Unicast - max multipaths: ebgp 1 ibgp 1
RIB entries 3, using 288 bytes of memory
Peers 2, using 9120 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.*.*.* 4 65000 262 266 0 0 0 00:43:17 1
169.*.*.* 4 65000 262 267 0 0 0 00:43:14 1
Total number of neighbors 2
vyatta@vyatta:~$
vyatta@vyatta:~$
show ip route でルートテーブルも確認できます。「クラウド共有サーバ」のセグメント10.0.0.0/16が伝播されていることが確認できます。
vyatta@vyatta:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
S>* 0.0.0.0/0 [210/0] via 192.168.0.1, eth0
B>* 10.0.0.0/16 [20/100] via 169.*.*.*, vti0, 00:50:38
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.0.0/20 is directly connected, eth0
~中略~
vyatta@vyatta:~$
疎通確認
「本社PC」から「クラウド共有サーバ」へPing疎通が通ることを確認してみます。 疎通出来ていれば正しく構築できています。
NAT通信用設定変更
今の状態では、「クラウド共有サーバ」から本社のセグメントは192.168.0.0/20として見えています。
「本社」の実際のセグメント192.168.0.0/20ではなく、NAT後のセグメント172.16.0.0/20が「本社」として見えるようにする変更を実施していきます。
まずは「本社」から広報するルートを192.168.0.0/20に172.16.0.0/20を足していきます。 「仮想ルータ」へログインして以下設定を投入、反映します。
- BGP広報ルートの追加設定
set protocols static route 172.16.0.0/20 next-hop 192.168.12.44 set protocols bgp 65001 network 172.16.0.0/20
1行目は2行目で広報するために自身のルートテーブルに宛先ネットワークへの経路が必要なため。 2行目でBGPに172.16.0.0/20を追加しています。
設定追加後、「クラウド共有サーバ」のルートテーブルを確認すると追加されていることが確認できます。
次に「仮想ルータ」に送信元NAT設定を入れていきます。
- 送信元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.0.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.0.0/20'
VPNはIPSECで構成されますが、IPSECトンネルは2つ作成され、vti0とvti1がトンネルインターフェース名になります。それぞれのインターフェースを出力インターフェースとするNAT設定を作成しています。
設定投入後、commitで反映させていきます。
改めて「本社PC」から疎通確認をしてみます。
Pingが通っています。
「仮想ルータ」でNAT変換状態を見ると想定通り変換されていることが分かります。
「クラウド共有サーバ」で到達パケットを見ても172.16.8.158であることが確認できます。
最後に「仮想ルータ」のBGP広報ルートから192.168.0.0/20を削除してみます。これを削除しても同じようにPing疎通できる状態かを確認していきます。
- BGP広報ルートから実際のセグメント192.168.0.0/20を削除
delete protocols bgp 65001 network 192.168.0.0/20
commit してからステータスを確認してみます。
192.168.0.0/20が広報されなくなっています。
これで、「クラウド共有サーバ」からは「本社」が172.16.0.0/20として見えているが、実際には本社のセグメントは192.168.0.0/20のままで通信が出来ている状態、が出来ました。（長かった。。）
まとめ
Site-to-Site VPN設定自体は難しくないのですが、VYOSのNAT設定が関連してくると難度が上がり、手探りでの設定と検証を繰り返す形になりました。
マネージドコンソールのSite-to-Site VPN側は細かなルーティング設定は出来ないように思いましたが、今回の構成ではBPGルートを受け取るだけで良いので想定通りの挙動には十分でした。
個人的にはルータをEC2で実現出来るVYOSが非常に役に立った印象です。showコマンドもCiscoライクで比較的理解しやすい点も〇。
おわりに
私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
