IPsec L2TP VPN server/ja

多くのオペレーティングシステムは、L2TP/IPSec による VPN 機能を実装しています. L2TP/IPSec は、IPsec (インターネットプロトコル セキュリティ) による機密保持および認証サービス、レイヤ2トンネルプロトコル(L2TP)によるネットワークトンネリング、pppdを通したユーザ認証を組み合わせたものです. 管理者は、複数の異なるシステムをまたいでVPNネットワークを設定可能です. Android、Windows、GNU/Linux、macOSなどのオペレーティングシステム間で、商用ソフトウェアを一切追加することなしに、VPNを設定可能です.

はじめに
IPsec/L2TPは、Windowsなどのオペレーティングシステムで一般的に使用されているVPNプロトコルです. VPN クライアント側としては、Windows では 2000 以降のすべてのバージョンに組み込まれており、（OpenVPN などと異なり）外部クライアントを要せずとても便利です. 他方のサーバ側の Linux については、IPsec、L2TP および PPP の少なくとも3つのレイヤが関わってしまいますので、設定がずっと難しいです.


 * 1) IPsecの設定は、ネットワーク通信の機密性およびクライアント（システム）の認証を提供します
 * 2) L2TP でトンネルを設定することで、VPN トラフィックが透過的に IPsec を通過します
 * 3) PPP（ポイント・トゥ・ポイント プロトコル）の設定は、ユーザー認証を管理します

このガイドでは、DHCP や RADIUS、Samba、公開鍵インフラ（PKI）の設定を記載していません. Linuxをクライアントにする際の設定方法を記載していません（実際には、このガイドを読めば容易に判るはずですが）. そもそも、クライアント側の Windows の設定について記載しているのも、サーバ設定のトラブルシューティングに使うことを想定しているからにすぎません.

想定および設定例
このガイドでは、以下の状況を想定した設定例を記載しています（そのため実際の設定は、状況に応じて読み替えて行ってください）:


 * ドメイン名は example.com
 * サーバ名は vpn.example.com
 * CA(認証局) ファイル名は
 * サーバ側の認証ファイル名は
 * サーバ側の鍵ファイル名は
 * クライアント側の認証ファイル名は
 * クライアント側の鍵ファイル名は

IPsec
最初にセットアップするレイヤ（しかも最難関）が IPsec です. IPsec はピア・トゥ・ピア（1対1）なので、IPsec 用語としてはクライアントをイニシエータ、サーバをレスポンダと呼びます.

Windows は IKEv1 をその処理に用います. Portage にある IPsec の実装には、ipsec-tools (racoon)と LibreSwan、strongswan の3種類の選択肢があります.

次のセクションでは、それぞれ異なる設定が説明されています. それぞれの選択肢について以下を記載しています
 * どうやって認証に PSK を用いるか
 * どうやって認証に証明書を用いるか

PSK か証明書か、いずれか一つを選んでください. また、証明書による認証については、必要な証明書が既に用意されていることを前提にしています.

選択肢 1: ipsec-tools (racoon)
ipsec-tools は、最小限の機能で構成されていますが、BSD 系由来のものと比べると親しみやすくなっています. しかし、BSD 系と異なり、Linux は IPsec について別途のインターフェイスをもっていません.

ipsec-tools をインストールしたあとは、いくつかのファイルを作成せねばなりません. まず、これらファイルを置くディレクトリを作成します:

ipsec-tool における、PSK 方式でのセットアップ
まず、事前共有鍵(PSK)ファイルを作成します. このファイルは、ピア間の認証に用いる固有の鍵です.

PSK ファイルの各項目は、ID と鍵で構成されています. Windows では 完全ドメイン名(FQDN)を ID にしています. 鍵は、文字列もしくは（ 0x で始まる）16進数で表記されます. いずれにしても、内容（鍵そのもの）は、管理者のみが読み出します:

ファイルの中身では、 の設定項目でこの PSK ファイルを参照します.

ipsec-tools における、証明書方式でのセットアップ
と と を、 にコピーします. ファイルは、一般ユーザが読み書き不可能な属性にしてください.

つぎに、 ファイル内の  セクションでこれらのファイルを参照します:

