Zenn
Closed4

NETWORKING IMMERSION DAY / BEGINNER TOPICS / LAB 2: DATACENTER CONNECTIVITY

AWS
network
kenryokenryo

https://networking.workshop.aws/beginner/lab2.html

サイト間VPN(IPsec)やDirect Connectなど既存のデータセンターと通信する機能がVPCにはある。
VPNは最大スループットが1.25Gbpsだが、Transit Gatewayを使用するとECMPを使用してスループットを拡張することができる。

このラボでは以下で作成した環境を使用する。作成していない場合、このラボでCloudFormationテンプレートが提供されているのでそれを実行して作成しておく。

https://zenn.dev/kenryo/scraps/c15c499e9e340c

kenryokenryo

1 Launch CloudFormation template

提供されているCloudFormationテンプレートを実行すると1つのVPCが作成される。
VPCはパブリックサブネット、プライベートサブネットを持ち、踏み台サーバ、DNSサーバ、アプリケーションサーバが作成される。

2 Explore the simulated datacenter environment

踏み台サーバにログインし、/etc/resolv.confのnameserverのIPがDNSサーバのプライベートIPと同じであること、VPCのデフォルトではなくカスタムDNSを使用していることを確認する。

sh-4.2$ cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search example.corp
options timeout:2 attempts:5
nameserver 10.10.1.95

踏み台サーバから以下のコマンドでアプリケーションサーバにアクセスし、Hello, world.が返ることを確認する。

curl http://myapp.example.corp

3 Create a Transit Gateway attachment

Transit Gatewayアタッチメントを作成する。
アタッチメントタイプはVPN
カスタマーゲートウェイは新規で作成し、IPは踏み台サーバのパブリックIPを指定する


作成されたアタッチメントはVPCのサイト間VPN画面で参照することができる。

画面右上の設定をダウンロードするを選択する。
ベンダーOpenswanを選択し、設定ファイルをダウンロードしておく。

トンネルの詳細タブを選択し、外部IPアドレスをメモっておく

Transit Gatewayのルートテーブルにルートを追加する。
仮想データセンターのCIDR(10.10.0.0/16)への通信を先ほど作成したTransit Gatewayへ流す。

kenryokenryo

LAB 2.2: SETUP VPN CONNECTION

3つのVPCの相互接続を可能にしているTransit Gatewayと仮想データセンター環境を連携させるためには、
Transit Gatewayとカスタマーゲートウェイ間にVPNを張る必要がある。
今回カスタマーゲートウェイは踏み台サーバで稼働している設定とする。

1 Configure the simulated datacenter VPC’s routing.

踏み台サーバをカスタマーゲートウェイとして使用するため、サーバをルーターとして使用し、Transit Gatewayと繋ぐ。

踏み台サーバのEC2インスタンスを選択し、アクション-ネットワーク-ソース/宛先チェックを変更を選択する。

停止を選択することでインスタンスをルーターとして使用することができる。
停止するとインスタンス自身のIPアドレス以外の通信も通過させることができる。

踏み台サーバとVPNエンドポイントがIPsecで通信できるように、
踏み台サーバのセキュリティグループにインバウンドルールを追加する。
UDP ポート500、UDP ポート 4500
IPはサイト間VPN画面でメモっておいたトンネルの外部IPアドレスを指定する。

ルートテーブルを編集して仮想データセンター環境とAWSを連携させます。
仮想データセンター用のルートテーブルOnPremNatRouteTableを選択します。
3つのVPCを束ねるTransit GatewayのCIDR(10.0.0.0/14)を送信先に、ターゲットに踏み台サーバを指定します。

2 Configure OpenSWAN and bring up the tunnel

踏み台サーバにログインし、sudo nano /etc/sysctl.confを入力する。
IPフォワーディングを有効にするため、以下を入力する。

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0

設定を適用するためsudo sysctl -pをコマンドする。

sh-4.2$ sudo sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0

sudo nano /etc/ipsec.d/aws.confを入力する。

前の手順でダウンロードしたOpenSWANの設定ファイルを開き、IPSEC Tunnel #1の4)に記載しているconn Tunnel1から始まる文字列をコピーし、aws.confに貼り付ける。
この時、
auth=espは削除
<LOCAL NETWORK>は仮想データセンターのCIDR10.10.0.0/16に変更
<REMOTE NETWORK>は3つのVPCをまとめる10.0.0.0/14に変更

続いてsudo nano /etc/ipsec.d/aws.secretsを入力する。
OpenSWANの設定ファイルを開き、IPSEC Tunnel #1の5)に記載されている文字列を入力する。

以下のコマンドでOpenSWANを有効にする。

sudo systemctl enable ipsec.service
sudo ipsec start

sh-4.2$ sudo systemctl enable ipsec.service
Created symlink from /etc/systemd/system/multi-user.target.wants/ipsec.service to /usr/lib/systemd/system/ipsec.service.
sh-4.2$ sudo ipsec start
Redirecting to: systemctl start ipsec.service
sh-4.2$

