株式会社TTMエンジニアリング株式会社TTMエンジニアリング 〒550-0002 大阪市西区江戸堀1丁目6-13 肥後橋堀田ビル603号 
TEL:06-6479-1315 FAX:06-6479-1311 
ホーム 会社情報 会社情報 商品情報 技術サポート お問い合わせ
  HOME > 技術サポート > ユーザスペースVPNとOpenVPN サイトマップ  
SSL-VPN機能を標準装備した新たなインターネットVPNの世界へ
ImageStream

ユーザスペースVPNとOpenVPN

歴史、概念の基礎と実践から見たユーザスペースVPN

この資料はLinuxFestNorthwest2004でOpenVPNProjectの創設者JamesYonanが
発表したプログラムノートの日本語訳です。
また、OpenVPN概要資料として「OpenVPN理解のために」も参考としてください。
原文 Understanding the User-Space VPN: History, Conceptual Foundations,
and Practical Usage:http://openvpn.net

VPNとは何か?または他のセキュリティソフトウェアとどう違うのか?

・基本的に、VPNは異なった場所でのネットワークを公衆ネットワーク(インターネット)
 を通してトランスポート層として安全に接続することのできるツールセットです。

・VPNは盗聴や積極的攻撃に対して防御するために暗号書式を利用します。

・VPNは今日では一般的に自宅からのリモートアクセスや安全なWANを通じて支店と
 結ぶ用途として利用されています。

VPN以前の広域ネットワーク

・企業は本支店間を独自で専用線を用いて接続し毎月高額な費用を支払っていました。

・インターネットの進歩は通信を低額化しましたが、帯域はセキュアではありません。

・VPNの概念は仮想的に専用線を作ることでインターネット上にデータを流し込み暗号書式を
 利用することでセキュアなネットワークを実現しました。

VPNの簡単な歴史

・IPSecは安全なネットワーク標準を開発するために最初の主要な成果でした。

・最初のバージョンは1995年

・他の初期の暗号開発のように、IPSecは外からの制限やIPSecが実行されるルータのプロセッサのパワー不足によって
挫折していました。

・IPSecのいくつかのコンポーネント例えばIKEは未だに今日でも開発途中です。非常に長い開発期間です!

IPSecの持つ問題

・90年代半ば、開発過程の遅さで様々な開発成果が分裂しました。

・SSLはその派生物のひとつで、ネットワークレベルのセキュリティというより、
アプリケーションレベルでのセキュリティを配布するために開発されていました。

・伝統的なIPSec製品は膨大なカーネルコードの取り扱いを要求し、相互プラットフォーム
互換を複雑にしていました。

・IPSecは新しいユーザにとっては険しく学習しないと理解できない複雑な製品です。

SSLの台頭とユーザスペースVPN

・IPSecの進まない歩みと複雑さは多くの人を他のソリューションへ向ける事になりました。

・それに対して、SSLはWebの利用によって急速に成長しました。

・SSLがユーザスペース内の中で作動し、実行と管理を簡単にしました。

・SSL-VPNというところのVPNはユーザが複雑なVPN技術すべてを知らなくても、必要なサービスをユーザーに提供する
 正にウェブアプリケーションそのものです。

Linuxと仮想ネットワークインターフェース

・90年後半、LinuxOSの急速な発展は、実験的ネットワーク構築の概念に対して優れたテスト環境を与えました。

・"tun"あるいは"tap"インターフェースはそのような革新のひとつです。

・Linuxでの最初のtunドライバはマキシム・クラスニャンスキーによって書かれました。

tunインターフェースとは何か?

・tunインターフェースはOSへのポイントツーポイントネットワークハードウェアのような仮想ネットワークアダプタです。

・ワイヤへビットを流し込む代わりに、tunドライバはユーザスペースへそれらを流します。T1回線のようなもの。

・ユーザスペースプログラムはちょうどファイルのようにtunドライバを開くことができて、IPパケットを読んだり書いたり
 することができます。

