180 likes | 302 Views
特定ユーザーのみが利用可能な仮想プライベート・ネットワーク. 宇崎央泰 ( 東京工業大学 ) 千葉滋 ( 東京工業大学 ) 光来健一 (NTT 未来ねっと研究所 ). 仮想プライベートネットワーク( VPN ). 共有ネットワーク上に、ホスト同士を直接つなぐネットワークを仮想的に構築する技術. Passwd=4871. 3582. 4871. インターネット. 4871. ?. VPN の利用形態 (誰が利用可能か?). ネットワーク間接続型 接続されたネットワーク内の、全てのホストが VPN を利用可能 ホスト間接続型
E N D
特定ユーザーのみが利用可能な仮想プライベート・ネットワーク特定ユーザーのみが利用可能な仮想プライベート・ネットワーク 宇崎央泰(東京工業大学) 千葉滋(東京工業大学) 光来健一(NTT未来ねっと研究所)
仮想プライベートネットワーク(VPN) • 共有ネットワーク上に、ホスト同士を直接つなぐネットワークを仮想的に構築する技術 Passwd=4871 3582 4871 インターネット 4871 ?
VPNの利用形態 (誰が利用可能か?) • ネットワーク間接続型 • 接続されたネットワーク内の、全てのホストがVPNを利用可能 • ホスト間接続型 • 直接接続された2つのホストだけがVPNを利用可能 インターネット
より細かな制限が必要な場合 • マシンを多数のユーザと共有している場合 • 構築したユーザだけが利用可能なVPN • 既存VPNにはユーザ個々に対してアクセス権限を設定するという概念がない • 同一ホストからであれば、全てのユーザが使えてしまう web server uzaki kourai アカウント所持 process process process kourai:両方のサーバ uzaki:東工大サーバのみ NTT未来ねっと 研究所サーバ 東工大サーバ
現実的な対処 • アプリケーション毎にVPNを構築 • SSL(SecureSocketLayer) • 問題点 • 個々のアプリケーションが対応しなければならない • アプリケーション毎にセッションを確立しなければならず、資源を浪費しがち • 最初の認証は重い web server uzaki kourai process process process NTT未来ねっと 研究所サーバ 東工大サーバ
パーソナルVPN(PVPN)の提案 • IPパケットごとにユーザ認証を行うVPN • VPNの入り口でOSがユーザ認証を行う web server kourai uzaki process process process NTT未来ねっと 研究所サーバ 東工大サーバ
直接通信できないホスト間でのPVPN構築 • 互いのホストがプライベートIP、ファイアウォール内に存在 • 信頼できる中継ホストが必要 • ホスト間にPVPNを構築し、一本のPVPNになるようにルーティング ファイアウォール 直接通信できない uzaki uzaki process インターネット process ローカルネット ローカルネット プライベートIP プライベートIP
中継ホストがPVPNを構築するときのユーザ認証中継ホストがPVPNを構築するときのユーザ認証 • 中継ホストはPVPN構築時のユーザ認証も中継 • 中継のホストにプライベートキーを置かないため • 中継ホストすべてにプライベートキーを置くのは手間がかかる • さまざまなホストにプライベートキーを置くのは危険
PVPNの実装 • Linuxカーネル2.4.9に実装 • 暗号化とユーザ認証 • PVPNへのIPパケット送信処理 • PVPNからのIPパケット受信処理 • PVPNの連結(未実装)
暗号化と認証の実装方法 • SSLによる暗号化 • カーネルレベルで利用できる SSL [光来’01]を実装 • LibraryはOpenSSL • PVPN構築時にサーバ・ホストを認証 • ユーザの認証 • SSL通信路作成後、RSAによるユーザ認証をSSL上で行う
PVPNへの送信 • IPパケットの送信処理を行う関数に以下を追加 • 送信先IPアドレスから利用するPVPNを決定 • IPパケットの送信ユーザチェック • ユーザ認証後IPパケットをPVPNに流す kourai OS process IPパケット uzaki PVPN process IPパケット
PVPNからの受信 • PVPNを通ってきたIPパケットをIP層に渡す • 応答パケットを適切なPVPNに流す • 受信側もPVPNを利用できるとは限らない • 送信プロセスと受信プロセスのユーザが同じとは限らない kourai web server 同じユーザとは限らない process process インターネット OS OS
ユーザレベル版PVPNによる実験 • Divert socket を使った実装 • PVPN のオーバーヘッドを計測 • WebStoneベンチマークを利用 • Web server のスループットと平均レスポンスタイム • 以下の3つについて計測 • サーバーとクライアントが直接通信:Normal • PVPNを通して通信(暗号化無し):Noencrypt • PVPNを通して通信(暗号化有り):Encrypt
実験結果 • PVPNを使うと10倍から数百倍遅くなる • 100倍以上遅い場合は、タイムアウトによるパケットの再送が頻繁に発生していた • IPパケットインターセプトのオーバヘッドが大きい • 実装をカーネル内に行うことで改善可能 実験環境 ClientPentiumⅡ400MHz Memory384MB ServerAthlonXP1800+Memory640MB 100Mbpsのイーサネット FileSize(Kbyte) グラフ:Throughput 1000 Normal 10 Noencrypt Encrypt 1 100 1000 10000 (Kbyte/sec)
カーネル版PVPN (実装中) • PVPNを利用したUDP通信のスループットを計測 • 実験環境 • ユーザレベル版と同じ • IPパケットのサイズは1052バイト • 結果 • PVPNを利用:0.052Mbyte/sec • カーネルレベルSSLによるTCP通信:1.24Mbyte/sec • 通常のUDP:6.2Mbyte/sec • PVPNのオーバーヘッドにより速度は約25倍遅くなる • チューニングが必要
関連研究 • IPsec • VPN構築のときホスト間の認証が行われる • L2TP • トンネル構築時にPAP、CHAPなどによるユーザ認証 • SSHのポートフォワーディング • SSHでログインするときにユーザの認証を行う
まとめ • パーソナルVPNを提案し、その機能の一部をLinuxカーネルに実装した • IPパケットごとにユーザ認証を行うVPN • OSがユーザ認証を行う • 直接通信できないホスト間でもPVPN構築可能 • 信頼できる中継ホストがルーティング • ユーザ認証は中継ホストでは行わない
今後の課題 • カーネルへの実装を行ったが、まだうまく動作しない部分やパフォーマンスに問題があるので、改善する • PVPNの連結は設計はできているが、まだ未実装なので、実装を行う