Tunnel/Reverse Tunnel over websocket を作った

tunnel 間の通信がインターネットを経由する場合、セキュリティには十分注意すること。

• tunnel client/server 間通信の暗号化や、client 認証を実装しているが、 tunnel 内の TCP セッションは raw な tcp 接続をせずに、 ssh などで接続すること。
• tunnel server は常駐させず、必要な時にだけ起動するように運用すること。
• pass , encPass オプションを必ず指定し、適切な期間で変更すること。
• ip オプションを指定し、接続可能な client を制限すること。

次のコマンドを実行することで、 tunnel ディレクトリ内に tunnel コマンドがカレントディレクトリに生成される。

$ git clone --depth 1 https://github.com/ifritJP/kptunnel.git
$ cd kptunnel
$ make build

kptunnel コマンドは tunnel server と、 tunnel client の両方の役割を持ち、 オプションで切り替える。

kptunnel コマンドは、次の書式をもつ。

$ kptunnel <mode> <server> [forward [forward [...]]] [options]

• mode

  • 次のいずれかを指定する

  • サーバ

    • wsserver
    • r-wsserver
    • server
    • r-server

  • クライアント

    • wsclient
    • r-wsclient
    • client
    • r-client
  • "r-" が付くものは、 reverse tunnel である。
  • ws が付くものは、 over websocket である。

  • ws が付かないものは、 tcp で直接接続する。

    • tcp による接続は、実験的なサポートである。
    • tcp で接続できる環境なら、 このツールを使わずに ssh した方が良いだろう。
  • "r-", "ws" は client/server で一致している必要がある。

• server

  • server を示す。

  • サーバ側で指定する場合は、開放するポートを指定する。 (:1234 or localhost:1234)

    • この port に接続可能なネットワークを制限する場合は、 そのネットワークを指定する。 例えば localhost に制限する場合は localhost:1234 として指定する。
  • クライアント側で指定する場合は、ホスト名を含めて指定する (hoge.com:1234)

• forward

  • tunnel で転送するポートの情報。
  • forward は複数指定できる。
  • server 側に forward が指定されている場合、 client 側の設定は server 側の設定で上書きされる。
  • "localのポート,forward先のポート" の書式で指定する。
  • localのポートに接続可能なネットワークを制限する場合は、 そのネットワークを指定する。 例えば localhost に制限する場合は localhost:1234 として指定する。

  • forward 先のポート情報は、相手にそのまま伝わる。

    • 例えば reverse tunnel で localhost を指定した場合、localhost は tunnel クライアント自身になり、 通常の tunnel の場合、 localhost はサーバ自身になる。

  • forward の書式は old_forward と new_forward の 2 つの書式がある。

    • old_forward は、 local-port,remote-port の書式で指定する。

      • ここで reverse-tunnel の場合、 local-port はサーバ側の host:port を指定し、 remote-port はクライアントからアクセスする host:port を指定する。
      • tunnel の場合、 reverse-tunnel と逆になる。

    • new_forward は、 <r|t>,old_forward の書式で指定する。

      • ここで r は、 old_forward を reverse-tunnel として指定する。
      • ここで t は、 old_forward を tunnel として指定する。
    • つまり、old_forward は転送設定を mode 指定に従うのに対し、 new_forward は forward 設定毎に tunnel, reverse 設定を行なうかの違いである。

    • さらに言えば、 new_forward 書式を利用すると、 mode の tunnel, reverse の違いは意味がない。

      • mode の reverse (r-client, r-server 等)は、互換性のために残しているが、 将来は削除する可能性がある。

次に代表的なコマンド例を示す。

• server

server のコマンド例を示す。

$ kptunnel r-wsserver :6666 :8001,localhost:22 -pass XXXXXXX -encPass YYYYYYYY

これは次のサーバの実行を指定している。

• client

client のコマンド例を示す

$ kptunnel r-wsclient hoge.hoge.com:80 -proxy http://user:pass@proxy.hoge.com:8080/ -pass XXXXXXX -encPass YYYYYYYY

これは次のクライアントの実行を指定している。

• tunnel への接続

上記のサンプルは localhost の 22 番ポートに接続するための reverse tunnel を構築している。 つまり、このサーバ側の 8001 ポートに繋げると、 client 側の ssh に接続されることになる。