・“tap”インターフェースもよく似た製品ですが、ただポイントツーポイントというよりむしろイーサネットに匹敵するものです。

tunインターフェースはどのようにVPNを構築するのか?

・tunインターフェースをマシンAと別のマシンBに持たせてみます。

・では2つのスレッドで簡単なネットワークアプリケーションを書きます。

・tunデバイスから->ネットワークソケットへビットをコピーします。

・ネットワークソケットから->tunデバイスへビットをコピーします。

・もし、このアプリがマシンAとマシンBで動くなら、とても簡単なVPN(セキュリティのない)を構築したことになります。

tunインターフェースはどのようにVPNを構築するのか?続き

・AからBのtunデバイスへPINGでき、またBからAのtunデバイスへPINGできます。

・そのPINGが実際にソケット接続上で行きかい返答しているでしょう。
 例えばPINGパケットはUDPやTCPパケット内でカプセル化され、AB間へ送られます。

・このとても簡単なVPNの問題点は、セキュリティがないということです。それはCleartextトンネルとして知られています。

VPNにセキュリティを追加してみましょう

・今回構築した簡単なVPNはTCPまたはUDPコネクション上で仮想ネットワークインターフェースをトンネルします。

・SSHのようなセキュアなポートフォワーディングツールでTCPコネクションを転送することによって、本当のVPNを構築できます。

VPN構築するためにSSHを用いることの問題点

・しかし、前回の例は問題があります。

・IPは“信頼のない”プロトコルです。

・これは正当な判断とはいえないでしょう。

・むしろ、IPは物理的または仮想ネットワークを通して送られたパケットが消失あるいは改ざんされているかもしれないと
 見られる事を意味します。

・TCPのようなIPファミリのプロトコルはこのような仮定で機能するのは非常に困難です。

「信頼のある」そして「信頼のない」プロトコル

・TCPは信頼のないトランスポート層を利用する信頼のあるアプリケーションプロトコルです。

・このことは、WEBブラウザ(HTTPはTCPプロトコル)があなたのクライアントと出来るだけ遠くにあるWEBサーバ間を接続中で  生じる障害をTCPが処理することを期待するようなものです。

・TCPはこのことをネットワーク障害によって消失したパケットを再送することによって行います。

・TCPはアプリケーションと物理ネットワーク層間で信頼のある架け橋です。

プロトコルをカプセル化する

・ネットワークでクールなことのひとつはあるプロトコルを採って他のプロトコルへカプセル化できることです。

・先ほどのVPN構築事例に戻りましょう。IPをTCPポートへカプセル化し、他のリモートホストへTCP接続を確保
 するためにSSHを利用します。

・カプセル化に関しては、IP(UDP、TCPプロトコルを含む)をTCPにカプセル化しています。

TCPをTCPにカプセル化する-その問題点

・しかしこのカプセル化方式は根本的な問題があります。

・TCPは信頼のないネットワーク上で流れる様に設計されています。
 TCPをTCPへ流しこむということは信頼のある層をも一つの層に重ねることで、本質的には全冗長レベルを作成することです。

・この冗長は混雑したネットワーク状況で非能率的で、堅牢でないものに置き換わります。

その問題の改善

・より良い解決はTCPをUDPにカプセル化することです。

・UDPはTCPの"信頼のない従兄弟"です。TCPの包括した信頼のある層を取り去り、消失したパケットやまちまちに到達したパケットの問題をそれらがどのように送られてきたかからみてより分ける責務をアプリケーションに付加します。

なぜIPのカプセル化にUDPが良いのか?

・根本的な理由はIPが障害や混雑を蒙るすべての信頼のない物理メディアである回線、光ケーブル、無線上に流れるように設計されているからです。

・UDPはそれ自身信頼のないプロトコルなので、固有の環境に限りなく近い伝送媒体をIPに求めます。

