PacketiX VPN 4.0の新機能を試す(3)
L2TP/IPsecとは
L2TP/IPsecと書きましたが、実際はそれぞれ別のプロトコルで、IPSecは暗号化、L2TPはカプセル化と思っていただければ問題無いのではないかなと。
詳細については書き始めると読むのが面倒なほどになるので割愛します。Wikipediaによくまとまってますよ。
実装の背景
これはあくまで推測ですが、Apple iOSの対応をするためではないかと推測されます。
Apple iOSではカーネルに触ることが通常は出来ないため、L2TP/IPSecを実装したのではないかなと。
使用方法
公式Webサイトに掲載されているのが一番わかりやすい気がするので省略します。
というか、全部に対して解説しているとやはり誌面が尽きます。
Tipsみたいなの
PacketiX VPN 4.0の新機能を試す(2)
はじめに
PacketiX VPN 4.0の新機能を試す(1)ではNAT-Tについてちょっとだけ解説しました。
第二回は、VPN Azureについて解説したいと思います。
VPN Azureとは
VPN Azureの公式サイトを見てもらえると良いと思いますが、簡単に言うとNAT内に居るVPN Serverと代理サーバが通信を行い、クライアントからの接続は代理サーバが受け持つことで通信を実現するのがVPN Azureです。
基本的には複雑な設定を要するMicrosoft SSTPを受けるためのサービスですが、一応VPN Clientからも接続が出来るようです。
使い方
公式サイトにて説明し尽くされているように見えるので割愛させていただきます。
VPN Azure Internal(?)
さて、このVPN Azureですが、https://DDNS名.vpnazure.netで接続すると、GeoTrustのワイルドカード証明書が使用されていることがわかります。おそらく、Microsoft SSTPの設定で必要になる自己証明書インストールなどの手間を減らすためでしょう。
また、PacketiX VPN Clientから接続するとUDP高速化が有効になるケースもあることから、前回説明したNAT-Tでの接続を優先的に行うような仕組みになっているようです。
おわりに
前回も説明したが、ファイアーウォールでのブロックはこちらも困難になっています。
恐らく複数の代理サーバが設置されているであろう状態のため、一つをアクセスコントロールしても他のサーバへ接続に行ってしまうことが考えられます。
また、VPN Azureを塞いだところでDDNS機能やNAT-T機能を封じていなければNAT-T機能により突破される可能性もあり、もし「PacketiXを止めたい！」と思っているので有ればVPN AzureとDDNS機能、NAT-T機能の三つを同時に封じる必要があるため、難易度はより高くなります。
次回は、IPSec/L2TPについてちょろっと書こうかなと思っています（予定）
PacketiX VPN 4.0の新機能を試す(1)
はじめに
国産VPNソフトウエアのPacketiX VPN 4.0のRCがついにリリースされたので、試しに使ってみる。
今回のバージョンアップでは、iPhoneと接続出来るIPSec/L2TPやEtherIP以外にもNATトラバーサル（以下NAT-T）やダイナミックDNS（以下DDNS）などの機能が実装されているが、今回はNAT-Tについてちょっと書いてみようと思う。
NAT-Tとは
Wikipediaを見て貰えば早いのだが、要するにUDPホールパンチングである。
元々UDP高速化機能（PacketiXではWAN高速化機能と言っている）が実装されているため、その延長線上にUDPホールパンチングを実装したのではないのだろうか。
動作の仕組みとしては、既知の第三者サーバ（恐らくソフトイーサ社が設置している）に対してサーバ側からパケットを投げると、NATサーバにそのエントリが残る。この時NATサーバの実装によっては、宛先IPアドレスとポートをちゃんと紐付けしていないこともある（このポートへのアクセスはどのホストからも許可するようになる）ので、これを利用して擬似的にポートを解放させている。
もちろんこの状態ではクライアントは接続先ポートを知らないので接続出来ない。そのため、クライアント側は「このホストに対応するポートはあるのか？」という問い合わせを第三者サーバに送り、得たポート番号を元に接続を行う。
これによりサーバとクライアントで一対一で接続が出来るようになり、高速な通信が可能になる。
実際に使ってみる
実験環境としてポート開放をしていないIX2015を用意し、その下にPacketiX VPN Server 4.0 RC1を配置した。
また、DDNS設定を行い、ホスト名にはexample.softether.net（仮名）を設定した。
この状態でPacketiX VPN Clientに設定を行う。DDNS名をホスト名に入力すると、ちょっと間を置いて仮想ハブが列挙された。まさにこの間にUDPホールパンチングが行われていたのである
（なお、NAT-Tの設定はデフォルトで有効になっているため、設定する必要は無い。）
設定を済ませて接続を行うと、すぐに接続が確立し、いつも通りVPN通信が出来る。
この状態でスループットを付属の「通信スループット測定ツール」を用いて測定した。設定は32セッション、上下、60秒間とした。
結果から言うと、100Mbpsを越えるスループット*1をはたきだした。
おわりに
つらつらとPacketiX VPN 4.0に搭載されているNAT-Tについて書いてきたが、これを防ぐのは大変難しい。
NAT-Tを防ぐには第三者のサーバを突き止めアクセスコントロールを行う必要があるが、現在の所第三者サーバは非公開のためパケットキャプチャを行うしかなく、第三者のサーバIPが変わった場合にも対応しなければならない。
また、NAT-Tを防いだとしてもVPN Azureという機能も実装されているため、ファイアーウォールでのブロックをより困難にしている。
そのVPN Azureについては、また次の機会に書こうと思っている。
*1:全二重通信のため
車載オフ2012に参加します
生きてます！！参加します！！
CX520Vにワイコンをつけるとボケる(2)
前のエントリで書き忘れたことがあったので書く。
どうすればいいのか
その場しのぎ的な解決方法は、先のエントリの通り。
だが、根本的な解決(つまり、内部プログラムの修正)を望むのであれば、サポートセンターに連絡するべきである。
他人が再現してるかどうかは書かなくていいので、自分なりに再現手順と症状を書いて、サポートセンターに相談してみよう。
本当にごくわずかの可能性だが、もしかすると修正されるかもしれない。
CX520Vにワイコンをつけるとボケる
ことの始まり
SONYのCX520Vを持っているのだが、CX520Vにワイコン(純正, VCL-HGE07A）をつけて
夜景や車載動画を撮影しようとすると全体がボケて撮影に支障が出てきた。（使い物にならないという意味もある）
再現条件
詳しく調べてみると、以下の設定にするとボケることがわかった。
- ワイコンを装着してある
- シーンセレクションが「夜景」や「風景」などのカメラが自動でフォーカスを固定するモードにする
- マニュアルでフォーカスを設定しない
この条件を満たせば、容易にこの問題は再現できる。
解決方法
この問題を回避するためには、マニュアルでちょうどいいフォーカスにフォーカス固定する必要があるのだが、ボケない焦点距離に設定するのが非常に面倒で*1、液晶が小さいために細部のフォーカスが確認できないのである。
修理センター、そして...
そこで、一抹の望みを掛けてSONYのサポートセンターに連絡したところ、詳しい再現状況と再現した映像が入っている本体を送ってくるように言われた。
で、修理に出した翌々日（つまり今日）修理センターから連絡があった。
修理センターでの調査結果は、以下の通りだった。
- 本体には問題がない。
- 内部ソフトウエア（ファーム）のシーンセレクションが、ワイコンを考慮していないのが原因
- ワイコンを考慮することになると他のワイコンのことも考えてフォーカスを決めなければならないので複雑になる
- 1週間とか1ヶ月程度でどうにかなる問題でもなく、修理センターだけでどうにかなる問題でもない。
- 当面はマニュアルフォーカスを設定することで回避して欲しい
- 修理センターとしてはこの問題を設計・開発部門にフィードバックしていく予定
- Webなどでもお知らせできるようにフィードバックをする予定
...とまぁ、悲しい感じの連絡だった。
私の修理を担当した人曰く、担当している限りでは初めてのケースということらしい。
さらに、新しいワイコンには注意書きが記載されているらしい、ということも聞いた。
が、最新モデルで修正されているかはわからないし、修正プログラムが出るかについての質問は答えることができないとのこと（それはそうだ）。
おわりに
とりあえず、この件は本体説明書にも書いてないのでここに書いておく。
ただ、修理センターからの連絡の下りからは''私の記憶だけ''を頼りに書いたので''鵜呑みにしないこと''。
他のカメラではテストしてないけど、この問題はCX500Vとか、XR500V,XR520Vでも再現するんじゃないか？
*1:MANUALリングにAFを割り当てて下にずるずると下げ続ける(0.1mとかそのくらい)とフォーカスが合う
