2012-02-12

RTX1000 が VPN で packet loss するわけがないじゃないか

RTX

id:blooper:20120208 の時点で RTX1000 を AWS の VPC と繋いだら packet loss が激しかったので職場でボヤいてみました。

「RTX1000 が VPN でパケロスするんすよねー」
「MTU, ping」

つわけで MTU の最適値をめっけて設定するところからはじめるぜ。

折れない packet で MTU にうってつけの値を探すこと

ping の man 見るとこんな感じ

      -s packetsize
              Specifies the number of data bytes to be sent.  The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
      -M hint
              Select Path MTU Discovery strategy.  hint may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).

よーし、とーさん ping 打っちゃうぞー

$ ping -s 1472 -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.36.2 icmp_seq=1 Frag needed and DF set (mtu = 1454)
From 192.168.36.2 icmp_seq=2 Frag needed and DF set (mtu = 1454)
From 192.168.36.2 icmp_seq=3 Frag needed and DF set (mtu = 1454)

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms

Ethernet つったら 1500 bytes だと思って 1500 bytes で ping 打ったのに届かないよ!! というわけでフレッツ光の場合には 1454 に設定しろって言われてるし config にもちゃんと

pp select 1
 ppp lcp mru on 1454
 ip pp mtu 1454

という設定をしていました。問題は tunnel の方だぜ。

$ ping -M do -s 1472 -c 3 169.254.252.1
PING 169.254.252.5 (169.254.252.1) 1472(1500) bytes of data.
From 192.168.36.2 icmp_seq=1 Frag needed and DF set (mtu = 1280)
From 192.168.36.2 icmp_seq=2 Frag needed and DF set (mtu = 1280)
From 192.168.36.2 icmp_seq=3 Frag needed and DF set (mtu = 1280)

--- 169.254.252.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms

1280 にしろというオラクルを頂きました。こりゃ何でかっつーと「9.1.4 インタフェースの MTU の設定」にある通り tunnel の MTU がデフォルトで 1280 になってるから。じゃぁどんくらまでいけるのよ? ということでここでおもむろに

# tunnel select 1
# ip tunnel mtu 1454
# tunnel select 2
# ip tunnel mtu 1454

としてみる。

$ ping -s 1426 -c 3 169.254.252.1
PING 169.254.252.1 (169.254.252.1) 1426(1454) bytes of data.

--- 169.254.252.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

通らない、何も通らない。size を小さくしていってみると、

$ ping -s 1363 -c 3 169.254.252.1
PING 169.254.252.1 (169.254.252.1) 1363(1391) bytes of data.

--- 169.254.252.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

$ ping -s 1362 -c 3 169.254.252.1
PING 169.254.252.1 (169.254.252.1) 1362(1390) bytes of data.
1370 bytes from 169.254.252.1: icmp_req=1 ttl=63 time=12.4 ms
1370 bytes from 169.254.252.1: icmp_req=2 ttl=63 time=13.1 ms
1370 bytes from 169.254.252.1: icmp_req=3 ttl=63 time=18.1 ms

--- 169.254.252.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.404/14.583/18.183/2.567 ms

1390 bytes でｷﾀｰ｡ってこれ id:j3tm0t0:20111108 で計算されてる値そのものですね。失礼しました。mss の設定も 1390 - 40 でいいのかなと思ったけど auto ってので多分同じことしてくれるんだろうと思って auto でお茶を濁すことに。

tunnel select 1
 ip tunnel mtu 1390
 ip tunnel tcp mss limit auto
tunnel select 2
 ip tunnel mtu 1390
 ip tunnel tcp mss limit auto

よーしこれで! と思ったけど、packet loss はまだ無くならないのでした。

ログがあるならログを読め

んー、何かログに残ってないのかな、とおもって log 見てみました。

$ egrep 'IP Tunnel\[1\]' rtxlog.txt
(略)
2012/02/11 02:08:35: IP Tunnel[1] Up
2012/02/11 02:09:05: IP Tunnel[1] Down
2012/02/11 02:09:10: IP Tunnel[1] Up
2012/02/11 02:09:27: IP Tunnel[1] Down
2012/02/11 02:09:31: IP Tunnel[1] Up
2012/02/11 02:10:01: IP Tunnel[1] Down
2012/02/11 02:10:06: IP Tunnel[1] Up
2012/02/11 02:10:36: IP Tunnel[1] Down
2012/02/11 02:10:41: IP Tunnel[1] Up
2012/02/11 02:11:11: IP Tunnel[1] Down
2012/02/11 02:11:16: IP Tunnel[1] Up
2012/02/11 02:11:46: IP Tunnel[1] Down
(略)