・UDPでIPをカプセル化することは理想的な選択です。

VPNとUDP

・現代的、ポータブル、簡単設定であるユーザスペースVPNはいくつかの基本的なプロパティを持っています。

・tunやtap仮想ネットワークアダプタからのIPパケットはUDP接続の上で暗号化され、「カプセル化」されてインターネット上のリモートホストへ送られます。

・そのリモートホストはそのIPパケットを復号、認証し、カプセルを外して他の端にあるtunやtap仮想アダプタへ流し込みます。

VPNはトンネルすることでアプリケーションを不可視にする

・本来、このユーザスペースVPNモデルはローカルのtun仮想アダプタとリモート先のtun仮想アダプタを本質的に結びつけます。

・それはイーサネットインターフェースに適用するのと同じ方法で経路やファイアウォールルールをtun/tapインターフェースに適用することができます。

・VPNを利用するアプリケーションは専用線で構築された広域ネットワークとは、なかなか区別がつかないかもしれません。

OpenVPN入門

・今日ではユーザスペースtun/tapモデルをサポートする数々のオープンソースVPNがあります。

・OpenVPN,VTun,Tinc,Cipeそしてさらに多くのVPNが今日では実際に開発されています。

・それらの製品はまったく違った方法で問題に取り組んでいるFreeSwanのようなIPSecソリューションとは対照的な位置づけとされています。

ユーザスペースTun/Tap vs IPSec

・ここに、どのアプローチがより良いかについて、いくつかの論争があります。

・ユーザスペースはよりポータブルで設定が簡単です。

・IPSecはより複雑でマルチベンダーや専門ルータ会社のサポートを必要とします。

・IPSecの複雑性はときおりベンダーA社の製品が別のB社の製品と通信することを困難にします。

要約するとIPSecは

・IPSecはIPスタックを複雑に変更するものです。

・IPSecはIPインターフェースから出てくるパケットを検査し、到達先にセキュリティ提携が存在するかどうかを決定してから、一つの端で自動的にパケットを暗号化します。そして他方でそれらを復号します。

・IPSecの夢はうまく機能し、そこにあることを決して知る必要がないようにすることです。
(この概念はしばしば機会的暗号として参照されます。)

IPSecの限界

・IPSecが発展したと同じくインターネットもまたそれに加えて発展しました。

・IPv4のアドレス不足は単一IPを通してインターネットへアクセスするためNATを使ったプライベートネットワーク
 を大量に作り出しました。

・IPアドレス不足はまた、動的IPアドレス使用を増大させました。

・IPSecはこれらの新しい技術へ幾分か融通のきかないということを証明したことになりました。

IPSecの限界(続き)

・IPSecはソースと到達アドレスがセキュアペイロードの一部であるべきとの見解をしたためにNATとの相互運用性を破壊しました。

・以来、IPSecの標準はこれらの制限の周辺で進化しようとしてきました。

・IPSecはまた、そのセキュリティ性に対して賞賛と非難両方受けてきました。

・時々そのような賞賛と非難は同じ個人から生じます。(次のスライドをみてください)

IPSecの“2つの見解”N.ファーグスマン・B.シュナイア

・我々はIPSecに関して2つの見解を持っている。一つはIPSecはマイクロソフト社PPTP、L2TPなど以前にあったIPセキュリティプロトコルより、はるかにセキュアであること。もう一方では、我々はそれが結果として常にセキュアなオペレーションシステムとなりうるとは信じていません。
 それは非常に複雑すぎ、またその複雑さが多くの曖昧さや矛盾、非効率そして脆弱性を導いてしまった。[...中略]
 我々はいかなる種類の価値ある情報を守るために現在のフォームのままでIPSecを利用することに強く失望している。そして、将来の設計の繰り返しがその改善となることを期待する。しかしながら現段階でのIPSecの代替品には、さらに強く失望しており、その繰り返される代替品がセキュアでないネットワークあればIPSecを推奨します。それが世界の真実なのです。

