sshコマンドだけで多段ログインする

NAT内のホストなど、ゲートウェイを経由して多段sshログインする技についてです。

emobile GP02 (GMOとくとくBB) を導入した件

docomoのデータ通信をBF-01Bでつかってて、だいぶつらいなーと思っていたのだけれど、
つらつらとはなくろさんのブログ見てたらemobile気になったので検討した結果導入に至った。

キャッチオール

すべてを受け止める。
いい響きですね。

この度、メールアドレスの拡張アドレスをやめて、ローカルパートがなんであってもすべて受け取るようにしました。

Cancellation InfoSphere IP8 (2)

なんか最低利用期間に満たってないらしく。
あと1ヶ月使ってくださいと。

おかしいなぁ08/8月加入で7月で12ヶ月じゃんっていったら、加入月は無料なんで12ヶ月にはたりないんだと。
要するに12ヶ月分の料金は払えということすね。

そんなわけで8月末解約になった。

すでに環境は ipp.jp の IP1個コースに移行済みである。

Cancellation InfoSphere IP8

ということで。
IPは1個で足りる気がしてきたのでInfoSphereのIP8は解約することに。

実際、3つしか有効活用していなかったし、ひとつをDDNSで、もうひとつをルータからのDNATで賄えば dynamic(1) + static(1) の2つ(2契約)あればたりるでしょう、と。

ほとんどのネットワーク設定はすでにIP1モードに以降済み。
固定IP1はwakwakあたりで検討中。

nscd and getnameinfo

nscdがなんかへん。

% ruby -rsocket -e 'p Socket.getnameinfo([nil, 80, "127.0.0.1"])'
["localhost.localdomain", "80"]
% sudo /etc/init.d/nscd stop
Stopping Name Service Cache Daemon: nscd.
% ruby -rsocket -e 'p Socket.getnameinfo([nil, 80, "127.0.0.1"])'
["localhost.localdomain", "www"]
% dpkg -s nscd | grep "^Version"
Version: 2.7-9

うーん？

Is UHP really required?

そもそも、プロトコルを全部UDPでやれば、初期接続がクライアントからであるかぎり、UHPなんて考えなくてもいいのではなかろうか。

再送とかのチェックがめんどうではあるけども、それはデータ転送においても同じわけで。
まぁUHPつかえないルータの場合の考慮はどうすんだという問題もあるが、そのへんは要件次第か。

UDP Hole Punching その２

どうやら昨日書いた手法は特許とられてるらしい。ひどい話である。
・TCPでなんらかのデータ送信の後、UDPで補足データを送信する
という請求事項にひっかかるのだとか。(特許公開番号:2007-502585)

まぁいろいろ考えたが、最初のTCPによるセッション初期化をUDPでやっちまえばいい気がしてきたので、次のように変更。

1. C UDP::UHPInitialize -- NOP
2. S UDP::UHPInitializeOK -- SESSIONID < UNIQUE ID >
3. C TCP::UHPComplete -- FLAG < 0(FAIL) | 1(SUCCESS) >[, SESSIONID < UNIQUE ID > ]
4. S TCP::UHPCompleteOK -- NOP

まぁいいんでないかなあ。初期化失敗したら知らんぷり or TCPで続ける。
あとUHPを行う場合、クライアントのUDPソースポートも固定(bind())しておかないといつのまにか通信できなくなる可能性があるので注意すべき。
あとほんとに目的のサーバから送られてきたかどうかのチェックとか。

UDP Hole Punching

仕事でUDPのデータストリームを扱っていて、さらにクライアントはNAT超えを考慮しなくてはならないということで、UDPのNAT超えでよく使われる手法、UDP Hole Punching (UHP) というものを実装することになった。

UDP Hole Punchingというのはルータに動的に空けられたNATテーブルの穴を逆から叩くことにより、NATの中のクライアントとUDP通信を可能にする技術であるからして。

さて、TCPのコントロールコネクションはもともとあるので、そのプロトコル上に UHP のネゴシエーションを付け加える形にした。

1. TCP C: UHPInitialize <NOP>
2. TCP S: UHPInitializeOK <SESSION ID> <SERVER UDP PORT>
3. UDP C: UHPRequest <SESSION ID>
4. UDP S: UHPRequestOK <NOP>
5. TCP C: UHPComplete <SUCCESS | FAILED>
6. TCP S: UHPCompleteOK <NOP>

3と4で UDP Hole Punching を行うわけだが、UDPなのでロストするかもしれない。なので両者とも数回再送を試みる。
最終的に、クライアントが4の UHPRequestOK を受け取る事ができればUHPは成功であり、
5 の UHPComplete で SUCCESS を返すわけである。

3もしくは4をロストしたり、そもそも UHP が不可能な NAT 環境であった場合、FAILEDを返すことにより TCP へ Fallback するなりなんなりするようにする。といった寸法である。

以上のシーケンスをRubyでテストコード書いて(仕事のコードなので公開はできないが)実行してみたのだが、うまくいかない。
NAT なしの LAN内であれば動くのでアルゴリズム的な部分は間違ってない(と、思う)。

ルータが特殊なのかと思っていたのだが、帰宅途中で罠に気がついた。

実は、テストしているサーバは複数の Network Interface をもっている。
アドレスがプライベートで NAT の中にある eth0 と、実験でつかっている(つもり)のグローバルアドレスを持つ eth1 であり、default route は eth0 の NATルータである。

そして、サーバでudp socketがbind() しているアドレスは '0.0.0.0' である。
つまり、クライアントがグローバルアドレスに sendto()し、サーバが recvfrom() により取得したした client socket address へ sendto() を返す場合、サーバの source addres はカーネルが勝手に決めているのであり、基本的に default routeが使われるわけだから、eth0のプライベートアドレスになってしまう。
要するにサーバもNAT内あるものとして動作をしていた、というわけなのである。
UHP は NAT(client)からNAT(server) では仲介サーバが居ない限り不可能である。

今回はそういったケースは考慮しないので、素直にサーバの bind address をグローバルなものにして再実験をしたところ、うまく動作した。

教訓。udp socket を '0.0.0.0' に bind()してlistenするときは複数の interface や routing がないか注意しよう。