ipsec-tools のトラブルシューティング
もしも支障が起こったら、このセクションが参考になる解決手段を指し示しているかもしれません.

セキュリティポリシーと NAT の作成
という設定で、適切なセキュリティポリシーが生成されます. しかし、NAT がある（少なくとも、サーバが NAT 裏にある）と、期待するようなポリシーが生成されません. したがって、もしもトンネル内をトラフィックが通らないようならば、ポリシーをマニュアルで定義しなければなりません.

にポリシーを作成します:

このポリシーでは、防護されるべきサーバとの L2TP トラフィックのすべてを通過させています. そのため、追加のセキュリティの関連付けなしにはトラフィックが全く防護されず、（認証や暗号化なしの）一般的な通信でインターネットを通過してしまいます. セキュリティの関連付けがないため拒否されることがありませんので注意してください.

選択肢 2: LibreSwan
LibreSwan は （FreeS/WAN のフォークである）OpenSwan のフォークです. 実際には、もともとの OpenSwan の制作者達によるフォークですが、彼らが Xelerance を辞めたあとに "Openswan" の名称をめぐって紛争になり訴訟に至りました. その結果として、LibreSwan という名称が採用されました.

それぞれの VPN 設定ごとにファイルを分けるのであれば、 の最終行のコメントを外せば可能です:

LibreSwan の設定ファイルでは、NAT トラバーサルがデフォルトで有効になっていますので、特別な設定作業は不要です.

LibreSwan における、PSK 方式でのセットアップ
共通鍵を作成せねばなりません. 鍵は、引用符で括られた文字列か、16進数字です. 次の例では、 を実際のサーバの IP アドレスに置き換えてください. ドメイン名を用いることも可能ですが、LibreSwan の制作者達は推奨していません. という設定は、この PSK を用いるあらゆるクライアントを許可します.

そして、 を作成します:

LibreSwan における、証明書方式でのセットアップ
LibreSwan のためには、Network Security Services (NSS) を要し、適切に設定されていなければならず、証明書の管理に用います. 容易にするためには、PKCS#12 バンドルには、サーバの秘密鍵と証明書、認証局(CA)の証明書がまとめておくべきです.

このバンドルを、NSS データベースにインポートします:

LibreSwan の設定ファイルは、インポートされた内容物をニックネームで参照します. や を用いればニックネームがわかります.

上記の例では、 がニックネームとして用いられており、 コマンドで判ります.

ここでは、 は コマンドで判るニックネームです.

選択肢 3: strongSwan
strongSwan は、FreeS/WAN のフォークの一つです. （多くのコードが書き換えられていますが. ）

strongSwan 5.0 以降では、NAT トラバーサルは自動になり、設定不要になりました.

strongSwan では が作成されませんから、自ら作成する必要があります:

strongSwan における、PSK 方式でのセットアップ
共通鍵を作成せねばなりません. 共通鍵は引用符で括られた文字列か、16進数字です. つぎの例は、 をサーバの IP アドレスに置き換えてください. は、あらゆるクライアントセレクタが、指定されている PSK で認証可能であることを意味します.

つぎに を下記の通り編集します:

left と right がともに  に設定されていると、strongSwan は local マシンを left であると認識します.

strongSwan における、証明書方式でのセットアップ
証明書と鍵は適切なディレクトリにコピーされねばなりません:

strongSwan に対して、公開鍵を認証に用いるように伝えます:

そして、 を下記の通り更新します:

前記と同様で、 left と right がともに  だと、strongSwan は local マシンを left であると認識します.

IPsec パススルー / 壊れた NAT
以前のバージョンの strongSwan では、IPsec パススルーは使えませんでした. 「接続不明のため IPsec SA 要求に応答不可能」あるいは（設定ファイルの編集のしすぎで）INVALID_HASH_INFORMATION エラーが起こりました. これは、strongSwan 5.0 以降では起こりません.

IPsec 一般のトラブルシューティング
IPsec は、取扱がそれほど平易ではありません. このセクションでは、一般的に起こる支障やエラーについて指し示しておきます.

NAT 裏のサーバ
サーバが NAT (Network Address Translation)裏にある場合、つまり多くはホームルータの裏にサーバがホスティングされている場合ですが、IPsec 接続を確実に動作させるには、特別な注意点があります.