どのようにVPNはセキュリティを達成するのか?

・VPNは待ち伏せ(Passive)と積極的(Active)な攻撃に対して防御しなければなりません。

・待ち伏せ攻撃者とは2拠点間でのデータチャネルを停止したり変更したりする能力のない盗聴者です。

・暗号化が待ち伏せ攻撃者を打ち負かすのに効果があります。

積極的攻撃

・積極的攻撃者は自分自身をコミュニケーションチャネルの中へ潜ませて、2拠点間データパケットを追加、変更あるいは消去する能力を持っています。

・この理由で、そのような攻撃は一般的にMan-in-the-middle攻撃と呼ばれています。

積極的攻撃は認証の利用を通して失敗させられる

・多くの人々がVPNセキュリティとはすべて暗号化についてが全てである信じている間、解決すべきより大きな、より困難な問題は認証の問題です。

・VPNでの認証は安全なハッシュですべてのパケットにサインすることが含まれており、受信者はそれが正当なソースからきた唯一であると証明できます。

・OpenVPNとIPSecVPNともにパケットを認証するためにHMACハッシュベースメッセージ認証符号機構を利用しています。

HMACは積極的攻撃に対して100%の解決ではない

・HMACを適用後でさえ、私たちはまだ2つのタイプの積極的攻撃に対して脆弱性を持っています。

・再生攻撃

・既知平文攻撃

再生攻撃

・では、ある攻撃者がトラフィックの低い午前3時に彼が使用している銀行のT1回線に盗聴できるものとしましょう。

・“snort”のようなツールでその回線を通して流れる暗号化されたビットを観察している間、彼はその銀行のウェブサイトをログし、
 小さなワイヤ伝送数をログして、銀行のT1回線から流出している暗号化されたパケットを観察しています。

・彼は、解析するタイミングによっては彼のお金の転送を表しているある暗号化されたパケットの見本へアクセスすることができます。

再生攻撃(続き)

・それから彼がそれらのたくさんのサンプル化されたパケットでそのT1回線をスパムしたらどうなるでしょう。

・彼は暗号化アルゴリズムを知る必要はなく、彼はそのパケットを再生産する必要だけなんです。

・もし、その銀行が再生防御機能のない暗号のみを使っていれば翌朝には説明のできない疑わしい送金が殺到してしまうかもしれません。

再生攻撃(さらに続き)

・その問題への解決はサインする前に、唯一のIDやタイムスタンプをすべてのパケットに埋め込むことです。

・受信者はこのタイムスタンプの軌跡を保持する必要があり、決して2回同じタイムスタンプを受容しないことを確約する必要があります。

・OpenVPNやIPSec製品はそのSlidingWindowAlgorithmを利用して防御を再生しています。

既知平文攻撃

・では、また銀行ハッカーのところへ戻りましょう。合計の違っている金を5回送金したとしましょう。

・送金が実行されているのでT1を流れる暗号文書を解析することで、彼は合計金額をあらわしているパケット内でバイトの埋め合わせを
 認識できます。それは、例え合計金額自身が暗号化されていてもです。

既知平文攻撃(続き)

・では、合計金額が32ビットintger型だとします。

・彼はいくつかの偽造パケットをリンク上に変更された金額合計で挿入します。

・彼はそれが“復号”される時、最終の金額が何になっているのかは知りません。しかし、彼が十分な値を試して、そのいくつかはとてつもなく大きく破壊的なものになっていることは知っています。

これは2003年の現在では不可能でしょう(と私は願う)

・このシナリオは勿論今日では起こりえません。

・この種の考慮的実験の重要なことは決して破られない暗号でさえ積極的攻撃者に対しては十分に安全とはいえないことを指し示しています。

・前に議論した攻撃に対して防御するために、暗号は認証(HMAC)、乱数化したIVや再生防御を組合わすべきです。

OpenVPNと暗号

