前回は、ssh のポートフォワーダと比較して、 VPN-Warp には次の特長があることを説明しました。
- ログインアカウントが不要
- アクセス対象はリレーサーバのみ
例えばローカルホストの 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 との間の通信が確立する、というわけです。
