読者です 読者をやめる 読者になる 読者になる

続 カッコの付け方

AWSを始めとしたクラウドコンピューティング全般と、唯一神emacsにおける()の付け方についてだらだら書きます

VPC Peeringを使ってロンゲストマッチを試す

AWSVPNを張るとき、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経由となります。

VPCで実験

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

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

設定

こんな設定です。

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

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につかえますね)。

参考

Configurations With Routes to Specific Subnets or IP Addresses - Amazon Virtual Private Cloud