仙石浩明の日記

2006年4月18日

VPN-Warp 入門編 (3)

前回は、ssh のポートフォワーダと比較して、 VPN-Warp には次の特長があることを説明しました。

  1. ログインアカウントが不要
  2. アクセス対象はリレーサーバのみ

例えばローカルホストの 8080番ポートを、 リモートの intra:10080 へフォワードする場合、 次のように、ローカルホストで stone を、リモートホストで relayagent を、 それぞれ走らせます。 

ローカルホスト         リレー           リモートホスト
    stone ─────→ サーバ ←──── relayagent─→ intra
  8080番ポート …………………………………………………→ 10080番ポート

stone も、relayagent も、リレーサーバに対しては 「クライアント」であることに注意してください。 また、ローカルホスト、リモートホスト、リレーサーバ、 いずれにおいても、ssh の場合のようなログインは必要ありません。

必要なのは、SSL クライアント認証だけで、 stone/relayagent はクライアント証明書を使って リレーサーバへアクセスする、というわけです。 実際、リレーサーバは stone/relayagent にとって、 普通の https サーバのように見えます。 リレーサーバは、stone/relayagent 双方から SSL 接続を受付け、 もし同一のクライアント証明書を持っている組があれば、 それらを結び付ける役割を果たします。

具体的な設定方法

stone/relayagent それぞれの具体的な設定方法を見ていきましょう。

stone の設定

stone の設定ファイルは次のような感じになります: 

-q key=private.pem
-q cert=cert.pem
relay.klab.org:443/ssl,http localhost:8080 "GET / HTTP/1.1" --
  • -q key= から始まる行は、SSL 証明書の秘密鍵ファイル、
  • -q cert= から始まる行は、SSL 証明書の公開鍵ファイルの指定です。
  • relay.klab.org:443 はリレーサーバの指定、
  • 最後の localhost:8080 がローカルホストで listen するポートの指定です。

このような設定を行なうと、 stone は 8080番ポートで受けた接続を、 「https リクエストに乗せて」リレーサーバへ転送します。

「https リクエストに乗せて」というのはどういうことかというと、 例えば 8080番ポートに接続して「abcdefg」というデータを送信したとすると、 stone は以下のようなデータを、SSL で暗号化してリレーサーバへ送ります: 

GET / HTTP/1.1

abcdefg

あまり「https リクエスト」のようには見えませんが (^^;)、 最初の一行がリクエストヘッダで、 空行をあけて、リクエストボディが続いている、と見なすこともできます。

実をいうとリクエストヘッダ (のようなもの) を送り終わった時点で、 任意のデータの送受信が可能で、 送信したデータデータはそのまま relayagent へ伝わります。 つまり、 8080番ポートが、relayagent へフォワードされる、というわけです。

relayagent の設定

relayagent の設定ファイルは次のような感じになります: 

-n
-k private.pem
-c cert.pem
relay.klab.org:443
intra:10080
  • -n は、relayagent をポートフォワーダとして使う、という意味です。
  • -k から始まる行は、SSL 証明書の秘密鍵ファイル、
  • -c から始まる行は、SSL 証明書の公開鍵ファイルの指定です。
  • relay.klab.org:443 はリレーサーバの指定です。
  • 最後の intra:10080 がポートフォワード先の指定です。

このような設定で relayagent を実行すると、 relayagent は、リレーサーバに対して以下のような「ポーリング」を https を装って行ないます。 

GET /KLAB/poll HTTP/1.1
X-Ver: 2 relayagent.cpp,v 1.32 W (TAKUMI)

「X-Ver:」の次の数字「2」で、relayagent - リレーサーバ間の プロトコルのバージョン番号を伝えています。 続く「relayagent.cpp,v 1.32 W (TAKUMI)」は単に relayagent のバージョンを (トラブル時の解析用として) 伝えているだけで、通常は参照されません。

このリクエストヘッダ (のようなもの) を送り終わると、 リレーサーバは次のようなレスポンスを返します: 

HTTP/1.1 200 OK
X-Customer: nusers=10&type=3&expire=1262271599&digest=0123456789abcdef0123456789abcdef

この、https レスポンスヘッダ (のようなもの) を受信した後、 relayagent はレスポンスボディ待ち状態 (ポーリング状態) になります。 この状態の時、 同じ証明書を持つ stone からの接続があると、 その情報がレスポンスボディとして送られてきて、 relayagent はそれを受けて intra:10080 へ接続を行ない、 stone と intra:10080 との間の通信が確立する、というわけです。

Filed under: システム構築・運用 — hiroaki_sengoku @ 16:42

3 Comments »

  1. こんにちは。
    糸山＠ジオです。
    今Telnetサービスのトネリングにチャレンジしています。
    設定ファイルに関して疑問があります。
    stoneの設定ファイルにコメントを入れたい場合、どうしたら良いのでしょうか？
    relayagent同様、#で良いのですか？

    Comment by itoyama@geotrust — 2006年4月28日 @ 14:22

  2. stone のコメントは行頭に # をつけるのが本来の方法なのですが、Linux をはじめとする Unix 版では設定ファイルを cpp (C プリプロセッサ) を通してから使うのが一般的なので、cpp を通す場合は C と同じコメント方法、すなわち /* … */ になります。cpp を通す場合は、行頭に # をつけると cpp が警告を出すので注意が必要です。

    Comment by 仙石浩明 — 2006年4月29日 @ 08:10

  3. こんにちは。
    なるほど。ありがとうございます。注意します。
    すみません、設定ファイルに関してもう一つ。
    RelayAgentの設定ファイルで”-n”を設定してサービスを起動すると”サービスは予期せず終了しました”とエラーがイベントビューアに表示されます。Windowsバージョンの場合このオプションは無効だと考えて宜しいでしょうか？

    Comment by itoyama@geotrust — 2006年5月1日 @ 17:20

RSS feed for comments on this post.

Leave a comment