ポートを開く
2つのポートを開く必要があります:
 * UDP ポート 500 (ISAKMP)
 * UDP ポート 4500 (NAT トラバーサル)

VPN サーバに転送することも忘れないでください.

さらに、（ポートではなく）以下のインターネットプロトコルを許可する必要があります:
 * 50 (ESP)
 * 51 (AH)

こうした設定は、ルータがプロトコル別に設定されている（およそスルーでない）際に必要になることがあります.

IPsec パススルー / 壊れた NAT
多くのルータは「IPsec パススルー」の設定が可能ですが、この意味は2種類あります:


 * 1) IPsec パケットを、IPsec NAT トラバーサルと異なる手法で加工する
 * 2) IPsec パケットを、ルータを通過させ加工しない

(1) は、IPsec パススルーが無効という意味. (2)は、IPsec パススルーが有効という意味です.

残念ながら、ポートフォワーディングを指定したときでさえも IPsec トラフィックをすべて棄て、上記 (1) しか不可能なルータもあります. こうしたルータにはつぎの3つの対処方法があります:


 * 1) ファームウェアを更新する. 新バージョンでは正しく動作させられる
 * 2) ルータの設計についてバグ・欠陥報告を出す（サポート終了していなければ）
 * 3) 別のルータを求めましょう. Linksys や D-link のルータは正しく動作するといわれています

このチュートリアルははじめ、そのようなルータ (Zyxel P-330W) のために書かれました. - そして (3) の選択肢しかありません.

Windows Vista/Server 2008 クライアント
こういう OS は NAT 裏の IPsec/L2TP サーバには自動的に対応しないのです. KB926179 を参照のうえ、レジストリを編集して対応させてください.

事前共有鍵 (PSK) の限界
IPsec プロトコルにおいて、PSK をやりとりする手段はありません. 通信元と通信先の IP アドレスに基づいてどの鍵を選ぶかという情報が得られるのみです. 多くの状況では、応答者は要求者の IP アドレスをあらかじめ知り得ないため、誰もが同じ事前共有鍵を使用するほかありません. よって、単一の接続しかない場合でさえも、事前共有鍵(PSK)方式よりも証明書(PKI)方式が推奨されます. しかし、証明書や PKI（公開鍵インフラストラクチャ）を作成するのは比較的複雑な作業ですので、この記事の対応範囲外です.

L2TP
The second layer, Layer 2 Tunneling Protocol (L2TP), is much easier to setup. Like IPsec, L2TP is a peer-to-peer protocol. The client side is called the L2TP Access Concentrator or LAC and the server side is called the L2TP Network Server or LNS.

When using iptables, use the following rules to block all L2TP connection outside the ipsec layer:

If the local firewall is then get  to accept incoming & outgoing connections using the ESP protocol to allow IPsec authentication, and to block all L2TP connections outside the IPsec layer. This can be accomplished by using the following file:

xl2tpd を用いる
Unlike other L2TP servers, can maintain an IP address pool without a DHCP or RADIUS server. This is a layering violation, but for a small setup it is extremely convenient:

To use a RADIUS or DHCP server, leave off the  and   parts. If the connection is unstable, try adding  to the   section. To not use PPP authentication, change  to.

Create the options file as well:

rp-l2tp を用いる
rp-l2tp の設定は簡素です:

Specify the server IP as well in lns-pppd-opts. Also don't forget to setup pppd to use an IP address pool, either via DHCP or RADIUS.

PPP
The final layer to configure is the Point-to-Point Protocol (PPP) layer. The package to install here is.

認証
PPP is used to perform authentication. Unlike the certificate based or PSK authentication, the PPP layer is more for authenticating (and authorizing) the end users' access to the VPN.

無認証
The easiest way to setup pppd is to not use any authentication at all. In that case, make sure "noauth" is specified. This is useful for testing purposes, but otherwise not recommended - especially when using PSK. For certain PKI setups, such a configuration may be sensible - for example,
 * all the client machines are fully trusted and under control, or
 * all the users are trusted and the keys are on machines no one else, besides the users' themselves, have access to, or
 * all connections are unattended (using this method to connected multiple sites)