・暗号は高度で専門的なフィールドです。

・OpenVPNは暗号へモジュール単位のアプローチ方式を採用しています。

・ほとんどの暗号機能はOpenSSLライブラリに取り込まれています。

・OpenVPNは待ち伏せ攻撃と積極的攻撃の既知型に対して防御する機能を持ちます。

OpenVPNと鍵方式

・OpenVPNは鍵方式を決定する際、もっとも優れた2つの世界の優れたものを提供することを試みます。

・静的な、事前共有鍵は設定の容易さを提供するものです。

・完全なRSA PKIはOpenSSLライブラリを通して、完全証明書と私的鍵動作に対して提供されます。

・SSL/TLSは初期認証と対称する鍵交換に対して利用されるものです。

認証はより大きな問題を引き起こすのみ-鍵管理

・HMAC構築は暗号コミュニティからの強力で優雅な貢献物ですが、セキュアな接続の両端ではまだ共有された秘密鍵をなおも必要としています。

・では、どのような方法で2つの拠点は、攻撃者によってハイジャックされている交換に対してプロテクトする方式で鍵交換過程を実行するのでしょうか?

公開鍵暗号入門

・1977年9月サイエンティフィクアメリカンの記事で、ロナルドLリベスト、アディンシャミールとレオナルドMアドルマンは公開鍵暗号とデジタル署名に適用できるいRSA暗号を世界へ発表しました。作者たちはかれらのすべての報告書を自分宛の返信用切手の貼った封筒を送ってきた人に提供しました。そして次におこった国際的反響は暗号ソースコードの拡大配布する考えに躊躇していたNSAを圧倒するほどのものでした。彼らの要求の法的基盤に関してNSAがなんらの反応を示さなかったので、配布は再開されました。そしてそのアルゴリズムはACMのコミュニケーションの中で翌年公表されました。

公開鍵暗号は実際に認証の問題にかかわっている

・コンピュータ時代のはるか以前より、暗号は共有鍵を所有しあった個々間で実践されてきました。

・公開鍵暗号の革新は、個々がその鍵を共有するために以前から存在したセキュア媒体を必要とせず、いかに安全に通信できるかを示しました。

公開鍵技術は共有鍵の問題を解決する

・公開鍵暗号は最新の共有秘密鍵が交換できるような安全な媒体を提供する問題を解決します。

・現在の暗号は共有される対称鍵で未だ行われている。公開鍵プロセスはセキュアでない媒体上でこの鍵を電子的に共有するひとつの方法を
 我々に与えているだけです。

公開鍵暗号化

・公開鍵暗号は公開鍵と秘密鍵の一対を生成する事を貴方に許可します。

・秘密鍵は決してハードディスクから取り除けません。

・公開鍵は広域に発行されます。

・誰かと通信するためには、ただ公開鍵を必要とすればいいのです。

・しかし、内容が公開鍵でいったん暗号化されてしまうと、秘密鍵のみがそれを復号化できます。

公開鍵暗号と認証

・このように述べてきました公開鍵暗号はまだ欠けている部分を持っています。

・では、コミュニケーションチャネルの本当に話したい相手をどのようにして知ることができるでしょうか?

・彼らは公開鍵を提出することは出来ますが、それは彼らであることの証明をするものではありません。

証明書入門

・公開鍵暗号とRSAは安全な署名の概念を開拓しました。

・私は自分の秘密鍵でファイルに“署名”できます。

・私は自分の公開鍵を発行できます。

・そのファイルを受け取る人は誰でもそれが私の公開鍵によって署名されたものであることを照合できます。

・デジタル署名の背後にあるアルゴリズム数学は正しい秘密鍵を持たずに偽造して署名することが実行出来ない様にします。

認証機関(CA)

・認証機関Certificete authority(CA)は認証の問題を解決しようとした応用暗号化の長い開発期間での最終結論です。

・CAは武装された警備の下で保たれている強力な秘密鍵を持っています。

