みなさんこんにちは。
テクニカルグループの山田です。
今回はVyattaの検証中に起きてハマった現象と、その原因について調べたので共有したいと思います。
検証環境
環境としては前回のVyattaの記事そのままで、別々のVPC内にVyattaを構築し、Vyatta間でIPsec VPN接続するというものです。
前回の記事 : http://blog.serverworks.co.jp/tech/2013/12/04/vyatta_site-to-site/
- VPCを2つ作成
- それぞれのVPCのPublicSubnetにVyattaインスタンスを作成
-
VyattaインスタンスにEIPを付与する
検証中に起きた現象とは
まず初めに、今回どんな現象が起きたのかを説明すると
「SecurityGroupでIPsec SA生成に必要なポートを許可していないのに、Vyatta間でIPsec SAが生成された」
のです。
通常、VPNルータ間でIPsec SAを生成するには IKE(UDPポート番号500) と ESP(IPプロトコル番号50) を許可する必要があります。が、今回たまたまIKE(UDPポート番号500)を許可せずにESPのみを許可した状態でVyattaインスタンス内のログを確認したところ、IPsec SAが生成されたというログが出力されていました。
root@vyatta:/home/vyatta# tcpdump -i eth0 udp port 500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:27:14.025356 IP ec2-xx.compute-1.amazonaws.com.isakmp > 10.1.100.123.isakmp: isakmp: phase 1 I ident
00:27:14.025770 IP 10.1.100.123.isakmp > ec2-xx.compute-1.amazonaws.com.isakmp: isakmp: phase 1 R ident
00:27:14.049502 IP ec2-xx.compute-1.amazonaws.com.isakmp > 10.1.100.123.isakmp: isakmp: phase 1 I ident
00:27:14.061023 IP 10.1.100.123.isakmp > ec2-xx.compute-1.amazonaws.com.isakmp: isakmp: phase 1 R ident
00:27:14.069419 IP ec2-xx.compute-1.amazonaws.com.isakmp > 10.1.100.123.isakmp: isakmp: phase 1 I ident[E]
00:27:14.070103 IP 10.1.100.123.isakmp > ec2-xx.compute-1.amazonaws.com.isakmp: isakmp: phase 1 R ident[E]
00:27:14.079176 IP ec2-xx.compute-1.amazonaws.com.isakmp > 10.1.100.123.isakmp: isakmp: phase 2/others I oakley-quick[E]
00:27:14.090477 IP 10.1.100.123.isakmp > ec2-xx.compute-1.amazonaws.com.isakmp: isakmp: phase 2/others R oakley-quick[E]
00:27:14.234764 IP ec2-xx.compute-1.amazonaws.com.isakmp > 10.1.100.123.isakmp: isakmp: phase 2/others I oakley-quick[E]
※VyattaBのudpの500番ポートでtcpdumpすると、VyattaAからの通信(IKE)がVyattaBまで到達している事が確認できた
※VyattaAが ec2-xx.compute-1.amazonaws.com
※VyattaBが 10.1.100.123
※お互いのVyattaのSecurityGroupはESPしか許可してない
原因は何なのか
前提として、SecurityGroupはステートフル(パケットの状態をチェックし動的にポートの開閉をしてくれる)でOutboundへの通信については特に制限なく許可されます。
つまり、Outbound方向の通信があったものについては Outbound に対しての返信(Inbound方向の通信)があるものとして通信を受け入れてしまいます。IPSecではIKE(UDPポート番号500)を利用しますが SourcePortも500、DestinationPortも500になり、しかも通信は双方向で実施されます。
つまり、次の①と②の2つの通信がVyattaA,Bで同時に実施されるのです。
①VyattaAがVyattaBとIPsecトンネルを結ぶ際の通信
From: VyattaA, UDP Port 500
To: VyattaB, UDP Port 500
→ SecurityGroupはステートフルなので、VyattaB UDP 500番Port からの通信(IKE)が許可される
②VyattaBがVyattaAとIPsecトンネルを結ぶ際の通信
From: VyattaB, UDP Port 500
To: VyattaA, UDP Port 500
→ SecurityGroupはステートフルなので、VyattaA UDP 500番Port からの通信(IKE)が許可される
図にするとこんな感じです。
まとめると、
- VyattaA,BがSource/DestinationのPort番号500でOutbound方向の通信を始める
- ステートフルであるセキュリティグループは、必然的にSource/DestinationPort番号500のInboundの通信も許可する
- 結果的に、IKEの通信がお互いのインスタンスで行き来することになりIKE SAが確立する
以上が、今回の現象の答えになります。
まとめ
よく考えれば当たり前の動作をしているだけなのですが、許可していないポートでなぜ通信が出来ているのか分からずに凄くハマりました。同じような通信をするプロトコルでも同様の現象がみられるはず。