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

選択肢 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
2つ目の層である、第2層トンネリングプロトコル(L2TP)は、セットアップがずっと容易です. L2TP は IPsec と同様にピアツーピア（2端点間）プロトコルです. クライアント側は「L2TP アクセス集線装置」(L2TP Acccess Concentrator) すなわち LAC と呼ばれ、サーバ側は「L2TP ネットワークサーバ」(L2TP Network Server) すなわち LNS と呼ばれます.

iptables を使っているならば、IPsec レイヤ外の L2TP 接続をブロックするつぎのようなルールを用いましょう:

ローカルのファイアウォールが だったら、 に対して、IPsec の認証に必要な ESP プロトコルの接続を双方向に許可し、IPsec 層以外の L2TP 接続をブロックしましょう. 以下のようなファイルを用いて実現可能です:

xl2tpd を用いる
ほかの L2TP サーバと異なり、 は、DHCP や RADIUS のサーバを用いなくとも、IP アドレスプールの管理が可能です. こうした機能はネットワーク階層構造を逸脱していますが、簡易なセットアップ時には極めて便利です:

他方で RADIUS や DHCP のサーバを用いるならば、 と   の箇所は空欄にしてください. もしも接続が不安定ならば、 のセクションに   を追加してみてください. もしも PPP 認証を行わないのであれば、 を   に変更しましょう.

オプション用のファイルもつくります:

PPP
最後の層は、ポイント・トゥ・ポイント プロトコル(PPP)層です. インストールすべきパッケージは です.

認証
PPP は認証に用いられます. PSK 認証による証明書と異なり、PPP 層は、エンドユーザが VPN にアクセスするのに必要な認証や権限付与のためにより多くのことを要します.

無認証
最も容易な pppd のセットアップ方法は、無認証にすることです. そのためには、"noauth" を指定せねばなりません. 無認証はテスト運用には至便ですが、それ以外の状況では奨められません. とりわけ、PSK 方式を利用しているときにはそうです. PKI 方式のときにはこのような設定が妥当なこともあります、例えば、
 * 全てのクライアントマシンが信頼可能で制御下にある
 * 全てのユーザが信頼可能で、鍵がユーザ自身以外のマシン上のどのユーザにもアクセス不可能である
 * 全ての接続が無人処理である（複数のサイトに接続する手法として用いている）

chap.secrets を通じた認証
小規模のユーザ（典型的には、ホームネットワークから外部に接続したいような状況）には、 ファイルを用いた認証で達せられます:

Samba を通じた認証
マシンが MS ドメインや AD（アクティブディレクトリ）フォレストの一部である（あるいはこれらをホスティングしている）のならば、クライアントは winbind を用いることも可能です. つまり、Samba を認証に用いることが可能です. を ppp オプションに追加しましょう. なお、そのための Samba と pppd のセットアップに関しては、この記事の対応範囲外です.

RADIUS を通じた認証
RADIUS サーバが同じマシンで稼働しているならば、pppd は RADIUS を利用可能です. USE フラグを有効にして をインストールしましょう. PPP オプションに  を追加します. なお、RADIUS と pppd のセットアップに関しては、この記事の対応範囲外です.

EAP-TLS を通じた認証
（マシンにではなく）ユーザ個人が証明書を保有していたら、pppd の認証に EAP-TLS を用いることも可能です. ユーザ認証が、スマートカードや RSA secureID で可能な場合には奨められます. USE フラグを有効にして をインストールしてください. RADIUS のセットアップも要します（上述）. も、PPP のオプションファイルに追加する必要があるかもしれません. このような pppd のセットアップ方法に関しては、この記事の対応範囲外です.

Windows: 証明書の適切なインストール (PKI の場合)
証明書は PKCS12 にパッケージングされていなければなりません. この処理は openssl か 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.

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 による記事