・また、クライアントと同一かを照合する追跡チームも持っています。

・CAはそのあとにその強力な秘密鍵でクライアントの鍵に署名します。

CA 続き...

・CAの公開鍵はアプリケーションやOSの中に組み込まれる公的な必需品となります。

・CAの“ルート証明書”はCAのクライアントのどんな鍵の同一性を証明する為に利用できる一連の公開鍵の根源を形成します。

・CAは信頼された照合によって認証問題を解決します。

・CAは安全なWEB上での認証基盤です。

暗号化の結論

・OpenVPNがIPSecの関連した暗号開発の上で大きく注意をひきつけている間、隠されることの出来ない如何なる暗号化された通信セッションの詳細があります。

・トラフィック分析はインターネットベースで現在の暗号システムでは対抗できない攻撃のひとつです。

・しかし、ほとんどのVPNユーザのニーズを考慮するとき、現在の暗号技術は充分以上であることがわかっています。

OpenVPN特長

・OpenVPNはユーザスペースVPNに対して可能なすべての機能を利用しようとします。

・ポータビリティ 異なったプラットフォーム間での高い動作性

・なじみのデーモン形式の使いやすさ

・カーネル変更の不必要性

・OpenSSLライブラリーに備わった暗号技術レイヤ

OpenVPN特長 続き

・動的アドレスやNATとは非常に快適に動作します。

・現在知られているコンピュータ技術の世界でLinux,Windows,MacOSX,BSD,Solarisを含むほとんどのオペレーティングシステムに
 対応します。

OpenVPNの3層セキュリティモデル

・コンピュータセキュリティの格言のひとつは複雑さがセキュリティの敵であるということです。

・ソフトウェア全体でソフトウェアの複雑性が与える衝撃を軽減するひとつの方法は入ってくるネットワーク上のトラフィック(データ)をあるコードの背後のアプリケーションよりもっと単純なコードであるセキュリティゲートウェイを押し通すようにせしめることです。

・この例で最重要なのはファイアウォールです。

OpenVPNの3層セキュリティモデル (続き)

・鍵は未承認パケットによって生成されるコードの行数を減らすことです。これらの僅かなコード行数は脆弱性に対し
 さらに厳密に吟味されうることです。

・OpenVPNはファイアウォールの概念の上で発展します。それは、実際のSSL/TLSコードに与える前に受信パケットを
 事前にデジタル署名テストにかける -tls-authオプションを使っていきます。

OpenVPNの3層セキュリティモデル (さらに続き)

・第1層-HMACベースのtls-authオプション 使用 SSL/TLSサブシステムへパケットを注入することを攻撃者から避けるため

・第2層-双方向クライアント-サーバ認証用SSL/TLSの使用

・第3層-成功する脆弱性の対処方法を含むことを助けるために--user/--groupを利用してOpenVPNデーモンの特権レベルを下げます。

VPNとネットワーク

・VPNと暗号に関して記述されるほど(またはそれ以上に)VPNとネットワークの記事に関することが書かれているかもしれません。

・人々がVPNで抱えている技術サポート問題の95%はネットワークとファイアウォールレイヤの問題であって暗号層の問題ではありません。

・VPNネットワークに対する2つの主要な技術はルーティングとブリッジングです。

VPNにおけるブリッジングvsルーティング

・ブリッジングは仮想、広域イーサネットLANを創造し単一サブネットの上で実行する技術です。

・ルーティングは個別のサブネットを経路を設定することで広域VPNの問題を解決します。

ブリッジングの優位性

・ブロードキャストがVPNをトラバース(超え)します。--これはWindowsのNetBIOSでのファイル共有やネットワークコンピュータのブラウズのようなLANブロードキャストに依存するソフトウェアが起動することを可能にします。

・経路情報設定が不必要です。

・IPv4,IPv6,NetWareのIPX,AppleTalkなどを含むイーサネット上を機能するどんなプロトコルでも動きます。