踏み台サーバから3VPCで起動されているインスタンスにpingできることを確認

sh-4.2$ ping -c 3 10.0.0.187
PING 10.0.0.187 (10.0.0.187) 56(84) bytes of data.
64 bytes from 10.0.0.187: icmp_seq=1 ttl=253 time=6.50 ms
64 bytes from 10.0.0.187: icmp_seq=2 ttl=253 time=4.44 ms
64 bytes from 10.0.0.187: icmp_seq=3 ttl=253 time=4.45 ms

--- 10.0.0.187 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.442/5.132/6.504/0.970 ms
sh-4.2$ ping -c 3 10.1.0.75
PING 10.1.0.75 (10.1.0.75) 56(84) bytes of data.
64 bytes from 10.1.0.75: icmp_seq=1 ttl=253 time=5.78 ms
64 bytes from 10.1.0.75: icmp_seq=2 ttl=253 time=4.65 ms
64 bytes from 10.1.0.75: icmp_seq=3 ttl=253 time=4.71 ms

--- 10.1.0.75 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 4.652/5.052/5.789/0.524 ms
sh-4.2$ ping -c 3 10.2.0.111
PING 10.2.0.111 (10.2.0.111) 56(84) bytes of data.
64 bytes from 10.2.0.111: icmp_seq=1 ttl=253 time=5.37 ms
64 bytes from 10.2.0.111: icmp_seq=2 ttl=253 time=4.51 ms
64 bytes from 10.2.0.111: icmp_seq=3 ttl=253 time=4.44 ms

--- 10.2.0.111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.447/4.781/5.378/0.426 ms

3 Test the VPN connection from AWS to the simulated datacenter network.

仮想オンプレ環境の踏み台サーバからAWS環境への接続を確認することができた。
仮想オンプレのアプリケーションサーバにAWS環境から接続できるか確認してみる。

3VPCのいずれかのEC2にログインし、curl http://myapp.example.corpを実行する。

sh-4.2$ curl http://myapp.example.corp
curl: (6) Could not resolve host: myapp.example.corp
sh-4.2$

エラーとなり接続できなかった。これはmyapp.example.corpが解決できないからである。

次にアプリケーションサーバのプライベートアドレスでアクセスしてみる。

h-4.2$ curl http://10.10.1.24
Hello, world.
sh-4.2$

アクセスできた。

EC2インスタンスからDNSサーバに問い合わせることができるのか確認する。
DNSサーバからmyapp.example.corpのプライベートIPが返ってきた。

sh-4.2$ dig @10.10.1.204 myapp.example.corp

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> @10.10.1.204 myapp.example.corp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33858
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;myapp.example.corp.            IN      A

;; ANSWER SECTION:
myapp.example.corp.     60      IN      A       10.10.1.24

;; AUTHORITY SECTION:
example.corp.           86400   IN      NS      ns1.example.corp.

;; ADDITIONAL SECTION:
ns1.example.corp.       60      IN      A       10.10.1.204

;; Query time: 5 msec
;; SERVER: 10.10.1.204#53(10.10.1.204)
;; WHEN: Fri Apr 29 15:53:28 UTC 2022
;; MSG SIZE  rcvd: 97
kenryokenryo

LAB 2.3: SETUP ROUTE 53 RESOLVER

Route 53 Resolverを導入することで、オンプレとAWS間のDNS解決を容易にすることができる。
本章では、前回できなかったAWS環境からオンプレに登録されているドメインの解決をできるようにする。

3.1 Configure a Route 53 Resolver outbound endpoint

Route 53 Resolverはエンドポイントで外部DNSサーバと連携する。
Route 53画面でアウトバウンドエンドポイントを選択し、エンドポイントの設定を選択する。

  • エンドポイント名
    • 一意な名前を入力
  • VPC
    • VPC Aを選択
  • セキュリティグループ
    • VPC Aのデフォルトセキュリティグループを指定する

IPアドレスは以下のような感じで指定

3.2 Create a Route 53 Resolver rule for example.corp.

アウトバウンドエンドポイントを作成したことによって、Route 53 ResolverはVPC AとTGWを経由して、オンプレのDNSサーバにアクセスできるようになった。

ルールを新規追加し、3VPCからドメインexample.corpの名前解決をオンプレDNSサーバに向ける設定を追加する。
以下のIPはDNSサーバのプライベートIP。


VPC Aにアウトバウンドエンドポイントが1つ作成されていることを確認

3.3 Testing the Route 53 Resolver rule

3VPCのいずれかのインスタンスにログインし、cat /etc/resolv.confを入力。
nameserverのIPがAWS提供のDNSサーバIPであることを確認する。

sh-4.2$ cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search ap-northeast-1.compute.internal
options timeout:2 attempts:5
nameserver 10.0.0.2
sh-4.2$

curl http://myapp.example.corpを打つと名前解決に成功し、結果が返ってくることを確認。

sh-4.2$ curl http://myapp.example.corp
Hello, world.
sh-4.2$
このスクラップは2022/05/02にクローズされました