さくらのVPSでIPv6 (6rd)
まえがき
とあるサーバをアップグレードしたいと思い、 さくらのVPS(v3) SSD 1G IK01 を仮契約してしまいました。レビューについてはまた後ほど書きたいと思います。
ほんだい
さて、さくらインターネットでは6rd
を用いて、サーバにグローバルIPv6アドレスを割り当てる実験を行なっており、VPSや専用サーバなどエンドユーザがroot権限を持っているサーバならば使用できます。
なにした
さくらインターネットのサイトに6rd設定方法は載っているので詳しいセットアップ方法は割愛します。
IPアドレスの打ち間違いに気をつけましょう。それでしばらく行き詰っていました。
どうなった
つながったかどうかを判定するのに、一旦サーバにSSH
で接続し、そこからわたしがひいきにしている筑波大学 WORD編集部のサイトをwgetしてみました。
コマンドおよび出力:
[email protected]:~$ wget -O /dev/null -6 www.word-ac.net --2013-03-16 07:10:54-- http://www.word-ac.net/ Resolving www.word-ac.net (www.word-ac.net)... 2001:200:0:7c06:0:ac:3c:212 Connecting to www.word-ac.net (www.word-ac.net)|2001:200:0:7c06:0:ac:3c:212|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `/dev/null' [ <=> ] 40,059 246K/s in 0.2s 2013-03-16 07:10:55 (246 KB/s) - `/dev/null' saved [40059]
そして、ローカルから新サーバにping:
[~]$ ping6 2001:e41:123:abcd::1341:398 ch[email protected] 07:20:37 PING 2001:e41:123:abcd::1341:398(2001:e41:123:abcd::1341:398) 56 data bytes 64 bytes from 2001:e41:123:abcd::1341:398: icmp_seq=1 ttl=57 time=44.5 ms 64 bytes from 2001:e41:123:abcd::1341:398: icmp_seq=2 ttl=57 time=25.9 ms 64 bytes from 2001:e41:123:abcd::1341:398: icmp_seq=3 ttl=57 time=26.0 ms ^C --- 2001:e41:123:abcd::1341:398 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 25.944/32.170/44.530/8.741 ms
なんかへんだ
時々pingが通らなくなることがあるのですが、実験サービスなので安定性についてはしょうがないですね。 pingが通らなくなっても、サーバからのIPv6接続は問題なく行えます。しかもサーバからどこかへIPv6接続したあとこのサーバへpingするとしばらくの間は通るので、不思議です。
どうでもいいこと
- さくらインターネットの6rdでは、/64のIPv6アドレスブロックがもらえるので、末尾64ビット (数字で言って16桁) は自由に決められます。某メイド長にちなんで ::1341:398 とかやってみたり。
- WORD編集部のサイトのIPv6対応は、日本で30番目だそうです。
よんだ
6rd - Wikipedia
VPS(仮想専用サーバ)のさくらインターネット
6rd設定方法(Ubuntu10.10編)
さくらのVPSの Ubuntu 12.04 環境で IPv6 アドレスを使う
SSL中間証明書を改良してAndroidに対応させた
およそ3週間の間多忙で何もアウトプットできていなかったくりすです。
nginx
のSSL証明書をAndroid
上で信頼されないという報告を受けていたのですが、先程対応が完了したのでシェア。
問題
このnginx
上ではRapidSSLを採用しており、その親ベンダはGeoTrust, Inc.であるわけですが、この両者の中間証明書をインストールしないと、一部の端末では証明書が正しく使用できませんでした。
原因
2010年頃からRSA
(1024bit) は暗号強度上の理由から廃止されており、それに伴い諸CA証明書も2048bitに順次入れ替わっております。しかし、これに伴い互換性確保のために中間証明書のインストールが必須となるので、これを正しく設置していない場合SSLエラーが発生するわけです。
気を付けないといけないのは、RapidSSL
の場合はRapidSSL
の中間証明書と、その上位のGeoTrust
の中間証明書の両方が必要であるということです。
対策
RapidSSL
, およびGeoTrust
の中間証明書をそれぞれ入手します。
参考文献の3番目のテキストファイルは、この2つの証明書がバンドルになったものなので、それを引っ張ってくればよいでしょう。$ wget https://knowledge.rapidssl.com/library/VERISIGN/INTERNATIONAL_AFFILIATES/RapidSSL/AR1548/RapidSSLCABundle.txt
- 自分のサーバ用の証明書とこれらを連結します。
# cat /path/to/the/downloaded/RapidSSLCABundle.txt >> /path/to/your/ssl/cert.pem
nginx
を再起動します。# service nginx restart
これだけの手間でしたが、Android 4.0.3
で正常に読み込まれたことを確認しましたので、一安心。
NIST
の文書によると、今年の末までに1024bitのRSA
は廃止され、2048bitに移行するものとされています。
参考文献
- RapidSSLを使うとAndroidで証明書エラーが出た場合 | TechRacho
- RapidSSL - Knowledge Center - SSL Certificates Support
- https://knowledge.rapidssl.com/library/VERISIGN/INTERNATIONAL_AFFILIATES/RapidSSL/AR1548/RapidSSLCABundle.txt
- NIST Special Publication 800-131A - Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (PDF)