AWS でVPNを張るとき、AWS側のVPCのCIDRと、拠点側のCIDRは、被らないように設計します。 が、諸々の事情で被ってしまった場合でも、ロンゲストマッチによって何とかなるかも？というおはなし。
CIDRオーバーラップ
たとえば 10.0.0.0/8 と 10.1.0.0/16 は被っています。この状態を、オーバーラップというらしいです。この場合はなんとかなりますが、まるまる同じCIDRの場合は無理です。
ロンゲストマッチとは
ルートテーブルで、オーバーラップが発生している場合、ビットマスクが長いほうが優先されます。一般的にオンプレ（拠点）側のCIDRの方が、アドレス領域が広いと仮定して(AWSは/16が限界です)、
拠点側のルートテーブル
| DEST | GW |
|---|---|
| 10.0.0.0/16 | 自分 |
| 10.0.240.0/22 | AWSのVGWへ |
AWS側のルートテーブル
| DEST | GW |
|---|---|
| 10.0.240.0/22 | 自分(local) |
| 10.0.0.0/16 | 拠点のルーターへ |
であれば、拠点からAWS側のアクセスにはロンゲストマッチで、VPN経由となり、AWS側は自身のCIDRはlocal、それ以外のローカルアドレスはVPN経由となります。
VPCで実験
VPNで実験の前に、VPCpeeringで試してみます。peeringの制限上、CIDR完全かぶりやオーバーラップは直接張れません。仕方が無いので3つのVPCをpeeringします。こんな感じ。
設定
こんな設定です。
| VPC | DEST | GW |
|---|---|---|
| VPC-A | 10.0.0.0/16 | local |
| VPC-A | 172.31.0.0/16 | A – C peer GW |
| VPC-B | 10.0.240.0/22 | local |
| VPC-B | 172.31.0.0/16 | B – C peer GW |
| VPC-C | 172.31.0.0/16 | local |
| VPC-C | 10.0.0.0/16 | A – C peer GW |
| VPC-C | 10.0.240.0/22 | B – C peer GW |
VPC-Cのルートテーブルでロンゲストマッチを使ってます、セキュリティグループも各々のネットワークからの ping が通るようにしておきます。
実験
すべてテスターから行います。 ping でもいいのですが、わけあってhttpです。各VPCがわかるように、 this is VPC-X とだけ書いて、仕込みました。
まずは狭い方(ロング)へ
[ec2-user@ip-172-31-43-80 ~]$ curl 10.0.240.129 this is VPC-B
おお、効いてる
今度は広い方へping
[ec2-user@ip-172-31-43-80 ~]$ curl 10.0.0.228 this is VPC-A
こっちも大丈夫！
最後に、AにもBにも 10.0.240.129 を作っておきました。この場合、ロンゲストマッチでB側の 10.0.240.129 に到達するはずですが、Bのサーバを停止して、Aに飛んだりしないか確認します。
AもBも生きている状態はさっきやっているので省略。ではBを停止して、どうなるか。
[ec2-user@ip-172-31-43-80 ~]$ curl 10.0.240.129
帰ってこない。ルートテーブルにきっちり縛られます。この状態でVPC-Aの 10.0.240.129 に開通したいなら、ルートテーブルから B-C peer GWのルールを消す必要があります。
まとめ
ロンゲストマッチでオーバーラップが発生してもなんとかできることが分かりました。また、ロンゲストマッチは、狭い方に1回飛ばして、反応が場合は広い方に飛ばすような、奇妙な動作もしませんでした(もしもそんなことができればFailOverにつかえますね)。
参考
Configurations With Routes to Specific Subnets or IP Addresses – Amazon Virtual Private Cloud
元記事はこちらです。
「VPC Peeringを使ってロンゲストマッチを試す」