よって、サーバ側で次のコマンドを実行することで、クライアントの ssh に接続できる。

$ ssh -p 8001 localhost

dispatcher は、 client から接続要求を受けると次の処理を行なう。

• 接続要求の uri, http header をもとに、 その接続要求を受け付けるかどうかを判定する (canAccept)
• 接続要求を受け付ける場合、 その client に対応する server の起動パラメータを決定する (getTunnelInfo)
• server を起動する
• 起動した server に、 client からの接続要求を転送する

これにより、 dispatcher を介して client と server が接続される。

dispatcher は、 tunnel client の要求毎に起動する tunnel server の構成を変更する。

この tunnel server の具体的な制御は、ユーザによって異なる。

この制御のカスタマイズは、 LuneScript のコードによって行なう。

LuneScript のコードは、次の 2 つからなる。

• CanAccept.lns

  • 非 排他処理
  • 接続要求の uri, http header をもとに、 client からの接続要求を受け付けるかどうかを判定する
  • この処理は 非 排他処理で、 client のリクエスト毎に複数同時に動作する
  • 1リクエスト毎に、 独立 した VM 上で動作するため、 オブジェクトが毎回初期化される

• UserHandler.lns

  • 排他処理

  • 次を処理する

    • client からの接続要求を受け付けた後の、サーバ構成を決定する
    • 切断後の処理
  • この処理は、排他処理で、client のリクエスト毎にシーケンシャルに動作する
  • 全てのリクエストで 共通 した VM 上で動作するため、 全てのリクエストでオブジェクトが保持される

dispatcher/lns/user/sample/

dispatcher の起動コマンドオプションを示す。

$ ./dispatcher wsserver

Usage: ./dispatcher wsserver <server> [option] 

   server: e.g. localhost:1234/path or :1234

 options:
  -console string
    	console port. (:1234)
  -ip string
    	allow ip range (192.168.0.1/24)
  -u string
    	userHandler path. (ex: handler.lns,canAccess.lns)
  -verbose
    	verbose. (true or false)

次は、 localhost の 10000 ポートの /path に dispatcher を立ち上げ、 カスタマイズ処理として lns/user/UserHandler.lns lns/user/canAccess.lns を指定している。

./dispatcher wsserver localhost:10000/path -u lns/user/UserHandler.lns,lns/user/canAccess.lns

この Tunnel ツールは、主に次の 6 つのスレッドで構成される。

• tunnel session 制御
• WriteQeue → tunnel のパケット送信制御 (packetWriter)
• tunnel → ReadQueue のパケット受信制御 (packetReader)
• ReadQueue → host のパケット転送制御 (tunnel2Stream)
• WriteQeue → tunnel のパケット転送制御 (stream2Tunnel)
• 無通信が一定時間続かないようにするダミーパケット送信制御 (keepalive)

スレッド多す過ぎという気もするが、 メニーコア時代な現代であれば、 少ないスレッドで複雑なコードを書くよりも、 処理毎にスレッドを分けた方がメンテナンス性も性能も良いんじゃないだろうか？

下図は、各スレッドの役割を図示している。

digraph G {
rankdir = RL;

tunnel [shape=doublecircle];
subgraph clusterA {

packetWriter [shape=rect; margin=0.2;];
packetReader [shape=rect; margin=0.2;];
keepalive [shape=rect; margin=0.2;];

WriteQueue

tunnel2Stream [shape=rect; margin=0.2;];
stream2Tunnel [shape=rect; margin=0.2;];
ReadQueue

{rank = max; packetReader; packetWriter}
{rank = same; WriteQueue; ReadQueue}
{rank = min; tunnel2Stream; stream2Tunnel; keepalive}
}
host [shape=box3d];

tunnel -> packetReader
packetReader -> ReadQueue
ReadQueue -> tunnel2Stream
stream2Tunnel -> WriteQueue 
WriteQueue -> packetWriter
packetWriter -> tunnel
keepalive -> WriteQueue
tunnel2Stream -> host
host -> stream2Tunnel

{rank=min;host}


}

