Amazon FSx for NetApp ONTAPのフローティングIPにVGWのゲートウェイルートテーブルを使ってルーティングできるか試してみた
VGWのゲートウェイルートテーブルを使えばルーティングできるのでは?
こんにちは、のんピ(@non____97)です。
皆さんはMulti-AZ構成にしたときに作成されるAmazon FSx for NetApp ONTAP(以降FSxN)のフローティングIPに、Transit Gatewayを使わずに別ネットワークからアクセスしたいなと思ったことはありますか? 私はあります。
FSxNのフローティングIPに対して別ネットワークからアクセスする場合、通常だとTransit Gatewayが必要となります。
フローティング IP アドレスをサポートするのは AWS Transit Gateway だけです。これは推移的なピアリング接続とも呼ばれます。VPC ピアリング、AWS Direct Connect、AWS VPN は推移的ピアリングをサポートしません。そのため、ファイルシステムの VPC の外部にあるネットワークからこれらのインターフェイスにアクセスするには、Transit Gateway を使用する必要があります。
Transit Gatewayの用意が難しい場合は、「エンドポイントIPアドレスにVPCのCIDR範囲内のIPアドレスを指定できない」という制約はありますが、NLBでも代用することは可能です。
ただ、「NLBで大体した場合の制約事項も気になるし、Transit GatewayとNLBどちらも料金がかかるし、もっと良い方法はあるんじゃないだろうか...」と考えていると、VGWのゲートウェイルートテーブルでルーティングできるんじゃなかろうか とふと思いました。
フローティングIPへのルートを設定したゲートウェイルートテーブルをVGWに割り当てれば、Transit Gatewayを用意しなくとも、Site-to-Site VPN、Direct Connect経由でマウントできそうな気がします。
ゲートウェイルートテーブルの用途がミドルボックスアプライアンスへのルーティングということもあり、本来の用途としてはズレているような気はしますが、ここは良しとします。
ゲートウェイルートテーブル
ルートテーブルは、インターネットゲートウェイまたは仮想プライベートゲートウェイに関連付けることができます。ルートテーブルがゲートウェイに関連付けられている場合、ゲートウェイルートテーブルと呼ばれます。ゲートウェイルートテーブルを作成して、VPC に入るトラフィックのルーティングパスを細かく制御できます。例えば、インターネットゲートウェイを介して VPC に入るトラフィックを VPC 内のミドルボックスアプライアンス (セキュリティアプライアンスなど) にリダイレクトして、そのトラフィックをインターセプトできます。
もし、この方法で接続できるのであれば、オンプレミスからMulti-AZのFSxNに対してマウントするためだけにTransit Gatewayを用意するという構成は取らなくとも良くなります。VPCピアリングの場合はゲートウェイルートテーブルを関連付けできないので、別VPCから接続する場合は引き続きTransit Gatewayが必要となります。
いきなりまとめ
- Amazon FSx for NetApp ONTAPのフローティングIPにVGWのゲートウェイルートテーブルを使ってルーティングすることはできない
- FSxNが管理するルートテーブルにゲートウェイルートテーブルを追加することができない
- FSxNが管理するルートテーブルをVGWに関連付けて、ゲートウェイルートテーブルとすることもできない
検証環境
検証環境は以下の通りです。
動作確認として、実際にVGW経由でルーティングできるか確認する必要がありますが、我が家にはVPNルーターはありません。回避策としてVPC間でSite-to-Site VPNを構成します。VPC 2 のEC2インスタンスから VPC 1 のFSxNに対してアクセスします。
その後、FSxNをMulti-AZ構成でデプロイします。
VPC間でSite-to-Site VPNを構成
VPC 1からVPC 2へのSite-to-Site VPNの設定
それでは、VPC間でSite-to-Site VPNを構成します。
各VPCはそれぞれ作成しており、関連付けまで完了しています。
VPC 2のCGWを作成します。
VPC 2からVPC 1へのSite-to-Site VPNで使用されるトンネルのIPアドレスが現時点では不明なので、こちらのCGWは暫定的なものです。後で削除するためIPアドレスは適当なもので良いです。個人的に完全に他所様のIPアドレスを指定するのは気が引けたので、払い出しているElastic IPと同じIPアドレスを指定しました。
VPC 2用の暫定CGWの作成が完了したら、VPC 1からVPC 2へのSite-to-Site VPNの設定をします。
VGWはVPC 1のもの、CGWはVPC 2の暫定CGWを選択します。また、ルーティングオプションは静的にして、静的 IP プレフィックスにはVPC 2のCIDRを指定しました。
1つでもトンネルが構築できれば接続できるので、トンネル1のみオプションを変更します。
まずは事前共有キー(pre-shared key)を設定します。適当に英数字の32桁ぐらいの数字を生成して入力します。
続いて、スタートアップアクションを開始にします。
デフォルトの追加だとCGWからIKEのネゴシエーションプロセスを開始してからトンネルを構築します。今回はどちらもVPCからSite-to-Site VPNを張るので、どちらもデフォルトだと永遠に待ち続けてしまいます。そのため、どちらかのVGW側からIKEネゴシエーションプロセスを開始するように設定変更してあげる必要があります。
開始アクション: 新規または変更された VPN 接続の VPN トンネルを確立するときに実行するアクション。デフォルトでは、カスタマーゲートウェイデバイスが IKE ネゴシエーションプロセスを開始してトンネルを開始します。代わりに AWS が IKE ネゴシエーションプロセスを開始するように指定することもできます。
作成したSite-to-Site VPNのトンネル情報を確認します。
トンネル1の外部IPアドレス34.195.43.253を控えておきます。
なお、VPC間をSite-to-Site VPNで接続する場合、BGPは選択できません。
これはSite-to-Site VPN上でBGPのピアIPアドレスを/32で指定できないためです。BGPで使用するIPアドレスは「トンネルの内部 IPv4 CIDR」内のIPアドレスが自動で割り当てられます。
仮にどちらのSite-to-Site VPNのトンネルでも/30の同じCIDRをした場合、お互いBGPネイバーを/30の先頭のホストアドレスとして認識しようとしteBGPを確立することができません。
参考までに、トンネルの内部 IPv4 CIDRが169.254.129.48/30とした場合、ダウンロードされるコンフィグは以下の通りです。
The Customer Gateway inside IP address should be configured on your tunnel interface. Outside IP Addresses: - Customer Gateway : 34.231.75.91 - Virtual Private Gateway : 3.222.90.184 Inside IP Addresses - Customer Gateway : 169.254.129.50/30 - Virtual Private Gateway : 169.254.129.49/30 Configure your tunnel to fragment at the optimal size: - Tunnel interface MTU : 1436 bytes #4: Border Gateway Protocol (BGP) Configuration: The Border Gateway Protocol (BGPv4) is used within the tunnel, between the inside IP addresses, to exchange routes from the VPC to your home network. Each BGP router has an Autonomous System Number (ASN). Your ASN was provided to AWS when the Customer Gateway was created. BGP Configuration Options: - Customer Gateway ASN : 64513 - Virtual Private Gateway ASN : 64512 - Neighbor IP Address : 169.254.129.49 - Neighbor Hold Time : 30 Configure BGP to announce routes to the Virtual Private Gateway. The gateway will announce prefixes to your customer gateway based upon the prefix you assigned to the VPC at creation time.
トンネルの内部 IPv4 CIDRが169.254.129.48/30とすると、必ずBGPのピアIPアドレス(Neighbor IP Address) = Virtual Private Gateway = 169.254.129.49/30となってしまいます。これではBGPを確立することができません。
また、Site-to-Site VPNのトンネルの内部 IPv4 CIDRを重複しないようにした場合は、以下のように詳細はIPSEC IS UPですが、BGPが確立できていないためステータスはDownとなります。
VPC 2からVPC 1へのSite-to-Site VPNの設定
続いて、VPC 2からVPC 1へのSite-to-Site VPNの設定をしていきます。
まず、VPC 1用のCGWを作成します。
ASNではVPC 1のVGWと同じもの、IPアドレスには先ほど作成したVPNのトンネル1の外部IPアドレスを指定します。
VPC 1用のCGWの作成が完了したら、VPC 2からVPC 1へのSite-to-Site VPNの設定をします。
VGWはVPC 2のもの、CGWはVPC 1のCGWを選択します。ルーティングオプションは静的にして、静的 IP プレフィックスにはVPC 1のCIDRを指定します。また、事前共有キーを先に作成したVPNのトンネルで設定したものと同じものを指定します。他の設定はデフォルトです。
作成したSite-to-Site VPNのトンネル情報を確認します。
トンネル1の外部IPアドレス34.195.223.71を控えておきます。
VPC 1からVPC 2へのSite-to-Site VPNの更新
VPC 2のCGWとして設定すべきIPアドレスが分かったので、CGWを作り直します。
IPアドレスに先ほど作成したSite-to-Site VPNのトンネル1の外部IPアドレス34.195.223.71を指定します。
CGW作成後、暫定CGWを使用していたSite-to-Site VPNを変更して、新規に作成したCGWを指定してあげます。
設定変更して10分弱でトンネルのステータスがUpとなりました。
CloudWatchメトリクスからもSite-to-Site VPNのトンネルのステータスがUpになっていることを確認できました。
VPC 2の暫定CGWは用済みなので削除しておきましょう。
ルートテーブルの設定
各VPCのルートテーブルを設定します。
今回はSite-to-Site VPN作成時に静的 IP プレフィックスを指定したので、ルートテーブルのルート伝搬を有効にするだけです。
ルート情報を確認すると、伝搬済みがはいのルートが追加されていました。
疎通確認
VPC 2のEC2インスタンスからVPC AのEC2インスタンスに対して疎通確認します。
# 自身のIPアドレスの確認 $ hostname -i 10.1.0.242 # pingで疎通確認 $ ping -c 4 10.0.0.206 PING 10.0.0.206 (10.0.0.206) 56(84) bytes of data. 64 bytes from 10.0.0.206: icmp_seq=1 ttl=127 time=2.08 ms 64 bytes from 10.0.0.206: icmp_seq=2 ttl=127 time=1.56 ms 64 bytes from 10.0.0.206: icmp_seq=3 ttl=127 time=1.53 ms 64 bytes from 10.0.0.206: icmp_seq=4 ttl=127 time=1.54 ms --- 10.0.0.206 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 1.528/1.678/2.081/0.233 ms # tracerouteで疎通確認 $ traceroute -I 10.0.0.206 traceroute to 10.0.0.206 (10.0.0.206), 30 hops max, 60 byte packets 1 ip-10-0-0-206.ec2.internal (10.0.0.206) 2.822 ms 2.808 ms 2.805 ms
通信できていますね。
ゲートウェイルートテーブルの作成
次にゲートウェイルートテーブルを作成します。
VPC 1上に適当にルートテーブルを作成しました。
アクション-Edgeの関連付けを編集をクリックし、VGWを選択して変更を保存をクリックします。
関連付けられた仮想プライベートゲートウェイ に選択したVGWがあることを確認します。
Multi-AZ構成のFSxNのデプロイ
全ての下準備が整ったので、Multi-AZ構成のFSxNのデプロイします。
デプロイタイプでマルチAZを選択した上で、VPC ルートテーブル で、ゲートウェイルートテーブル(non-97-rtb-vgw)を選択します。
その他の設定は以下の通りです。
ファイルシステムを作成すると、なんとFile system creation does not support route tables with gateway associations. All route tables must not contain gateway associations.と怒られてしまいました。ゲートウェイルートテーブルを関連付けることはできないようです。
まだ諦めません。関連付けているルートテーブルに後からVGWに関連付けした時の挙動を確認します。
一度ゲートウェイルートテーブルからVGWの関連付けを解除した上で、Multi-AZのFSxNをデプロイします。
ルートテーブルを確認して、FSxNのフローティングIPへのルートがあることを確認します。
先ほどと同様の手順でVGWに関連付けようとしてみます。
すると、今度はRoute destination doesn't match any subnet CIDR blocksと怒られてしまいました。
これは「もう諦めろ」と言われているようなものです。
Transit GatewayかNLB経由でマウントしよう
Amazon FSx for NetApp ONTAPのフローティングIPにVGWのゲートウェイルートテーブルを使ってルーティングできるか試してみました。
結論、できません。
FSxNがデプロイされているVPCの外からマウントしたい場合は、Transit GatewayやNLBを使ってマウントしましょう。
ほぼ、VPC間をSite-to-Site VPNで接続する記事となった気がしますが、それはそれで良しとします。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] ONTAP接続時に使用するユーザーとロールを作成してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
