Check Point や Nortel に対する vpnc：なぜハングするのか

vpnc が話せるのは XAuth 付きの IKEv1 だけです。Check Point SNX や Nortel Aventail のゲートウェイは資格情報の段階に到達しないため、まず製品を特定してください。

症状は誤解しやすいものです：vpnc が起動し、グループパスワードを尋ね、その後ネゴシエーションの段階で止まったまま、対象から応答がないと報告します。出力のどこにもゲートウェイ製品は書かれておらず、アカウントはブラウザーからは動作するため、パスワードの誤りやポートの遮断という結論に飛びつきがちです。こうした事例のほとんどでは、ゲートウェイはそもそも IPsec のピアではないので、交換が資格情報の検証まで進むことはありません。プロファイルの他の設定を変える前に、まずこのパターンを試す価値があります。

プロファイルの別の項目を編集する前に、製品を特定してください。

障害は資格情報の誤りに見える

vpnc はまず UDP 500 に IKE を送り、NAT トラバーサルが提示されれば UDP 4500 にも送ります。IPsec ではなく SSL を終端するゲートウェイはどちらにも応答しないため、クライアントは再試行し、最終的に一般的なエラーで諦めます。同じアカウントが小さな補助アプリを読み込むブラウザーポータル経由で動作するなら、トンネルが SSL ベースであり、クライアントが間違った問いを投げている強い兆候です。

ここでの失敗はユーザーアカウントについて何も語りません、資格情報は一度もゲートウェイに提示されていないからです。

ゲートウェイが提供するプロトコルを確認する

数分の調査で IPsec のピアと SSL ポータルを切り分けられます。クライアントが使うのと同じネットワークから実行し、文書に載っているポートではなく、応答するポートを読み取ってください。結果は保存してください、同じポートが、ゲートウェイの所有者がどのクライアントを支援すべきかを決めるからです。ゲートウェイの隣のホストからではなく、クライアントのネットワークから調べます。

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

ログインページへのリダイレクトを伴う 443 の開放と、500 と 4500 の無応答は SSL VPN を示します。443 で証明書を提示しつつ 500 と 4500 も開いている場合は、ウェブフロントエンドも動かす IPsec ゲートウェイを示唆し、まさに vpnc が想定したケースです。

Check Point の SSL Network Extender と Nortel の Aventail クライアントはどちらも第二のカテゴリーに属し、IKEv1 のグループ秘密は受け付けません。

vpnc のプロファイルが表現できることとできないこと

内部では vpnc がグループの事前共有鍵に対して IKEv1 を実行し、その後 XAuth で個々のユーザーの資格情報を送ります。設定ファイルにあるものはすべてその交換に属します：ゲートウェイ、グループ名、グループ秘密、ユーザー名、ユーザーパスワードです。これらの項目は一つのプロトコルを記述しており、どのような組み合わせでもクライアントに別のプロトコルを話させることはできません。

だからこそ、暗号リストを広げたり証明書チェックを無効にしたりしても、この種の障害は決して直りません。そうした変更は、ゲートウェイが待っていないネゴシエーションを弱めるだけです。

ゲートウェイに合うクライアントの選び方

Check Point のゲートウェイには、ベンダーがリモートアクセスの文書とともに公開している SNX パッケージを使い、そのゲートウェイのリリース向けにビルドされたものを選んでください。古い SNX ビルドは、現在のディストリビューションでは、もはやインストールされていない 32-bit ライブラリを前提とするため失敗しがちで、放棄されたパッケージにパッチを当てるより、サポート対象のプラットフォームでサポート対象のクライアントを動かすほうが通常はましです。

Aventail クライアントはとうにサポートを失いました。そうしたゲートウェイが現役の場所では、現実的な選択肢は、組織が有効にしていればブラウザーポータル、あるいはサポート対象のオペレーティングシステム上でベンダーのサポート対象クライアントです。

ゲートウェイの所有者に、製品とバージョン、Linux でサポートしているクライアント、そもそも IPsec プロファイルが存在するかを尋ねてください。存在するなら、ユーザーパスワードとは別物であり取り違えた組がトンネル失敗のもう一つの一般的な原因でもあるため、グループ識別子とグループ秘密を別々の項目として求めてください。接続が最終的に成功したら、どのプロトコルで交渉したかを記録し、次の担当者が同じ推測を繰り返すのではなく事実から始められるようにしてください。

関連記事