AWS Direct Connectとは、自社のオフィスやデータセンター（オンプレミス環境）とAWSをインターネットを経由させずに専用回線で直接つなぐネットワークサービスです。
Direct Connectは、物理的な回線手配や高額な固定費が必要という大きなハードルがあり、気軽に試すことはできません。
今回はJAWS-UG茨城でAWS協力のもと、ハンズオンイベントが開催されことになったので参加してみました。
ハンズオン概要
以下のWorkshop Studioを実施していく形になります。
catalog.us-east-1.prod.workshops.aws
ハンズオンの全体構成はこちらです。
疑似オンプレミス環境は、AWS目黒オフィスのVMwareに立っている仮想ルーターになります。
全体の流れは以下の通りです。
必要なネットワークや仮想マシン用意されているので、2~5のDirect Connectに関する設定を中心に実施していきます。
踏み台環境の作成
踏み台環境をCloudFormationで作成します。Direct Connectの設定(VGW,DXGWの作成、VIFの承認)
VGW ,DXGW-1の作成およびDirect Connectの仮想インターフェイスの承認します。Direct Connectの設定(VPCの設定)
AWS側のDirect Connect環境に必要なVPC、subnet、Virtual Private Gatewayの設定をAWSコンソール上で行います。Direct Connectの設定(オンプレミス側)
踏み台環境からオンプレミス側に設置された仮想ルーターに対しリモートログインにより設定を行います。動作確認
AWS~オンプレミス間の疎通確認を行います。以降はオプション
TGW経路作成
新たにTGW用のDXGW-2を作成し、ホスト接続内にTransit VIFを作成し、DXGW-2に関連付けます。
そして、DXGW-2とTGWを割り当て、オンプレミスへ広報する経路を設定します。TGW経由へ通信を切り替え
TGWとVPCをアタッチし、VPCサブネットが参照しているルートテーブルで、オンプレミス向け経路をTGWへ変更します。
VIFの確認
既に作成されている仮想インターフェイスを確認します。
bastion server(踏み台)と疑似オンプレミス間を接続する仮想インターフェイスは、すでに承諾およびVGWの関連付けが済んでいるため、availableとなっています。
VGWの作成とVPCへの関連付け
training用VPCに、仮想プライベートゲートウェイを作成し、オンプレミスとの接続ポイントとなるように設定します。
次に作成したVGWをtraining用VPCにアタッチします。
サブネットのルーティングテーブルにオンプレミスへのルーティングエントリを追加します。
ルートテーブルのルートから編集を行います。
こちらが追加したルートです。
DXGWの作成とVIFの承認
Direct Connectゲートウェイを作成します。
ASNはAWSがデフォルトで利用するプライベートAS番号「64512」を指定します。
作成したDXGWにtraining用に作成したVGWを関連付けます。
数分するとassociatedに代わります。
csrのVIFの承諾を行い、作成したDXGWとの関連付けを行います。
pendingになります。
vsrxのVIFも同様に承諾と関連付けを行います。
両VIFともdownになりますが、この後のBGPの設定をすることで解消されます。
オンプレミスのCisco CSRの設定
Session Managerで踏み台サーバーに接続します。
踏み台サーバからsshでcsr (Ciscoルーター)に接続します。
/bin/bash sh-4.2$ /bin/bash [ssm-user@ip-10-7-0-55 bin]$ ssh aws@csr Password: csr#
割愛しますが、インターフェイスやBGPに設定をすることでアドバタイズされるようになり、仮想インターフェイスがavairalbeになります。
VIFのモニタリングタブでパケットの流量やBGPの状態などを確認できます。
疎通確認
それでは踏み台サーバーからserver1へ疎通確認をしてみます。
$ ping server1 PING server1 (172.16.0.100) 56(84) bytes of data.
pingが失敗しますが、これは設定が不足しているためです。
「subnet-dxtraining-1」のルートテーブルを確認してみます。
これは、疑似オンプレミス環境のCIDR「192.168.10.0/24」宛ての経路は指定されますが、bastion-serverが存在する「10.7.0.0/16」宛ての経路が指定されていないためです。
そこで、経路をサブネットのルートテーブルへ自動反映させるため、ルートテーブルでVGWに対して「ルート伝播」を有効にします。
すると、ルートが伝搬されるようになり、pingが通るようになりました。
[ssm-user@ip-10-7-0-55 ~]$ ping server1 PING server1 (172.16.0.100) 56(84) bytes of data. 64 bytes from training-server-1 (172.16.0.100): icmp_seq=229 ttl=251 time=6.46 ms 64 bytes from training-server-1 (172.16.0.100): icmp_seq=230 ttl=251 time=5.82 ms 64 bytes from training-server-1 (172.16.0.100): icmp_seq=231 ttl=251 time=5.95 ms 64 bytes from training-server-1 (172.16.0.100): icmp_seq=232 ttl=251 time=5.97 ms 64 bytes from training-server-1 (172.16.0.100): icmp_seq=233 ttl=251 time=5.77 ms
DXGWに別リージョンのVPCを接続
DXGWとバージニアリージョンを接続し、踏み台サーバーから接続を行います。
ゲートウェイの関連付けでVGW「vgw-dxtraining-2」を関連付けます。
バージニアリージョンのサーバへもpingが通るようになりました。
[ssm-user@ip-10-7-0-55 bin]$ ping server2 PING server2 (172.17.0.100) 56(84) bytes of data. 64 bytes from training-server-2 (172.17.0.100): icmp_seq=1 ttl=123 time=147 ms 64 bytes from training-server-2 (172.17.0.100): icmp_seq=2 ttl=123 time=146 ms 64 bytes from training-server-2 (172.17.0.100): icmp_seq=3 ttl=123 time=147 ms 64 bytes from training-server-2 (172.17.0.100): icmp_seq=4 ttl=123 time=146 ms 64 bytes from training-server-2 (172.17.0.100): icmp_seq=5 ttl=123 time=146 ms
まとめ
Direct Connectの設定と疎通確認を体験することで、オンプレからAWSへ繋がる裏側の仕組みが鮮明になりました。
ハードルの高さから個人では机上レベルでしか学習できないため、非常に良い経験になりました。
