Vyattaの検証中にハマったこと

記事タイトルとURLをコピーする

みなさんこんにちは。
テクニカルグループの山田です。

今回は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)が許可される

図にするとこんな感じです。
 


 

まとめると、

  1. VyattaA,BがSource/DestinationのPort番号500でOutbound方向の通信を始める
  2. ステートフルであるセキュリティグループは、必然的にSource/DestinationPort番号500のInboundの通信も許可する
  3. 結果的に、IKEの通信がお互いのインスタンスで行き来することになりIKE SAが確立する

以上が、今回の現象の答えになります。

まとめ

よく考えれば当たり前の動作をしているだけなのですが、許可していないポートでなぜ通信が出来ているのか分からずに凄くハマりました。同じような通信をするプロトコルでも同様の現象がみられるはず。