chap.secrets を通じた認証
For small users (typically, those wanting to connect their home network from elsewhere), authentication can be done through the file:

Samba を通じた認証
When the machine is part of (or hosting) an MS Domain or AD forest, and the clients are using winbind, then Samba can do the authentication. Add  to the ppp options. Setting up Samba and pppd to do this is beyond the scope of this document.

RADIUS を通じた認証
When a RADIUS server is running on the same machine, pppd can use RADIUS. Ensure the  USE flag is set on. Then add  to the PPP options. Setting up RADIUS and pppd to do this is beyond the scope of this document.

EAP-TLS を通じた認証
If individual users have certificates (which is not the same as the machine certificate above), then setup pppd to authenticate via EAP-TLS. It is recommended that the users authenticate via smartcards or RSA secureID. Ensure the  USE flag is set on. RADIUS needs to be setup (see above). The  option might need to be included in the PPP options file as well. Setting up pppd to do this is beyond the scope of this document.

Windows: 証明書の適切なインストール (PKI の場合)
The certificate should be packaged in a PKCS12 package. This can be done through openssl or gnutls:

Once a file is created, import it into Windows. However, the method is not obvious. Do not double-click the key and follow the instructions, that won't work. That imports the key into a personal certificate store, but in Windows, it is the local computer that needs to do the authentication, so the certificate needs to be added to the local computer's key store. To do that, use the Microsoft Management Console (mmc). Administrator privileges are needed for this to work.

Expand the Certificates. Choose any folder (doesn't matter which), right-click, choose "All Tasks", then "Import". Only now follow the wizard, but on the last step, make sure to choose "Automatically select the certificate store based on the type of certificate".

Error 766: A certificate could not be found
If this error occurs, then this means the certificate was not imported correctly. Make sure to import it though MMC, and not by double-clicking the file.

Error 810: VPN connection not complete
When using ipsec-tools (racoon) the following message might occur in the system log:

This means the certificate was not imported correctly, or the p12 bundle is missing in the CA certificate. Make sure to import the key through MMC, and make sure to select "Automatically select the certificate store based on the type of certificate" at the end of the import process.

XP SP2 and above: Error 809: Server not responding (Server behind NAT)
Windows XP SP2 and Vista |will not, by default, connect to server behind a NAT. A registry hack is required. Separate fixes are required for Windows XP and Windows Vista.

Vista: Error 835 Could not authenticate
This one occurs only when using PKI. It means the subjectAltName does not match the server that the client is connecting to. This often occurs when using dynamic DNS - the certificate has the internal name rather than the external name. Either add the external name to the certificate, or disable "Verify the Name and Usage attributes of the server's certificate" in the connection definition, under Security -> Networking -> IPsec.

Error 741: The local computer does not support required encryption type
Windows will try to negotiate MPPE, a (weak) encryption. When then this error occurs.
 * the system is not using PPP authentication, or
 * the system does not have a pppd with MPPE support, or
 * MPPE is supported but not compiled into the kernel (or a module)

If PPP authentication is used, it is recommended to fix the pppd or kernel (which are minimal configuration changes) even though there's no point to have double encryption. If the system does not use PPP authentication, or the double encryption is definitely not wanted, then disable it by unchecking "Require data encryption" on the Security tab.

Mac OS X
Mac OS X clients appear to be picky on the proposals they will negotiate with. In particular:
 * dh_group must be.
 * my_identifier must be an address, not a fully qualified domain name (address is the default, so just leave that line out from ).

Mac OS X won't connect if subjectAltName does not match the server the client is connecting to. Unlike Vista this check cannot be disabled.

Also, Mac OS X won't connect if the server certificate contains any "Extended Key Usage" (EKU) fields (except for the deprecated ikeIntermediate one). In particular, when using certificates from the OpenVPN utility, it adds the "TLS WWW Server" or "TLS WWW Client" EKU, so such certificates will not work. However, such certificates can still be used on the Mac OS X client, as it doesn't care what is on the client certificate - only the server.

外部の情報

 * |Using a Linux L2TP/IPsec VPN server Jacco de Leeuw による記事