Search on the blog

2011年9月17日土曜日

P2P通信NAT超え調査メモ

前回、Javaでソケット通信をして遊んだ。
簡単なP2Pチャット(片方のノードがグローバルIPを持っている OR LAN内での使用限定)を作ってみたり、接続したリモートPCを遠隔操作して遊んだりしたけど、やはりNATを超えたい衝動が抑えられないので、ちょっと勉強してみた。
調べた感じだと、たぶん自分で実装できそう。

今後のためにメモしておく。

[リンク集]
NATの仕組み、パケットのヘッダデータ書き換え
http://www.n-study.com/network/nat.htm

IPマスカレード(NAPT)
http://www.asi.co.jp/techinfo/unix/nat.html

NATトラバース(STUN)
http://www.itmedia.co.jp/enterprise/articles/0505/30/news070_3.html

ルータのタイプいろいろ
http://www.skame.nu/P2Pmeeting/0409sunouchi.pdf

Full Cone 開いたポートに送られるパケットは送信元がどこでも受け取る
Restricted Cone 送ったことのあるIPアドレスから送られるパケットのみ受け取る
Port Restricted Cone 送ったことのあるIPアドレス/ポートから送られてくるパケットのみ受け取る
Symmetric 最初に送った宛先以外からは受け取らない (同一ソケットから別の宛先に送った場合は、ルータに別のポートがマップされる)

[考えたこと]
P2PでNATの奥の端末同士が通信している間も、STUNとの通信はオープンになっている?
一度、STUNサーバーにつなげば、通信したい相手側のルーターのglobal IP、portが分かるので、
そこに捨てパケットをなげてやる。これで、次回からは通信可能となる。
-> Restricted Cone、Port Restricted ConeでもNAT超えられる。
P2P間で接続ができたら、その時点でSTUNサーバーとのコネクションはクローズしてもいいように思える。
開けたままだと、通信の内容がSTUNサーバーにも漏れてしまうことになりそうなので、
プライバシーの問題からおそらくクローズするの妥当だろう。この辺は実験して確認する。symmetricでは、NAT traverseは無理。

0 件のコメント:

コメントを投稿