• packetReader は tunnel からデータを読み取り ReadQueue に送る
• tunnel2Stream は ReadQueue からデータを読み取り host に送る
• stream2Tunnel は host からデータを読み取り WriteQueue に送る
• packetWriter は WriteQueue からデータを読み取り tunnel に送る
• keepalive は WriteQueue にダミーデータを送る

digraph G {
rankdir = RL;

tunnel [shape=doublecircle];
subgraph clusterA {

packetWriter [shape=rect; margin=0.2;];
packetReader [shape=rect; margin=0.2;];
keepalive [shape=rect; margin=0.2;];

WriteQueue

CITI1 [shape=component; margin=0.2;];
CITI2 [shape=component; margin=0.2;];


{rank = max; packetReader; packetWriter}
{rank = same; WriteQueue; }
{rank = min; CITI1; CITI2; keepalive}
}
host1 [shape=box3d];
host2 [shape=box3d];

tunnel -> packetReader
WriteQueue -> packetWriter
packetWriter -> tunnel
keepalive -> WriteQueue

packetReader -> CITI1
CITI1 -> host1
CITI1 -> WriteQueue 
host1 -> CITI1

packetReader -> CITI2
CITI2 -> host2
CITI2 -> WriteQueue 
host2 -> CITI2

{rank=min;host1;host2}


}

tunnel が切断されても、 tunnel を再接続すれば tunnel 内に流れる tcp セッションは継続通信可能である。

ただし、tcp 通信のタイムアウト以内に再接続できることが条件である。

tunnel を再接続すれば tcp セッションは継続通信可能だ。 しかし、そう単純にはいかないケースがある。 それは『送信したつもりになっているパケットが、相手に届いていないことがある』からだ。 この場合、相手に届いていないパケットを送信しなおす必要がある。

「tcp は udp と違って再送制御などを行なって信頼性を確保しているんじゃないのか？」 と思う人もいるだろう。私も最初はそう思っていた。 しかし、実際はそうではない。 なぜなら、再送制御などはあくまでも TCP セッションが続いている場合に行なわれることで、 TCP セッションが切断された場合は再送制御なども当然破棄される。

つまり、強制的にセッションが切断された場合は、 送ったつもりのデータが相手に届いていないことが普通にありえる。

このような「送ったつもりが相手に届いていないデータ」がある場合、 TCP セッションを継続させるにはそのデータを再送してやる必要がある。 この再送処理は、 packetWriter スレッドが実行する。

participant stream2Tunnel_client
participant packetReader_client
participant packetWriter_client
participant packetWriter_server
participant packetReader_server
participant tunnel2Stream_server


stream2Tunnel_client -> stream2Tunnel_client : check the count send packets.
stream2Tunnel_client ->> packetWriter_client : write the packet to client queue
packetWriter_client ->> packetReader_server : write the packet
packetReader_server ->> tunnel2Stream_server : read the packet to server queue
tunnel2Stream_server -> tunnel2Stream_server : count received packets.
tunnel2Stream_server ->> packetWriter_server : write the sync to server queue
packetWriter_server ->> packetReader_client : write the sync

digraph G {
rankdir = TB;

node0 [shape=rect; label = "buf"]
node1 [shape=rect; label = "buf"]
node2 [shape=rect; label = "buf"]
node3 [shape=rect; label = "buf"]
node4 [shape=rect; label = "buf"]
node5 [shape=rect; label = "buf"]

node0 -> node1
node1 -> node2
node2 -> node3
node3 -> node4
node4 -> node5
node5 -> node0


{rank=same; node1;node5}
{rank=same; node2;node4}
}

ここでは tunnel client/server 間で通信を開始する時の protocol について説明する。

protocol は 3 つの情報をやり取りする。

participant server
participant client

server ->> client : AuthCallenge
server <<- client : AuthResponse
server ->> client : AuthResult

この protocol の後は、-port オプションで指定されたポートをリスニングし、 アクセス毎に TCP 接続セッションを開始する。

この Tunnel ツールの開発には、次の技術が不可欠である。

• TCP
• Proxy Client
• HTTP Client/Server
• WebSocket Client/Server

これら技術との相性の良さという意味では、 node.js が一番始めに候補に上りそうな気がする。 しかし、今は Go の勉強中ということもあり Go で開発を行なった。