・リモートアクセスに関しての比較的簡単な設定ソリューションです。

ブリッジングの不利な点

・ルーティングより低効率で拡張が上手くできないといった点です。

ルーティングの優位性

・効率と拡張性がよい

・効率のためMTUのより良いチューニングができます。

ルーティングに不利な点

・Windowsでは、クライアントは交差しているVPNネットワークでブラウズするためsambaのようなWINSサーバを使わなければなりません。

・経路はそれぞれのサブネットのリンクを設定しなければなりません。

・ブロードキャストに依存するソフトウェアはVPNの他の側にあるマシンをみようとはしません。

・一般的にIPv4でしか作動しません。IPv6についてはいくつかの特別なケースのみです。

ブリッジの接続方法

・では、複数のモバイルユーザへ通信する安全なイーサネットブリッジを生成してみましょう。今回はサーバはLinuxを利用します。

・まず第一に、サーバ上で永続的なtapを仮想的なイーサネットインターフェースに生成します。“openvpn -mktun"コマンドを使います。

・それから、brctlツールを使ってそれらを現実のイーサネットアダプタに繋げます。

ブリッジの接続方法(2)

・クライアントがサーバへ接続するとき、終点のtap仮想イーサネットインターフェースはサーバに接続されている物理イーサネットLANの実際のサブネットからIPアドレスを割り当てわれます。

・ではブリッジされたイーサネットのサブネットが10.4.7.0ネットマスク255.255.255.0を得られたとしましょう。

・10.4.7.5アイダホのモスクワにあるマシンでありうるし、10.4.7.6はロシアのモスクワにあるマシンになりえます。

VPNとファイアウォール機能

・現在のユーザスペースVPNは仮想tun/tapインターフェースをVPN終点として提供します。

・tun0と呼ばれるVPNネットワークデバイスが得られると仮定します。

・eth0あるいは他のネットワークデバイスに適用できるように同様のファイアウォールルールをtun0に適用できます。

VPNとファイアウォール機能(続き)

・VPNのもっとやっかいなセキュリティの問題のひとつは、異なるネットワーク間で信頼できる関係を作り上げる方法です。

・このことは最悪になりえます。ワームやウィルスが誰かのホームマシンに影響を与えVPNを横断して関連のヘッドクオータへジャンプしてしまうケースのように。

・VPN自身へ適用されたファイアウォールルールは信頼されないよりはましな、かといって完全に信用されるものではない2つのネットワーク間において信用関係を築くことができます。

今後の方向性 --OpenVPN2.0

・OpenVPN1.xでは、単一のopenvpnデーモンがデーモン間通信をするために単一のUDPまたはTCPポートを利用して単一tun/tap
 インターフェースの上で単一トンネルをサポートできます。

・それぞれのトンネルの設定がカスタマイズできるので、このモデルは最大の融通性を発揮します。

・このモデルの弱点は多数の動的クライアントからの接続を扱うOpenVPN設定を行うのが難しいことです。

今後の方向性 --OpenVPN2.0(続き)

・OpenVPN2.0(現在は評価版)は、無作為の数多くのUDPクライアントがtun/tapインターフェースのひとつとUDPポート番号のひとつを利用した単一openvpnデーモンに接続できるようにしてこの問題を解決します。

結論

・VPNは暗号化書式、ネットワークおよびファイアウォールの概念を一元化します。

・VPNは小規模の安全な遠距離通信ソリューションから大規模の安全なWANまでいかなるものを構築するための建築ブロックとして用いられるようになります。

・ユーザスペースVPNはモジュラーパッケージにおいてVPN問題に対して的確なソリューションです。

・VPNにはIPのような他のネットワークサブシステムのように簡単設定となるまでには長い道のりが依然としてあります。

お問い合わせフォーム

戻る
Copyright(C) 2004 TTM Engineering Co., Ltd. All Rights Reserved.