なんだこれ、30 秒毎に綺麗に down してるぞ?? と思って設定ファイルを見直してみると

tunnel select 1
  ipsec ike keepalive use 1 on heartbeat 10 3
tunnel select 2
  ipsec ike keepalive use 2 on heartbeat 10 3

もしかして、これか? 何も良く分からず適当に設定して対応してない heartbeat で死活監視しようとしていたか!!

# tunnel select 1
# no ipsec ike keepalive use 1
# tunnel select 2
# no ipsec ike keepalive use 2

と設定無しにして ping 打ってみると

--- 169.254.252.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 59086ms
rtt min/avg/max/mdev = 7.325/14.577/43.399/8.103 ms

パケロス無し! やぁ、めでたい。っていうかスゲー間抜けだった。死活監視は無いのも何なので

# tunnel select 1
# ipsec ike keepalive use 1 on icmp-echo 169.254.252.1
# tunnel select 2
# ipsec ike keepalive use 2 on icmp-echo 169.254.252.5

にしてみました。

改めて、どのくらいの速度で繋がるのか気になるところ

再度 iperf で up と down を、デフォルトの 10 秒のを 25 回試してみました。

パケロスしてたのに比べると随分改善した感じです、が、ちょっとダウンが不安定ですね。ちなみにパケロスしてたときのはこちら:

Down の max はパケロスしてたときの方がいけていますねぇ、これは、mss の影響なのか、CPU の利用率などの理由なのか、う〜ん。

iperf してる間 RTX1000 の CPU はほぼ 100% に張り付いていました。あっつあつっすな。

ちなみに設定はいまのところこんな感じ

console character ascii
ip route default gateway pp 1
ip lan1 address 192.168.100.1/24
pp select 1
 pp always-on on
 pppoe use lan2
 pppoe auto disconnect off
 pp auth accept pap chap
 pp auth myname ID PASSWD
 ppp lcp mru on 1454
 ppp ipcp ipaddress on
 ppp ipcp msext on
 ppp ccp type none
 ip pp mtu 1454
 ip pp nat descriptor 1
 pp enable 1
pp select 2
 ip pp mtu 1454
tunnel select 1
 ipsec tunnel 201
  ipsec sa policy 201 1 esp aes-cbc sha-hmac
  ipsec ike always-on 1 on
  ipsec ike duration ipsec-sa 1 3600
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike keepalive use 1 on icmp-echo 169.254.252.1 10 3
  ipsec ike local address 1 192.168.100.1
  ipsec ike pfs 1 on
  ipsec ike pre-shared-key 1 *
  ipsec ike remote address 1 27.0.1.16
 ip tunnel address 169.254.252.2/30
 ip tunnel remote address 169.254.252.1
 ip tunnel mtu 1390
 ip tunnel tcp mss limit auto
 tunnel enable 1
tunnel select 2
 ipsec tunnel 202
  ipsec sa policy 202 2 esp aes-cbc sha-hmac
  ipsec ike always-on 2 on
  ipsec ike duration ipsec-sa 2 3600
  ipsec ike encryption 2 aes-cbc
  ipsec ike group 2 modp1024
  ipsec ike hash 2 sha
  ipsec ike keepalive use 2 on icmp-echo 169.254.252.5 10 3
  ipsec ike local address 2 192.168.100.1
  ipsec ike pfs 2 on
  ipsec ike pre-shared-key 2 *
  ipsec ike remote address 2 27.0.1.144
 ip tunnel address 169.254.252.6/30
 ip tunnel remote address 169.254.252.5
 ip tunnel mtu 1390
 ip tunnel tcp mss limit auto
 tunnel enable 2
