AWSでVPNを張るとき、AWS側のVPCのCIDRと、拠点側のCIDRは、被らないように設計します。が、諸々の事情で被ってしまった場合でも、ロンゲストマッチによって何とかなるかも？というおはなし。

f:id:iga-ninja:20150124135630p:plain

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経由となります。

VPNで実験の前に、VPCpeeringで試してみます。peeringの制限上、CIDR完全かぶりやオーバーラップは直接張れません。仕方が無いので3つのVPCをpeeringします。こんな感じ。

f:id:iga-ninja:20150124143544p:plain

こんな設定です。

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を停止して、どうなるか。

f:id:iga-ninja:20150124143642p:plain

[ec2-user@ip-172-31-43-80 ~]$ curl 10.0.240.129

帰ってこない。ルートテーブルにきっちり縛られます。この状態でVPC-Aの 10.0.240.129に開通したいなら、ルートテーブルから B-C peer GWのルールを消す必要があります。

ロンゲストマッチでオーバーラップが発生してもなんとかできることが分かりました。また、ロンゲストマッチは、狭い方に1回飛ばして、反応が場合は広い方に飛ばすような、奇妙な動作もしませんでした(もしもそんなことができればFailOverにつかえますね)。