| HowTo |
 |
|
このページはOpenVPN公式サイトのコンテンツをもとに作成されていますが、完全な翻訳であることを保証するものではありません。正確な情報については公式サイトの情報も併せてご確認ください。
目次OpenVPNの紹介（イントロダクション）
想定されている読者 クイックスタート インストール 「ルーティング」と「ブリッジ」のどちらを使うか？ サブネットの設定 認証局（CA）の設置とOpenVPN用証明書と鍵の生成 サーバー用/クライアント用の設定ファイルの作成 VPNの起動と接続テスト システムのスタートアップでOpenVPNが自動起動するように設定する 実行中のOpenVPNプロセスの制御 クライアント側、またはサーバー側サブネットへのクライアントPCの追加によるVPNの拡張 クライアントに対するDHCPオプションの設定 クライアント特有のルールとアクセスポリシーの設定 別の認証方法の使用 クライアント側でスマートカードを利用した2ファクタ認証を行うためのOpenVPNの設定方法 クライアントのすべてのトラフィック（Webトラフィックを含む）をVPN経由にルーティングする 動的IPアドレスでのOpenVPNサーバーの運用 HTTPプロキシ経由でのOpenVPNサーバーへの接続 OpenVPN経由でSamba共有に接続する ロードバランス/フェールオーバー構成 OpenVPNのセキュリティを強化する 証明書の失効 クライアントが接続先のサーバー証明書を検証しない場合に発生する可能性のある「Man-in-the-Middle」攻撃について サンプル設定ファイル OpenVPNの紹介（イントロダクション）OpenVPNは業界標準であるSSL/TLSプロトコルを利用した、高機能のSSL VPNです。証明書やスマートカード、ID/パスワードを使った柔軟なクライアント認証が可能であり、 VPNの仮想インターフェイスに対してファイアーウォールを設定することによってユーザーやグループ単位でのアクセス制御もできます。 OpenVPNはWebアプリケーションプロキシではありませんので、Webブラウザを使って操作するものではありません。 このドキュメントでは、OpenVPN 2.0のクライアント/サーバーの設定方法をステップバイステップで解説します。 設定ファイルのサンプルを参照したい場合はこちらからどうぞ。 想定されている読者このドキュメントは、ネットワークに関する基礎知識、たとえばIPアドレス、DNS、ネットマスク、サブネット、IPルーティング、ルータ、ネットワークインターフェイス、LAN、ゲートウェイ、ファイアーウォールなどについての基本的な知識を持っている方を対象にしています。 OpenVPN 1.xのドキュメント旧バージョンであるOpenVPN 1.0のドキュメントも「OpenVPN 1.x HOWTO」から参照できます。Point-to-Pointでの接続や静的鍵での設定などについて有用な情報が含まれていますので、必要に応じて参照してください。 他の資料他にもたくさんの資料があります。こちらをご覧ください。 クイックスタートここからは、X509 PKI（証明書と秘密鍵を使った公開鍵認証）を使ってVPNクライアント/サーバーを構成する方法を説明します。 静的鍵を利用する場合の利点
静的鍵を利用する場合の欠点
インストールまずはOpenVPNをダウンロードします。 正しくダウンロードできたかどうかを確認するため、ダウンロードしたファイルの署名を確認しておくとさらに安全です。 Windowsの場合はこちらを参照してください。
OpenVPNの実行ファイルはサーバーとクライアントの両方にインストールする必要がありますが、サーバーとクライアントに同じ実行ファイルをインストールします。 Linuxの場合（RPMパッケージを使うとき）RPMパッケージをサポートしたLinuxディストリビューション（SuSE、Fedora、Redhatなど）を使うときには、RPMを使ってインストールするのが最も簡単です。 rpmbuild -tb openvpn-[version].tar.gz RPMファイルを入手/ビルドできれば、通常のRPMファイルの場合と同じ方法でインストールできます。 rpm -ivh openvpn-[details].rpm インストール済みのOpenVPNをアップグレードする場合は次のようにします。 rpm -Uvh openvpn-[details].rpm OpenVPNのバイナリRPMパッケージをインストールする場合、次の依存関係があります。
また、自分でRPMパッケージをビルドする場合にはさらに次の依存関係があります。
Red Hat Linux 9でのRPMビルドや、依存関係の制御などに関してはopenvpn.specファイルを参照してください。 Linuxの場合（RPMを使わないとき）DebianやGentooなど、RPMベースではないLinuxディストリビューションの場合は、そのディストリビューションで利用できるパッケージングシステム（apt-getやemergeなど）を使ってインストールすることができます。 また、./configureコマンドを使ってインストールすることもできます。 tar xfz openvpn-[version].tar.gz 展開したディレクトリに移動してmakeします。 ./configure Windowsの場合ダウンロードページにある自己解凍exeファイルを実行してインストールします。 Windows用のOpenVPN GUIのインストール時にOpenVPNをインストールすることもできます。Mathias Sundmanのインストールパッケージを使うと、GUIツールとOpenVPN本体を同時にインストールできます。 このサイトではWindows用GUI日本語版を公開しています。このインストール済みパッケージを利用すると、OpenVPN本体とGUIを同時にインストールできます。こちらもぜひご利用ください。
OpenVPNをWindowsインストーラでインストールすると、.ovpnファイルがOpenVPNに関連付けられます。 インストールが完了した後、OpenVPNを次のいずれかの方法で実行します。
openvpn myconfig.ovpn
Windows用にはGUIもあり、GUIから起動することもできます。 Windowsへのインストールについては、こちらにある情報も参照してください。 Windows用GUI日本語版の利用方法はこちらからご覧ください。
Mac OS Xの場合Angelo LaubとDirk TheisenがOpenVPN GUI for OS Xを公開しています。 その他のOS特定のOS向けの注記がINSTALLに記載されていますので参照してください。通常は下記の方法でインストールできます。 ./configure 「ルーティング」と「ブリッジ」のどちらを使うか？「ルーティング」と「ブリッジ」の違いについてはFAQで、ブリッジの詳細はこちらのページでさらに詳しく説明されていますので、参照してください。 一般的には「ルーティング」が適している場合が多く、設定も容易です。 また、クライアントごとのアクセス制御もこちらのほうが高機能です。 しかし「ブリッジ」でないと利用できない機能もあります。下記のような機能が必要な場合は「ブリッジ」を使用する必要があります。
サブネットの設定VPNを設定する場合、通常は異なるロケーションにあるサブネットを相互にリンクさせます。 Internet Assigned Numbers Authority (IANA) は、RFC1918において下記のIPアドレスブロックをプライベートネットワーク用アドレスとして定義しています。
VPN設定でもこれらのプライベートIPアドレスブロック内のアドレスを使用しますが、IPアドレスやサブネットが重複しないよう注意する必要があります。たとえば次のような状況は避けなければなりません。
たとえば、よく使用されるプライベートLANのサブネットとして192.168.0.0/24があります。 外部のインターネットカフェからVPNにアクセスしようとしたとき、そのインターネットカフェのLANがこの同じサブネットを使うよう設定されているとすると、ルーティングの衝突が発生します。192.168.0.1というゲートウェイのアドレスが、そのインターネットカフェのLAN内のアドレスなのか、VPN上のアドレスなのかが判断できないためです。 もうひとつの例を考えてみます。複数の拠点間をVPNで接続しようとしますが、それぞれの拠点のLANでサブネットとして192.168.0.0/24を使用していたとします。 この場合も問題が発生します。各拠点で異なるサブネットを使用しないと、どのサイトにパケットを送ればいいかが判断できないためです。 この問題を避けるための最善の解決策は10.0.0.0/24や192.168.0.0/24をプライベートLANのネットワークアドレスとして使用しないことです。VPNのアクセス元（インターネットカフェや空港、ホテルなども含む）で使用されている可能性の低いサブネットを選択します。たとえば、10.0.0.0/8アドレスブロックの途中のアドレス（10.66.77.0/24 など）を抜き出して使えば、アドレスが重なりにくくなるかもしれません。 認証局（CA）の設置とOpenVPN用証明書と鍵の生成概要OpenVPN 2.0の設定の第一段階は、PKI（公開鍵基盤）の構築です。PKIには以下のものが含まれます。
OpenVPNは双方向の認証をサポートしています。したがって、信頼された接続を確立するためにはクライアントはサーバーの証明書を認証し、サーバーはクライアントの証明書を認証する必要があります。 この認証では、まずマスター認証機関（CA）によって署名されているかを確認し、その後証明書のヘッダ情報（共通名や認証タイプなど）をチェックします。 VPNの観点からすると、このセキュリティモデルにはさまざまな利点があります。
マスター認証機関（CA）の証明書と鍵の生成このセクションでは、まずマスター認証機関の証明書と鍵を生成した後、サーバーの証明書と鍵を生成し、続けて3台のクライアントそれぞれの証明書と鍵を生成する方法を説明します。 LinuxやBSD、UnixベースのOSを使用している場合には、シェルを開き、OpenVPNが配置されているディレクトリのeasy-rsaサブディレクトリに入ります。 RPMファイルからインストールした場合は、このディレクトリは通常/usr/share/doc/packages/openvpnか/usr/share/doc/openvpn-2.0にあります。 [注] RPMファイルからインストールした場合、設定ファイルを編集する前に、設定ファイルを/etc/openvpnなどのディレクトリにコピーしておくと安全です。こうしておけば、今後OpenVPNをアップグレードしたときにも設定ファイルが上書きされることを防ぐことができます。
.tar.gzファイルからインストールした場合は、easy-rsaサブディレクトリはソースツリーを展開したトップディレクトリの下にあります。 Windowsを使用している場合には、コマンドプロンプトを開き、\Program Files\OpenVPN\easy-rsaディレクトリに入ります。 次のバッチファイルを実行して設定ファイルをコピーします（このコマンドを実行すると、vars.batとopenssl.cnfが上書きされます）。 init-config varsファイル（Windowsの場合はvars.batファイル）で記述されているKEY_COUNTRY、KEY_PROVINCE、KEY_CITY、KEY_ORG、KEY_EMAILの各パラメータを設定します。 これらのパラメータはブランクにしないようにしてください。 続いて、PKIを初期化します。Linux/BSD/Unixの場合は次のようにします。 . ./vars Windowsの場合は次のようにします。 vars 最後にbuild-caコマンドを実行すると、opensslコマンドが呼び出されて認証機関（CA）の証明書と鍵が生成されます。 ai:easy-rsa # ./build-ca コマンドを実行したときにいくつかの情報を尋ねられますが、その際にデフォルト値として先ほどvarsまたはvars.batファイルで設定した値が使用されます。 Common Name（共通名）だけはデフォルト値が設定されないため、ここで必ず入力しなければなりません。上記の例では「OpenVPN-CA」としています。 サーバー用の証明書と鍵の生成次に、サーバー用の証明書と秘密鍵を生成します。Linux/BSD/Unixの場合は次のようにします。 ./build-key-server server Windowsの場合は次のようにします。 build-key-server server ここでもほとんどのパラメータはデフォルトのままで問題ないはずですが、Common Nameは設定する必要があります。ここでは「server」と設定します。 また、「Sign the certificate?（証明書に署名しますか？） [y/n]」と「1 out of 1 certificate requests certified, commit?（1つの証明書要求がありますが、コミットしますか？） [y/n]」という2つの質問が出ますが、両方にYesと答えてください。 3台のクライアント用の証明書と鍵の生成基本的にサーバーの手順と同様の方法です。Linux/BSD/Unixの場合は次のようにします。 ./build-key client1 Windowsの場合は次のようにします。 build-key client1 クライアントの鍵をパスワードで保護したい場合には、代わりにbuild-key-passコマンドを使用してください。 各クライアントには固有のCommon Nameを設定する必要があります。これは他のクライアント用証明書で使用した共通名と重複することはできません。 このサンプルでは「client1」「client2」「client3」という共通名を使用します。 Diffie Hellmanパラメータの生成OpenVPNサーバーでDiffie Hellmanパラメータを生成します。Linux/BSD/Unixの場合は次のようにします。 ./build-dh Windowsの場合は次のようにします。 build-dh コマンドを実行すると次のように表示されます。 ai:easy-rsa # ./build-dh 鍵ファイル新しく作成された証明書と鍵はkeysサブディレクトリにあります。 今までの手順に従うと、以下のようなファイルがあるはずです。
鍵を生成したら、それぞれのPCに必要なファイルをコピーします。これらのファイルは重要なファイルですので、ファイルを各PCにコピーする際には安全な方法でファイルをやり取りするように注意してください。 サーバー用/クライアント用の設定ファイルの作成サンプル設定ファイル設定ファイルを作成するには、サンプル設定ファイルをベースに利用するのが便利です。サンプル設定ファイルは下記の場所にあります。
Linux、BSDなどのUnix系のOSでは、サンプル設定ファイルはserver.confやclient.confというファイル名になっています。Windows版ではserver.ovpnやclient.ovpnというファイル名になっています。 サーバー設定ファイルの編集サンプルのサーバー設定ファイルをベースにして、サーバー設定ファイルの編集を行います。この設定では、仮想TUNネットワークインターフェイスをルーティングとして作成し、 UDPポート 1194（OpenVPNの標準ポート番号）でクライアントからの接続を受け付け、VPNクライアントには10.8.0.0/24サブネットのアドレスを配布します。 サンプルの設定ファイルを使用する前には、ca、cert、key、およびdhの各パラメータをPKIのセクションで作成した実際のファイルの場所に設定してください。 これだけの設定でサーバー設定ファイルを使うこともできますが、通常はさらに以下のような設定を行います。
1台のPC上で複数のOpenVPNインスタンスを実行する場合は、それぞれのインスタンスで個別の設定ファイルを使用します。このためには下記のような設定が必要になります。
クライアント設定ファイルの編集クライアント用のサンプル設定ファイル（Linux/BSD/Unixではclient.conf、Windowsではclient.ovpn）は、サーバー用のサンプル設定ファイルでの設定に対応するようになっています。
VPNの起動と接続テストサーバーの起動まず、OpenVPNサーバーがインターネットからアクセスできるようになっていることを確認します。ファイアーウォールの設定も確認し、OpenVPNのポート（設定したポート）にアクセスできるように設定されているかをチェックしてください。 次に、TUN/TAPインターフェイスに対するファイアーウォールの保護を解除します。 トラブルシューティングを容易にするために、OpenVPNをデーモンやサービスとしてではなく、まずはコマンドラインから（Windowsの場合は.ovpnファイルを右クリックして）実行します。 openvpn [サーバー設定ファイル] 通常、サーバーは起動時に次のようなメッセージを表示します。 Sun Feb 6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 5 2005 クライアントの起動サーバーと同様、OpenVPNをデーモンやサービスとしてではなく、まずはコマンドラインから（Windowsの場合は.ovpnファイルを右クリックして）実行します。 openvpn [クライアント設定ファイル] Windows版では通常、前述のサーバーの起動時の出力と似たようなメッセージが表示されます。メッセージの末尾はInitialization Sequence Completedとなります。 では、クライアントからVPN経由でPINGを実行してみましょう。ルーティングを使用している場合（サーバー設定ファイルでdev tunを使用している場合）は次のようにします。 ping 10.8.0.1 ブリッジモードを使用している場合（サーバー設定ファイルでdev tapを使用している場合）は、サーバーのサブネット上にあるIPアドレスに対してPINGを実行します。 PINGが成功すれば、VPNでの接続は成功です。 トラブルシューティングPINGが失敗した場合、またOpenVPNクライアントが接続を開始できない場合には、以下の点を確認してください。 ■ TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)と表示される。このエラーはクライアントがサーバーへのネットワーク接続が確立できないときに発生します。
解決策: 以下の点をご確認ください。
■ Initialization Sequence Completed with errorsと表示される。このメッセージはWindows版で （1）DHCPクライアントサービスが実行されていないとき、(2) XP SP2上でサードパーティのパーソナルファイアーウォールを使用しているとき、に発生する可能性があります。
解決策: DHCPが利用できるようになっていること、またパーソナルファイアーウォールがXP SP2上で正しく動作するものであることを確認する。
■ Initialization Sequence Completedメッセージは表示されるものの、PINGが成功しない。これはTUN/TAPインターフェイス上のVPNネットワークトラフィックがファイアーウォールによってフィルタされているときによく起きる問題です。
解決策: クライアントのTUN/TAPインターフェイスでファイアーウォールが無効にする。Windows XP SP2の場合、［Windowsセキュリティセンター］-［Windowsファイアーウォール］-［詳細］でTAP-Win32アダプタのファイアーウォールを解除する。また、サーバー側のTUN/TAPインターフェイスでもトラフィックがフィルタされていないことを確認する（サーバー側でのファイアーウォールの利用については、「クライアント特有のルールとアクセスポリシーの設定」も参照してください）。
■ proto udp設定を使用しているが、接続開始時に接続が止まってしまい、サーバーに下記のようなログが残される。
TLS: Initial packet from x.x.x.x:x, sid=xxxxxxxx xxxxxxxx クライアント側にはログが残されていない。
解決策: 接続がクライアントからサーバーへの一方のみしか確立できないため、サーバーからクライアントへのデータが（おそらくはクライアント側で）ブロックされている。（1）クライアント上でパーソナルファイアーウォールが動作しているか、（2）クライアント用のNATルータゲートウェイが動作している可能性がある。サーバーからクライアントへのUDPパケットが許可されるようファイアーウォールの設定を変更する。
トラブルシューティングに関するさらに多くの情報がFAQにありますので、参照してください。 システムのスタートアップでOpenVPNが自動起動するように設定するブート時にデーモンやサービスを自動起動する方法はOSによって異なります。 LinuxLinuxでRPMパッケージからOpenVPNをインストールした場合、インストーラによってinitscriptがセットアップされます。実行すると/etc/openvpnディレクトリ内にある.confファイルが検索され、見つかった設定ファイルごとに別個のOpenVPNデーモンが起動します。 WindowsWindowsインストーラを使ってインストールするときにサービスラッパーも同時にセットアップされますが、デフォルトではOFFになっています。サービスを有効化するには、［コントロールパネル］にある［管理ツール］から［サービス］を開き、OpenVPNサービスを選択して右クリックして［プロパティ］を選択します。［スタートアップの種類］を「自動」に設定すると、サービスは次回の再起動時から自動起動します。 サービスが起動されると、OpenVPNサービスラッパーが\Program Files\OpenVPN\configフォルダにある.ovpn設定ファイルを検索し、見つかった設定ファイルごとに別個のOpenVPNプロセスが起動します。 実行中のOpenVPNプロセスの制御Linux/BSD/Unixで動作している場合OpenVPNは下記のシグナルを受け付けます。
writepidディレクティブを使用するとOpenVPNデーモンが使用するPIDをファイルに書き出すことができるため、シグナルを送るプロセスを判別できます（initscriptでOpenVPNを起動した場合は、コマンドラインに--writepidディレクティブを付加して起動します）。 WindowsでGUIから動作している場合OpenVPN GUIを参照してください（日本語版はこちら）。 Windowsでコマンドプロンプトウィンドウから動作している場合Windowsでは、OpenVPN設定ファイル（.ovpnファイル）で右クリックして［Start OpenVPN on this config file］を選択することによって起動できます。 この方法で起動すると、以下のキーボードコマンドが使用可能になります。
Windowsサービスとして動作している場合OpenVPNをWindowsのサービスとして起動した場合には、以下の方法でのみ制御できます。
サーバー起動中の設定変更ほとんどの設定変更については、変更後にサーバーの再起動が必要です。ただし、2つのディレクティブによって参照されているファイルだけは例外で、それらのファイルは書き換えられた後すぐに反映され、設定の反映のためにサーバープロセスを再起動する必要がありません。 client-config-dir -- このディレクティブはクライアント設定ディレクトリを設定するものです。これはクライアントごとの設定ファイルを格納するディレクトリであり、サーバーへの接続のたびにスキャンされます（詳細についてはman pageを参照してください。）。このディレクトリ内のファイルは変更がすぐに反映され、サーバーの再起動は必要ありません。ただし、この設定の変更が適用されるのは設定変更後に接続してくる新しい接続に対してのみで、既存の接続には適用されないことに注意してください。既存の接続（または、切断したもののまだタイムアウトしていない接続）にも新しい設定を適用したい場合は、後述する管理インターフェイスを使用してその接続のインスタンスをKillしてください。これによって再接続が行われ、新しいclient-config-dirファイルが適用されることになります。 crl-verify -- このディレクティブは「証明書の失効」で後述する証明書失効リスト（CRL：Certificate Revocation List）を指定するためのものです。ここで指定されたCRLファイルを書き換えた場合は、その後接続してくる新しい接続や、既存の接続のSSL/TLSチャンネルの再ネゴシエーション（デフォルトでは1時間おき）の際にすぐに適用されます。CRLに追加した証明書を使っているクライアントからの接続をすぐに切断したい場合には、後述する管理インターフェイスを使用してください。 ステータスファイルデフォルトのserver.confでは次のように設定されています。 status openvpn-status.log このファイルには、現在接続しているクライアント接続のリストが1分ごとに書き出されます。 管理インターフェイスの使用OpenVPN管理インターフェイスを使うと、実行中のOpenVPNプロセスを制御できます。この管理インターフェイスは管理用のポートにTELNETで接続することによって直接使用することもできますし、この機能を利用するGUIを使って間接的に使用することもできます。 この管理インターフェイスを有効にするには、サーバーかクライアントの設定ファイルで次のように設定します。 management localhost 7505 この設定では、OpenVPNの管理インターフェイスはTCPポート 7505で接続を受け付けます（もちろん他の空いているポートを設定することもできます）。 この設定を行ってOpenVPNが実行されている状態であれば、この管理インターフェイスにTELNETクライアントを使って接続することができます。 ai:~ # telnet localhost 7505 詳細についてはOpenVPN Management Interface Documentationを参照してください。 クライアント側、またはサーバー側サブネットへのクライアントPCの追加によるVPNの拡張ルーティングVPN（dev tun）でサーバー側に複数PCを接続するクライアントとサーバー間でVPNが動作するようになると、クライアントを追加し、サーバーだけではなくサーバーネットワーク上にある複数のPCにアクセスできるようにVPNを拡張したいと思うことでしょう。 この例では、サーバー側LANはサブネットとして10.66.0.0/24を使用しており、OpenVPNのサーバー設定ファイルのserverディレクティブの設定ではVPN IPアドレス範囲として10.8.0.0/24を使用しているものとします。 まず、VPNクライアントに対して、10.66.0.0/24のサブネットにVPN経由でアクセスさせるようにする必要があります。これは、サーバーの設定ファイル内のディレクティブを下記のように設定することによって簡単にできます。 push "route 10.66.0.0 255.255.255.0" 次に、サーバー側LANのゲートウェイにおいて、VPNクライアントサブネット（10.8.0.0/24）からOpenVPNサーバーへルーティングされるように設定する必要があります（これはOpenVPNサーバーとLANゲートウェイが別の場合にのみ必要な設定です）。 また、OpenVPNサーバーでIPフォワードとTUN/TAPフォワードが有効になっていることを確認してください。 ブリッジVPN（dev tap）でサーバー側に複数PCを接続するブリッジの場合は、追加の設定を行う必要はありません。これはブリッジを利用しているメリットの1つです。 ルーティングVPN（dev tun）でクライアント側に複数PCを接続する典型的なリモートアクセスの場合、クライアントPCは1台のPCとしてVPNに接続します。しかし、クライアントPCをローカルLAN（ホームオフィスなど）のゲートウェイとして利用し、そのクライアントLAN上にある各PCをVPNに接続したい場合があります。 今回の例ではクライアントLANは192.168.4.0/24サブネットを使用しており、このVPNクライアントは共通名としてclient2を設定した証明書を使うものとします。目標は、クライアントLAN上のすべてのマシンがVPN経由でサーバーLAN上の任意のPCにアクセスできるようにすることです。 セットアップの前に必要なことがいくつかあります。
まず、このクライアントPCでIPフォワードとTUN/TAPフォワードを有効にしてください。 次に、サーバー側の設定を変更します。サーバー設定ファイルでクライアント設定ディレクトリへの参照が行われていない場合は、次の行を追加してください。 client-config-dir ccd このディレクティブで設定されているccdは、OpenVPNサーバーデーモンが起動する際に事前に作成されるディレクトリの名前です。通常、Linuxの場合は/etc/openvpn、Windowsの場合は\Program Files\OpenVPN\configが使用されます。新しいクライアントがOpenVPNサーバーに接続してくると、デーモンがこのディレクトリをチェックし、接続してきたクライアントと一致する共通名が設定された設定ファイルがないかどうかを確認します。ファイルが見つかった場合には、この設定が読み込まれ、追加の設定ディレクティブが適用されます。 次に、ccdディレクトリにclient2というファイルを作成します。このファイルには次の1行を含めます。 iroute 192.168.4.0 255.255.255.0 この設定は、OpenVPNサーバーに対し、192.168.4.0/24サブネットへの通信をclient2にルートさせるためのものです。 続いて、メインのサーバー設定ファイル（ccd/client2ファイルではありません）に下記の1行を加えます。 route 192.168.4.0 255.255.255.0 routeとirouteの両方の設定を行うのは冗長に感じるかもしれません。 routeはカーネルからOpenVPNサーバー（TUNインターフェイス経由）でのルート設定に使用される設定で、irouteはOpenVPNサーバーからリモートクライアントでのルート設定に使用されます。そのため、この2つはどちらも必要なものです。 client2のサブネット（192.168.4.0/24）とOpenVPNサーバーの他のクライアントとの間でのネットワークトラフィックを許可したい場合には、サーバー設定ファイルに下記の設定を加えます。 client-to-client この設定により、OpenVPNサーバーはクライアント2のサブネットを他のクライアントに通知することになります。 最後に（よく忘れる点ですが）、サーバーのLANゲートウェイにおいて、192.168.4.0/24への通信をOpenVPNサーバーにルーティングする設定を追加します（OpenVPN本体がサーバーLANのゲートウェイも兼ねている場合はこのステップは不要です）。もしこの設定を行わずに、 192.168.4.8からサーバーLAN上のPC（OpenVPNサーバー以外）にPINGを飛ばしたらどうなるでしょうか？ PINGはその対象PCには届きますが、192.168.4.0/24へのルートが設定されていないため、リプライを返すためのルートがわからないことになります。 同様に、OpenVPNが稼動しているクライアントマシンがクライアントLANのゲートウェイでない場合、クライアントLANのゲートウェイにおいて、OpenVPNクライアントマシンにVPNで接続できるようにすべてのサブネットへのルートが設定されている必要があります。 ブリッジVPN（dev tap）でクライアント側に複数PCを接続するこちらは少し複雑です（実際にはそれほど難しくありませんが）。下記のような手順が必要です。
クライアントに対するDHCPオプションの設定OpenVPNサーバーはクライアントに対し、DNSやWINSサーバーのアドレスなどのDHCPオプションをプッシュすることができます（詳細についてはFAQを参照してください）。 WindowsクライアントはプッシュされたDHCPオプションをOSレベルで受け入れますが、Windows以外のクライアントの場合は、 foreign_option_n環境変数リストをパースするupスクリプトを使用する必要があります。詳細やスクリプトのサンプルはman pageやopenvpn-users mailing list archiveを参照してください。 たとえば、接続してくるクライアントに対して内部DNSサーバーを10.66.0.4と10.66.0.5、WINSサーバーを10.66.0.8として設定したい場合には、OpenVPNサーバー設定で次のように設定します。 push "dhcp-option DNS 10.66.0.4" Windowsでこの動作を確認するには、OpenVPNサーバーに接続している状態でコマンドプロンプトから下記のコマンドを実行します。 ipconfig /all TAP-Win32アダプタの欄に、サーバーからプッシュされたDHCPオプションが表示されているはずです。 クライアント特有のルールとアクセスポリシーの設定企業で使用するVPNをセットアップするとして、以下の3つのグループごとにアクセスポリシーを設定する場合を想定します。
基本的なアプローチとしては (a) 各グループごとに仮想IPアドレスを分離し、(b) クライアントの仮想IPアドレスを利用してアクセスを制御するファイアーウォールを設定する、ということになります。 今回の例では、正社員の人数は可変であるものの、システム管理者は1名のみ、契約社員は2名のみ、という構成を想定してみましょう。また、IPアドレスの割り当て方針としては、正社員に対してはIPアドレス範囲からアドレスを割り当て、システム管理者と契約社員には固定IPアドレスを割り当てるものとします。 前提条件として、アクセス制御を可能にするため、OpenVPNサーバー上でソフトウェアファイアーウォールが動作している必要があります。今回は一例としてLinuxのiptableでの例を説明しましょう。 まず、グループごとの仮想IPアドレスのマッピングを決めます。
次に、このマッピングをOpenVPNサーバー設定に書き換えます。その際、前述の手順に従い、すべてのクライアントが利用可能な10.66.4.0/24サブネットが構成してあることを確認してください（10.66.4.0/24サブネットにアクセスできるようにルーティングの設定を行った後、上記のポリシーに従ってアクセス制御を行うようファイアウォールを設定します）。 まず、ファイアーウォールルールでインターフェイスを識別できるようにするために、tunインターフェイスのユニット番号を決めます。 dev tun0 サーバー構成ファイルで、正社員用IPアドレス範囲を定義します。 server 10.8.0.0 255.255.255.0 システム管理者用および契約社員用のIPアドレス範囲に対するルーティングを追加します。 route 10.8.1.0 255.255.255.0 システム管理者と契約社員には固定IPアドレスを割り振る必要があるため、クライアント設定ファイルディレクトリを使用します。 client-config-dir ccd これで、ccdサブディレクトリに正社員以外のVPNクライアント用に固定IPアドレスを設定するための設定ファイルを格納することになります。 ccd/sysadmin1ifconfig-push 10.8.1.1 10.8.1.2 ccd/contractor1ifconfig-push 10.8.2.1 10.8.2.2 ccd/contractor2ifconfig-push 10.8.2.5 10.8.2.6 ifconfig-pushで設定されている2つのアドレスは、仮想的なクライアントとサーバーのエンドポイントを示しています。WindowsクライアントおよびTAP-Win32ドライバとの互換性のため、これらのアドレスは連続する/30サブネットから選択する必要があります。具体的には、ここで指定するIPアドレスの最後のオクテットの組み合わせは、下記のセットのいずれかでなければなりません。 [ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18] これでOpenVPNの構成は完了です。あとはアクセスポリシーに基づいてファイアーウォールルールを設定します。一例としてLinuxのiptablesの場合は、次のように設定します。 # 正社員用ルール 別の認証方法の使用OpenVPN 2.0には、接続しているクライアントからOpenVPNサーバーがユーザー名やパスワードを安全に取得し、これらの情報をクライアントを認証するための基盤として利用するための機能が備わっています。 この認証方式を利用するには、クライアント設定ファイルにauth-user-passディレクティブを追加します。この設定を追加するとOpenVPNクライアントはユーザーにユーザー名とパスワードを問い合わせ、それらの情報をセキュアなTLSチャンネルを経由してサーバーに渡します。 次に、スクリプトや共有オブジェクト、DLLなどの認証プラグインを使用するようにサーバーを設定します。OpenVPNサーバーはVPNクライアントが接続しようとしてくるたびにプラグインを呼び出し、クライアントで入力されたユーザー名とパスワードをプラグインに渡します。認証プラグインは、 OpenVPNサーバーへの接続を許可するかどうかを戻り値（1：接続拒否、0:接続許可）によって制御します。 スクリプトプラグインの使用スクリプトプラグインを使用するには、サーバー設定ファイルにauth-user-pass-verifyディレクティブを追加します。次のように設定します。 auth-user-pass-verify auth-pam.pl via-file この設定では、接続してきたクライアントのユーザー名とパスワードをauth-pam.plスクリプトで認証することになります。auth-user-pass-verifyディレクティブの詳細についてはman pageを参照してください。 auth-pam.plはOpenVPNのソースファイル一式の中にあるsample-scriptsディレクトリに含まれています。このスクリプトではPAM認証モジュール（シャドウパスワード、RADIUS、LDAPによる認証が実装されています）を使用してLinuxサーバー上のユーザーを認証します。auth-pam.plは主にデモンストレーション用に作成されています。PAM認証を実際に使用したい場合には、次に説明するopenvpn-auth-pam共有オブジェクトプラグインを使用してください。 共有オブジェクトまたはDLLプラグインの使用共有オブジェクトやDLLのプラグインはCモジュールとしてコンパイルされ、OpenVPNサーバーの起動時に読み込まれます。RPMベースのLinux用のOpenVPNパッケージを使用している場合には、openvpn-auth-pamプラグインがビルドされています。このプラグインを使用するには、サーバー設定ファイルに下記の記述を追加します。 plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login この設定により、OpenVPNサーバーはクライアントで入力されたユーザー名とパスワードをlogin PAMモジュールを使って検証します。 PAM認証を実際に使用する場合には、openvpn-auth-pamプラグインを使用するほうが望ましいと言えます。このプラグインはauth-pam.plに比べていくつかの利点があります。
OpenVPNで使用できるプラグインを開発する方法については、OpenVPNのソース内にあるpluginディレクトリのREADMEファイルを参照してください。 Linux上でopenvpn-auth-pamプラグインをビルドするには、OpenVPNのソース内にあるplugin/auth-pamディレクトリに入り、makeを実行します。 デフォルトでは、auth-user-pass-verify、またはユーザー名とパスワードによる認証を行うプラグインを使用すると、二重の認証が行われることになります。したがって、クライアントが認証をパスするには、クライアント証明書による認証と、ユーザー名とパスワードによる認証の両方が必要です。 セキュリティ上はお勧めできませんが、クライアント証明書による認証を行わないようにし、ユーザー名とパスワードによってのみ認証を行うように設定することもできます。その場合にはサーバー設定で下記の記述を追加します。 client-cert-not-required この設定を行う場合には下記の設定も行います。 username-as-common-name これにより、サーバーはユーザー名をインデックス用に使用します。クライアント証明書での認証の場合は共通名が使用されます。 [注] client-cert-not-requiredはサーバー証明書を不要にするものではありません。client-cert-not-requiredを使用したサーバーに接続するクライアントはクライアント設定ファイルからcert とkeyディレクティブを削除できますが、caディレクティブは削除できません。これはクライアントがサーバー証明書を検証する際に必要だからです。
クライアント側でスマートカードを利用した2ファクタ認証を行うためのOpenVPNの設定方法2ファクタ認証（dual-factor authentication）について2ファクタ認証とは、「持っている物」と「知っていること」という2つの要素を組み合わせた認証方式のことです。 「持っている物」としてよく使用されるのは複製不可能なデバイス、たとえば秘密鍵を格納した暗号化トークンです。このような暗号化トークンでは、秘密鍵はデバイスの中で生成され、外に出ることはありません。暗号化トークンを所有しているユーザーがリモートネットワーク上にある保護されたサービスにアクセスしようとしたとき、そのユーザーが物理的に認証済みトークンを持っていれば認証プロセスは高い信頼性でユーザーを証明することができます。 「知っていること」としてよく使用されるのが暗号化デバイスのパスワードです。正しいパスワードが入力されなければ、秘密鍵にアクセスできません。暗号化デバイスの別の機能として、何度も間違ったパスワードが入力されたときに秘密鍵を使用できなくする、ということがあります。この機能により、もしユーザーがデバイスを紛失したとしても、他の人がそのデバイスを使用できなくすることができます。 暗号化デバイスは一般的にスマートカードやトークンと呼ばれ、PKI（公開鍵基盤）と組み合わせて使用されます。VPNサーバーはX.509証明書をチェックし、ユーザーが正しい秘密鍵を持っているかどうか検証することができます。デバイスの複製が不可能であり、さらに正しいパスワードも必要とすることで、サーバーはユーザー認証を高度なレベルで実現できることになります。 2ファクタ認証はパスワードベースの認証よりはるかに強力です。仮に最悪のケースを想定したとしても、暗号化トークンが使用できるのは一度に一人だけです。パスワードは他のユーザーによって推測されたり暴露されたりすることがあり得るため、パスワードのみの認証方式では、最悪の場合、非常に多くの人々が不正なアクセスを行う可能性があります。 秘密鍵をファイルとして保管する場合、通常、この鍵はパスワードによって暗号化されます。しかし、この方法の問題は、クライアント上でスパイウェアなどを利用したり、パスワードのアタックをかけることにより、暗号化された鍵が復号化されてしまう可能性があることです。暗号化デバイスを使用するときとは異なり、復号化に何回も失敗したときに鍵を自動的に消去する機能もありません。 PKCS#11とは？この標準は、暗号化情報を保持したり暗号化機能を実行したりするデバイスのAPI（Cryptoki）を定義しています。Cryptokiは「cryptographic token interface」を短縮したもので、crypto-keyと発音しますが、シンプルなオブジェクトベースのアプローチに従い、特定の技術やデバイスに依存せず、リソースを共有化（複数のアプリケーションが複数のデバイスにアクセス可能）するという目標のもと、暗号化トークンのようなデバイスにアプリケーションがアクセスするための共通の論理ビューを提供します。 要約すると、PKCS#11はアプリケーションがスマートカードや他の暗号化トークンにアクセスするために使用される標準仕様です。デバイス開発元の多くはPKCS#11プロバイダインターフェイスを実装したライブラリを提供しており、このライブラリを使用してアプリケーションはデバイスにアクセスすることができます。PKCS#11はクロスプラットフォームであり、特定のベンダーに依存していません。 PKCS#11プロバイダライブラリを見つける最初にしなければならないことは、デバイスドライバと共にインストールされているはずのプロバイダライブラリを探し出すことです。各ベンダーはそれぞれ独自のライブラリを提供しています。たとえば、OpenSC PKCS#11プロバイダであれば、Unixでは/usr/lib/pkcs11/opensc-pkcs11.so、Windowsではopensc- pkcs11.dllです。 暗号化トークンの設定方法以下の登録手順に従ってください。
これらの設定が終わったトークンは、同じIDとラベル属性を持った秘密鍵と証明書を格納しているトークンとなります。 簡単な登録用ユーティリティとしてOpenVPN 2.1シリーズの一部であるEasy-RSA 2.0が用意されています。READMEファイルに書かれている手順に従い、その後pkitoolを使って登録してください。 トークンの初期化は以下のコマンドで行います。 $ ./pkitool --pkcs11-slots /usr/lib/pkcs11/<provider> 証明書の登録は以下のコマンドで行います。 $ ./pkitool --pkcs11 /usr/lib/pkcs11/<provider> <slot> <label> client1 暗号化トークンを使用するようにOpenVPNを設定するにはPKCS#11の機能を使用するには、OpenVPN 2.1以降のバージョンである必要があります。最新のβ版をhttp://openvpn.net/download.htmlから入手できます。 正しいスロットを識別する各PKCS#11プロバイダは複数のデバイスをサポートしており、スロットごとに1つのデバイスがあります。スロットの一覧を表示するには下記のコマンドを実行します。 $ openvpn --show-pkcs11-slots /usr/lib/pkcs11/<provider> このコマンドの出力から、特定のスロットを指定することができます。たとえば、pkcs11-slot-type idとpkcs11-slot 1オプションや、2番目のスロットを選択するためにpkcs11-slot-type nameとpkcs-slot "My reader 01 00"のように使用します。また、トークン名でスロットを選択することもできます。たとえば、Token1があるスロットを指定するにはpkcs11-slot-type labelとpkcs11-slot "Token1"オプションを使用します。 正しいオブジェクトを識別する各PKCS#11トークンには複数のオブジェクトが含まれています。各オブジェクトにはidとlabelという特殊な2つの属性があります。トークンに何が含まれているのかを確認するには、次のコマンドを実行します。 $ openvpn --show-pkcs11-objects /usr/lib/pkcs11/<provider> <slot-id> このオブジェクトへの参照は次のようになります。
OpenVPNをPKCS#11と組み合わせて使用する
PKCS#11実装に関する考慮事項多くのPKCS#11プロバイダはスレッドを使用していますが、LinuxThreads（setuid、chroot）の実装上の問題を避けるため、PKCS#11を使用する予定であればglibcを有効にしたNative POSIX Thread Library （NPTL）にアップグレードすることをお勧めします。 OpenSC PKCS#11プロバイダOpenSC PKCS#11プロバイダはUnixであれば/usr/lib/pkcs11/opensc-pkcs11.so、Windowsであればopensc-pkcs11.dllです。 PKCS#11と Microsoft Cryptographic API（CryptoAPI）の違いPKCS#11はフリーで、ベンダーに依存せず、クロスプラットフォームな標準です。CryptoAPIはマイクロソフト特定のAPIです。多くのスマートカードベンダーは両方のインターフェイスをサポートしています。Windows環境ではユーザーはどちらのインターフェイスを使用するか選択しなければなりません。 MS CryptoAPI（cryptoapicertオプション）を使用したOpenVPNの現在の実装は、サービスとして実行させなければ問題なく動作します。管理された環境下でサービスとしてOpenVPNを実行させたい場合は、下記のような理由により多くのスマートカードが正しく動作しない可能性があります。
PKCS#11インターフェイスを使用すると、PKCS#11はMicrosoftストアにアクセスする必要がなく、エンドユーザーに問い合わせを行う必要もないので、任意の実装においてOpenVPNをスマートカードと組み合わせて使用できます。 クライアントのすべてのトラフィック（Webトラフィックを含む）をVPN経由にルーティングする概要OpenVPNが有効になっているとき、デフォルトではOpenVPNサーバーのネットワークとのやり取りのみVPN上での通信が行われます。通常のWebブラウジングなどは直接接続され、VPNを経由することはありません。 特定のケースにおいては、Webブラウジングなどを含むすべての通信をVPN経由で行いたいということがあります。この設定はクライアント上のパフォーマンスの低下は避けられませんが、VPN管理者にとってはクライアントが通常のインターネットとVPNに同時に接続する場合でもセキュリティポリシーの適用が行いやすくなります。 設定サーバー設定ファイルに下記の設定を追加します。 push "redirect-gateway def1" VPNが無線LANに接続されており、すべてのOpenVPNクライアントとOpenVPNサーバーも同じ無線LANのサブネット上にある場合は、localフラグを追加します。 push "redirect-gateway local def1" redirect-gatewayをクライアントにプッシュすると、クライアントPCからのすべてのIPネットワークトラフィックがOpenVPNサーバーを経由するようになります。これにより、サーバーではトラフィックをどのように扱うか、たとえばインターネットにNATで接続させたり、サーバーのネットワーク上にあるHTTPプロキシに渡したりするなどの設定を行う必要があります。 Linuxの場合は、次のようなコマンドでVPNクライアントのトラフィックをインターネットにNATで接続させることができます。 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE このコマンド例では、VPNサブネットが10.8.0.0/24（OpenVPNサーバー設定のserverディレクティブによる）で、ローカルEthernetインターフェイスがeth0であることを想定しています。 redirect-gatewayディレクティブを使用すると、OpenVPNクライアントはDNS問い合わせもVPN経由で行うようになるため、VPNサーバーがDNS問い合わせも処理できるようにする必要があります。これは、VPNが接続しているときに使用できるDNSサーバーのアドレス情報をクライアントにプッシュすることによって行えます。 push "dhcp-option DNS 10.8.0.1" これにより、Windowsクライアントの場合はDNSサーバーとして10.8.0.1を使用するようになります（Windows以外のクライアントの場合はサーバー側のスクリプトが必要です）。DNSサーバーのアドレスにはクライアントから接続できるアドレスを使用してください。 注意事項すべてのネットワークトラフィックをVPN経由にすることは、問題になることもあり得ます。以下のような点に注意する必要があります。
redirect-gatewayディレクティブの仕組みについては、こちらを参照してください。 動的IPアドレスでのOpenVPNサーバーの運用OpenVPNクライアントは動的IPアドレスでも特別な設定なしでサーバーに接続できます。また、サーバー自身が動的アドレスであっても問題ありません。 OpenVPNはいくつかの追加設定を行えば、動的IPアドレスでのサーバーでも問題なく動作します。 まず最初に必要なステップは、サーバーのIPアドレスが変わるたびにIPアドレスを更新できる、ダイナミックDNSのアドレスを取得することです。 dyndns.orgなど、いくつかのダイナミックDNSサービスが提供されています。 次に、サーバーのIPアドレスが変わるたびにDNSを更新するようセットアップすることです。これによって、クライアントはサーバーのIPアドレスが変わっても接続先を特定できます。これには2つの方法があります。 クライアント設定ファイルでremoteディレクティブを使ってダイナミックDNS名を設定すると、デフォルトでOpenVPNクライアントはサーバーのIPアドレスの変更を検知します。この動作の流れとしては (a) OpenVPNクライアントが古いIPアドレスからのキープアライブメッセージの受信に失敗して再起動が行われ、(b) 再起動時にremoteディレクティブで指定されたアドレスが再度解決され、新しいIPアドレスに接続できるようになります。 動的IPアドレスについてはFAQも参照してください。 HTTPプロキシ経由でのOpenVPNサーバーへの接続OpenVPNはHTTPプロキシ経由での接続をサポートしており、次の認証モードが使用可能です。
HTTPプロキシを利用するには、トンネルキャリアプロトコルとしてTCPを使用していなければなりません。サーバーとクライアントの設定ファイルで次のように記述されている必要があります。 proto tcp proto udpの記述は削除してください。 http-proxy 192.168.4.1 1080 HTTPプロキシで基本認証が必要な場合は次のようにします。 http-proxy 192.168.4.1 1080 stdin basic HTTPプロキシでNTLM認証が必要な場合は次のようにします。 http-proxy 192.168.4.1 1080 stdin ntlm この2つの認証方法の例では、OpenVPNはユーザー名とパスワードを標準入力から読み込みます。もしファイルから読み込ませたい場合にはstdinをファイル名に置き換え、そのファイルの1行目にユーザー名を、2行目にパスワードを記述してください。 OpenVPN経由でSamba共有に接続するこのサンプルでは、ルーティングでのdev tunトンネルを経由してOpenVPNクライアントがSamba共有に接続する方法を説明します。ブリッジを使用している場合（dev tap）はOpenVPNクライアントがサーバー側ネットワークにあるPCを参照できるため、下記の手順は必要ありません。
SambaとOpenVPNサーバーが別のPCで動作している場合は、「クライアント側、またはサーバー側サブネットへのクライアントPCの追加によるVPNの拡張」で説明された手順を確認してください。 次に、Samba設定ファイル（smb.conf）を編集します。hosts allowディレクティブにおいて、10.8.0.0/24サブネットから接続してくるOpenVPNクライアントが接続できるよう許可してください。次のように設定します。 hosts allow = 10.66.0.0/24 10.8.0.0/24 127.0.0.1 SambaとOpenVPNサーバーが同一PC上で動作している場合は、smb.confファイルのinterfacesディレクティブを編集し、10.8.0.0/24のサブネットのTUNインターフェイスもリッスンするようにします。 interfaces = 10.66.0.0/24 10.8.0.0/24 SambaとOpenVPNサーバーが同一PC上で動作している場合は、OpenVPNクライアントからSamba共有にフォルダ名を使って接続します。 \\10.8.0.1\\sharename SambaとOpenVPNサーバーが別々のPCで動作している場合は、次のように接続します。 \\10.66.0.4\sharename たとえば、コマンドプロンプトで次のように入力します。 net use z: \\10.66.0.4\sharename /USER:myusername ロードバランス/フェールオーバー構成クライアントOpenVPNクライアントは複数のサーバーを参照するように設定することができます。これにより、ロードバランシングやフェールオーバーが実現できます。 remote server1.mydomain このように設定すると、OpenVPNはServer1、Server２、Server3の順番に接続しようとしますが、既存の接続が切断された場合、OpenVPNクライアントは直前まで接続していたサーバーに再接続しようとします。接続できなかった場合、リストの次のサーバーに接続しようとします。また、リスト上にあるサーバーに対してランダムに接続するよう設定することもできます。これによって結果的に各サーバーの負荷が分散しやすくなります。 remote-random さらに、OpenVPNクライアントがDNS参照に失敗したときに次のサーバーに接続させるようにするには、以下のようにします。 resolv-retry 60 この「60」という値は、リストの次のサーバーに移る前にOpenVPNクライアントがremoteで定義されている各サーバーのDNS参照を60秒間試行するよう設定するものです。 remote smp-server1.mydomain 8000 サーバーがマルチプロセッサのPCを使用している場合、複数のOpenVPNデーモンを実行する際のパフォーマンスの向上が期待できます。 サーバーロードバランシング/フェールオーバーを実現する最も簡単な方法は、クラスタ内の各サーバーで同一の設定ファイル（仮想IPアドレス範囲だけはそれぞれ別個に設定します）を使用することです。 server1server 10.8.0.0 255.255.255.0 server2server 10.8.1.0 255.255.255.0 server3server 10.8.2.0 255.255.255.0 OpenVPNのセキュリティを強化するネットワークセキュリティの鉄則の1つは、「ひとつのセキュリティコンポーネントに決して大きな信頼を置かない」ということです。1つに大きく依存してしまうと、セキュリティに壊滅的な損害を与える可能性があるためです。OpenVPNではこのような問題に対応するため、セキュリティレイヤーを追加するためのいくつかの方法を提供しています。 tls-authtls-authディレクティブを指定すると、整合性の検証を行うためのすべてのSSL/TLSハンドシェイクパケットにHMAC署名が追加されます。正しいHMAC署名を有していないUDPパケットは、その後の処理は行われずに破棄されます。 tls-auth HMAC署名はSSL/TLSによって提供されるセキュリティに加えてさらに高度なセキュリティを提供し、次のような攻撃や問題に対処できます。
tls-authを使用する場合は、標準のRSA証明書と鍵に加えて、共有静的鍵を生成しておく必要があります。 openvpn --genkey --secret ta.key このコマンドを実行するとOpenVPNの静的鍵が生成され、ファイルta.keyに書き込まれます。この鍵ファイルをサーバーとすべてのクライアントにコピーしておく必要があります（安全な方法でコピーするように注意してください）。このファイルはRSAの.keyと.crtファイルのあるディレクトリに入れておきます。 tls-auth ta.key 0 クライアント設定ファイルに以下の行を追加します。 tls-auth ta.key 1 proto udpOpenVPNでは、VPNキャリアプロトコルとしてTCPかUDPのいずれかのプロトコルを使用することができますが、UDPプロトコルのほうがDoSアタックやポートスキャニングに対して強力です。 proto udp 非特権モード（Linuxのみ）Linux上では、OpenVPNを非特権モード内で動作させることができます。設定はやや複雑になりますが、最良のセキュリティが提供されます。 この構成で動作させるには、設定スクリプトで --enable-iproute2 を指定し、OpenVPNでiprouteインターフェイスを使用するように設定する必要があります。また、システム上でsudoパッケージが利用可能になっている必要もあります。 この構成では、Linuxの機能を使用してtunデバイスのパーミッションを変更し、非特権ユーザーがアクセスできるようにします。また、インターフェイス設定とルーティングテーブルを変更するため、sudoを使ってiprouteを実行します。 以下のように設定します。
/usr/local/sbin/unpriv-ipスクリプトのパラメータ設定により、さらにセキュリティを高めることができます。 user/group （Windows以外の場合）OpenVPNはインストール後、ルート権限をドロップさせてもきちんと動作するように設計されており、Linux/BSD/Solarisではこの機能を利用することをお勧めします。OpenVPNサーバーデーモンをルート権限なしで動作させると、外部からの攻撃に対して強化されます。 user nobody chroot （Windows以外の場合）chrootディレクティブを使用すると、OpenVPNデーモンをchroot jailにロックさせることができます。これにより、OpenVPNデーモンはパラメータで指定された特定のディレクトリ以外のディレクトリにアクセスできなくなります。たとえば、次のように設定したとします。 chroot jail この設定により、OpenVPNデーモンは初期化時にjailディレクトリに移動し、このディレクトリをルートディレクトリとして扱います。これにより、OpenVPNデーモンはjailディレクトリとそのサブディレクトリ以外のファイルにアクセスできなくなります。これにより、たとえ攻撃を受けたとしてもサーバーのファイルシステムを保護することができます。 [注] chrootを利用する場合には、OpenVPNが初期化後に使用するすべてのファイルをjailディレクトリに配置しておく必要があります。たとえば、下記のようなファイルです。
・ crl-verifyファイル ・ client-config-dirディレクトリ RSA鍵のサイズを大きくするRSA鍵サイズはeasy-rsa/varsファイルのKEY_SIZE変数で制御されており、すべての鍵を生成する前に設定しておく必要があります。デフォルトでは1024に設定されていますが、この値は2048まで増加させることができます。値を大きくしてもVPNトンネルのパフォーマンスそのものに悪影響はありませんが、各クライアントが1時間おきに実行するSSL/TLSの再ネゴシエーションにかかる時間が若干増えます。また、初期設定時に一度だけ行うeasy-rsa/build-dhスクリプトを使ったDiffie Hellmanパラメータの生成に時間がかかるようになります。 対称鍵を大きくするデフォルトではOpenVPNは128ビットの鍵を使用したBlowfishを使用します。 cipher AES-256-CBC ルート鍵（ca.key）をネットワークから切り離されたPC上に確保するX509 PKI を使用するメリットの1つは、ルートCA鍵（ca.key）をOpenVPNサーバー上に置いておく必要がないことです。高いセキュリティが必要な環境では、鍵の署名のための専用PCを用意しておき、そのPCを物理的に安全な場所に設置し、ネットワークから切り離しておきます。鍵ファイルの移動にはフロッピーディスクなどが使用できるでしょう。これにより攻撃者がルート鍵を盗むことは（物理的にそのPCにアクセスできなければ）非常に困難になります。
証明書の失効「証明書の失効」とは、以前署名した証明書を無効にし、認証できなくすることです。 下記のような場合に、証明書を失効させることがあります。
例この例では、このHOWTOの中で生成したclient2証明書を失効させます。 . ./vars Windowsの場合は次のようにします。 vars すると、次のようなメッセージが表示されます。 Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf 最後の"error 23"が気になるかもしれませんが、このメッセージは問題ありません。これは、失効させた証明書の検証に失敗したということを示しているからです。 crl-verify crl.pem これにより、すべての接続クライアントはCRLによって検証され、CRLにマッチした接続はドロップされることになります。 CRLに関する注意事項
クライアントが接続先のサーバー証明書を検証しない場合に発生する可能性のある「Man-in-the-Middle」攻撃について認証済みのクライアントがサーバーを偽装して他のクライアントに接続しようとする「Man-in-the-Middle」攻撃の可能性を回避するために、各クライアントにサーバー証明書を強制的に検証させることができます。これを実現するには下記の5つの方法があります（優先順）。
サンプル設定ファイルsample-config-files/server.conf################################################# sample-config-files/client.conf##############################################
|