nat descriptor type 1 masquerade
nat descriptor address outer 1 ipcp
nat descriptor address inner 1 192.168.100.1-192.168.100.254
nat descriptor masquerade static 1 1 192.168.100.1 udp 500
nat descriptor masquerade static 1 2 192.168.100.1 esp
bgp use on
bgp autonomous-system 65000
bgp neighbor 1 10124 169.254.252.1 hold-time=30
bgp neighbor 2 10124 169.254.252.5 hold-time=30
bgp import filter 1 equal 192.168.100.0/24
bgp import 10124 static filter 1
ipsec auto refresh on
dhcp service server
dhcp scope 1 192.168.100.128-192.168.100.254/24
dns server pp 1
dns private address spoof on
schedule at 1 */* *:15 * ntpdate ntp.ring.gr.jp

2012-02-08

YAMAHA の RTX1000 を使って自宅を AWS の VPC と繋いでみたよ

RTX AWS VPC

お手頃なお値段でご自宅でも show config できる時代となりました

RTX1000 といえば「ASCII.jp：楽器メーカーが作った傑作VPNルータ「RTX1000」 (1/3)｜歴史を変えたこの1台」なわけですが流石に時は流れて「http://auctions.search.yahoo.co.jp/search?ei=UTF-8&p=RTX1000&auccat=0&tab_ex=commerce&s1=cbids&o1=a&slider=0」を見ると 2000 円もあれば送料込みで自宅にやってくるくらいの手軽な存在になっています。というわけで手元に RTX1000 がやってきました。こんにちは!

つわけで RTX1000 を AWS の VPC を繋いでみようと思うんですが、RTX1100 のことなら巷に沢山溢れているので Management Console の作業のことなんかも含め「vpc rtx1100 - Google 検索」でおググりあそばせ。

シリアル <-> USB が無くても何とかなるよ

当然のように初期化されてやってきた RTX1000 には IP address が振られていないので telnet で繋ぐことができません。シリアルケーブルがあれば問題ないわけですが、そういえば個人所有したことがなかったので家にはありません。残念。そんなときの RARP です。Ubuntu なら RARP もいちころです、って「http://hitaki.net/diary/20070115.html」に書いてありました。

# aptitude install rarpd
# cat > /etc/ethers
xx:xx:xx:xx:xx:xx 192.168.100.1
# /etc/init.d/rarpd restart

で、パソコンと RTX1000 の lan1 を繋いで RTX1000 を起動してあげれば

$ telnet 192.168.100.1
Trying 192.168.100.1...
Connected to 192.168.100.1.
Escape character is '^]'.

Password: 

RTX1000 BootROM Ver. 1.04

RTX1000 Rev.8.01.29 (Fri Apr 15 11:50:44 2011)
  Copyright (c) 1994-2011 Yamaha Corporation.
  Copyright (c) 1991-1997 Regents of the University of California.
  Copyright (c) 1995-1996 Jean-loup Gailly and Mark Adler.
  Copyright (c) 1998-2000 Tokyo Institute of Technology.
  Copyright (c) 2000 Japan Advanced Institute of Science and Technology, HOKURIKU.
  Copyright (c) 2002 RSA Security Inc. All rights reserved.
xx:xx:xx:xx:xx:xx, xx:xx:xx:xx:xx:xx, xx:xx:xx:xx:xx:xx, 
Memory 16Mbytes, 3LAN, 1BRI
>

いぇ〜い、ってほんとは firmware の update をこの次にしたんだけど、省略。TFTP するだけよ。で、とりあえず

> administrator
Passwd:
# console character ascii 
# ip lan1 address 192.168.100.1/24
# save
Saving ... CONFIG0 Done .

これで再起動しても大丈夫。用済みの rarpd はさようなら。

# aptitude purge rarpd

インターネットに繋がっていないと単なる青い箱だ

YAMAHA はサポートが充実しすぎていて「PPP over Ethernet (PPPoE)」を見たらあっという間にインターネットにも繋がってしまいます。フレッツ光が来ているのでちょちょいとインターネットに繋がってしまいました。

ip route default gateway pp 1
pp select 1
 pp always-on on
 pppoe use lan2
 pppoe auto disconnect off
 pp auth accept pap chap
 pp auth myname ID PASSWD
 ppp lcp mru on 1454
 ppp ipcp ipaddress on
 ppp ipcp msext on
 ppp ccp type none
 ip pp mtu 1454
 ip pp nat descriptor 1
 pp enable 1
nat descriptor type 1 masquerade

で、RTX1000 で見てみると

# show status pp 1
PP[01]:
Current PPPoE session status is Connected.
Access Concentrator: BAS
8 seconds  connection.
Received: 106 packets [24188 octets]  Load: 0.0%
Transmitted: 156 packets [41032 octets]  Load: 0.0%
PPP Cofigure Options
    LCP Local: Magic-Number MRU, Remote: CHAP Magic-Number MRU
(略)

繋がりました。ついでに DHCP サーバとかにもしておきましょう。

dhcp service server
dhcp scope 1 192.168.100.128-192.168.100.254/24
dns server pp 1
dns private address spoof on

これでブロードバンドルータとしてはひとまず完成。

VPN ルータを VPN で繋ぐぜ

でもその繋ぎ先が今回 AWS の VPC の VPN Connection となるわけです。どーするかっつーと、

Management Console から Customer Gateway を作る (RTX1000 に振られてる Global IP address を入力)
Management Console から Virtual Private Gateway を作る
Management Console から VPN Connection を作る (上の 2 つの Gateway を指定する)

で、できあがった VPN Connections を選んで Download Configuration から YAMAHA 用の設定ファイルをダウンロードしました。中身はこんな感じで長いです。

(2012/Feb/12 追記: この keepalive の設定は間違いです。死活監視が失敗します。詳細は id:blooper:20120212)

$ cat ~/Downloads/vpn-babf15bb.txt 
# Amazon Web Services
# Virtual Private Cloud

# AWS utilizes unique identifiers to manage the configuration of 
# a VPN Connection. Each VPN Connection is assigned an identifier and is 
# associated with two other identifiers, namely the 
# Customer Gateway Identifier and Virtual Private Gateway Identifier.
#
# Your VPN Connection ID                    : vpn-babf15bb
# Your Virtual Private Gateway ID           : vgw-a7bf15a6
# Your Customer Gateway ID                  : cgw-d2be14d3
#
#
# This configuration consists of two tunnels. Both tunnels must be 
# configured on your Customer Gateway.
(略)

このファイルは RTX1200 用らしくって全てのコマンドが上手く通るわけではないのですが

@@ -66,7 +66,7 @@
 # This option enables IPSec Dead Peer Detection, which causes periodic
 # messages to be sent to ensure a Security Association remains operational.
 
-        ipsec ike keepalive use 1 on dpd 10 3
+        ipsec ike keepalive use 1 on heartbeat 10 3
 
 # --------------------------------------------------------------------------------
 # #3: Tunnel Interface Configuration
@@ -111,7 +111,7 @@
 #
        bgp use on
        bgp autonomous-system 6500
-       bgp neighbor 1 10124 169.254.252.1 hold-time=30 local-address=169.254.252.2
+       bgp neighbor 1 10124 169.254.252.1 hold-time=30
 
 # To advertise additional prefixes to Amazon VPC, copy the 'network' statement and 
 # identify the prefix you wish to advertise. Make sure the 
@@ -171,7 +171,7 @@
 # This option enables IPSec Dead Peer Detection, which causes periodic
 # messages to be sent to ensure a Security Association remains operational.
 
-        ipsec ike keepalive use 2 on dpd 10 3
+        ipsec ike keepalive use 2 on heartbeat 10 3
 
 # --------------------------------------------------------------------------------
 # #3: Tunnel Interface Configuration
@@ -216,7 +216,7 @@
 #
        bgp use on
        bgp autonomous-system 6500
-       bgp neighbor 2 10124 169.254.252.5 hold-time=30 local-address=169.254.252.6
+       bgp neighbor 2 10124 169.254.252.5 hold-time=30
 
 # To advertise additional prefixes to Amazon VPC, copy the 'network' statement and 
 # identify the prefix you wish to advertise. Make sure the

これくらいの編集で通るようになります、というか keepalive の方は行ごと消してしまっても問題は無いみたい。あと、IPSec を受けるのに masquerade の設定が必要なので以下も追加します:

nat descriptor masquerade static 1 1 192.168.100.1 udp 500
nat descriptor masquerade static 1 2 192.168.100.1 esp

結果、追加の設定はこんな感じ:

tunnel select 1
 ipsec tunnel 201
  ipsec sa policy 201 1 esp aes-cbc sha-hmac
  ipsec ike duration ipsec-sa 1 3600
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike keepalive use 1 on heartbeat 10 3
  ipsec ike local address 1 xxx.yyy.zzz.www
  ipsec ike pfs 1 on
  ipsec ike pre-shared-key 1 *
  ipsec ike remote address 1 27.0.1.16
 ipsec tunnel outer df-bit clear
 ip tunnel address 169.254.252.2/30
 ip tunnel remote address 169.254.252.1
 ip tunnel tcp mss limit 1396
 tunnel enable 1
tunnel select 2
 ipsec tunnel 202
  ipsec sa policy 202 2 esp aes-cbc sha-hmac
  ipsec ike duration ipsec-sa 2 3600
  ipsec ike encryption 2 aes-cbc
  ipsec ike group 2 modp1024
  ipsec ike hash 2 sha
  ipsec ike keepalive use 2 on heartbeat 10 3
  ipsec ike local address 2 xxx.yyy.zzz.www
  ipsec ike pfs 2 on
  ipsec ike pre-shared-key 2 *
  ipsec ike remote address 2 27.0.1.144
 ipsec tunnel outer df-bit clear
 ip tunnel address 169.254.252.6/30
 ip tunnel remote address 169.254.252.5
 tunnel enable 2
nat descriptor address outer 1 ipcp
nat descriptor address inner 1 192.168.100.1-192.168.100.254
nat descriptor masquerade static 1 1 192.168.100.1 udp 500
nat descriptor masquerade static 1 2 192.168.100.1 esp
bgp use on
bgp autonomous-system 6500
bgp neighbor 1 10124 169.254.252.1 hold-time=30
bgp neighbor 2 10124 169.254.252.5 hold-time=30
bgp import filter 1 equal 192.168.100.0/24
bgp import 10124 static filter 1
ipsec auto refresh on

bgp configure refresh # BGP の設定変更したらこれを実行する

繋がりました!! でもまだ VPC と Virtual Private Gateway を繋いでいないので VPC の欄が空っぽです。

VPN Connection を VPC と繋いで VPC 内のプライベートなインスタンスにアクセス

RTX1000 と Virtual Private Gateway は繋がったのですが、その Virtual Private Gateway がまだ誰とも繋がっていません。悲しいです。繋ぎましょう。

VPC 10.0.0.0/16 を作る
Virtual Private Gateway を VPC に attach する
VPC の中に Subnet 10.0.0.0/24 を作る
VPC の Main Route Table に「192.168.100.0/24 を Virtual Private Gateway に route する」というエントリを追加する (本当は別に Route Table 作るべきか?)

これで VPC が VPN Connection 経由で RTX1000 と繋がってるはずなので、暫く待つと

# show status bgp neighbor 169.254.252.1 received-routes 
Total routes: 1
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 10.0.0.0/16        169.254.252.1                 10124 IGP
> show status bgp neighbor 169.254.252.1 advertised-routes 
Total routes: 1
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 192.168.100.0/24    192.168.100.1         0        IGP

こんな感じで route table が受信できてることが確認できます。

実際繋ぐぞ!

VPC 内に SSH ができる Security Group を作成する
Subnet 内にインスタンスを作成する、Security Group は上のやつ

てな感じで作って繋いだりできました。

$ slogin 10.0.0.202 -i ~/Downloads/RTX1000.pem -l ec2-user
Last login: Tue Feb  7 16:38:59 2012 from 192.168.100.2

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

See /usr/share/doc/system-release/ for latest release notes.
There are 23 security update(s) out of 32 total update(s) available
[ec2-user@ip-10-0-0-202 ~]$

ようこそプライベートサブネットへ!

どのくらいの速度で繋がるのか気になるところ

(2012/Feb/12 追記: keepalive の設定のせいで packet loss しています。詳細・修正は id:blooper:20120212)

RTX1000 は AES をソフトウェアで処理していて中々残念です。一方 VPC は 3DES とか受け入れてくれないマッチョな体格です。ここが RTX1100 になると AES もハードで処理してくれてちょっぱやということになるらしいのですが。

つーわけで iperf -s に iperf -c を up/down でやってみました。

単位は Mbps なので、3〜4Mbps しか出ていない悲しい状況です。っつーか ping 打つと packet loss してる:

100 packets transmitted, 85 received, 15% packet loss, time 99227ms
rtt min/avg/max/mdev = 7.419/12.079/72.995/8.752 ms

なんか色々ダメかも。まぁいいか! 繋がったし!