VPNゲートウェイ経由のEAP：メソッドを終端するのは誰か

ヘルプデスクのチケットは、失敗したVPNログインと、より強力なメソッドを要求するRADIUSポリシーを同じ問題のように書くが、そうではない。ゲートウェイは資格情報を受け取って転送するか、クライアントと認証サーバーの間でEAPの会話を運ぶ。どちらが起きているかで、サーバー側の変更が何かを直せるかが決まる。サーバーグループを編集する前に、そのやり取りを読んでほしい。

ログでは同じに見える二つの認証経路

第一の経路では、VPNゲートウェイがユーザー名とパスワードを集め、パスワード属性を付けたRADIUS Access-Requestを送る。認証サーバーはそれを自分の資格情報ストアと照合し、受け入れか拒否を返す。クライアントはEAPメソッドを一度も実行しない。誰も要求していないからだ。

第二の経路では、クライアントと認証サーバーがEAPメソッドを端から端まで実行し、ゲートウェイは両者の間でEAP-Message属性を転送する。ゲートウェイは外側のRADIUSの会話は依然として終端するが、メソッドの論理は両端にある。

どちらの経路も、認証に失敗したという行をログに残す。サーバーが好むEAPメソッドの影響を受けるのは第二の経路だけで、ゲートウェイがパスワードをどう読むかの影響を受けるのは第一の経路だけだ。両者を交換可能と見なすと、PEAPを話す気のなかったクライアントのために、チームは丸一日サーバーグループを変更して過ごすことになる。

メソッドが実際に動く場所

RFC 3579はパススルーの取り決めを定義する。NASはEAPパケットをRADIUS属性で運び、EAPの種類ごとに専用コードを必要としない。だからゲートウェイはPEAPもEAP-TLSも、どちらも実装せずに対応できる。

パスワードを送るゲートウェイはPEAPを運んでいない。バックエンドが別のクライアントからのPEAPを受け入れるとしても同じだ。サーバーポリシーでPEAPを有効にしても、一度も提案しなかったクライアントにメソッドは追加されない。

PPP認証の設定はPPPサービスに属する。同じAAAサーバーを使うすべてのIPsecや旧来のXAuth経路を黙って再設定するわけではないので、一方のアクセス種別で有効な変更が他方をそのまま残すことがある。

NASが対応すべきこと

パススルーは要件をメソッドのコードから搬送側の対応へ移す。ゲートウェイは自分のVPNプロトコルでEAPを運べなければならず、その上のRADIUSクライアントは該当するサイズのEAP-Message属性を送受信できなければならない。

IKEv2ではEAPは定義された認証フローの一部であり、サーバーの身元と信頼の確認はそのフローから来る。802.1Xの導入から借りたPEAPのラベルは自動では移らない。周囲のネゴシエーションが異なるからだ。

クライアント側にも要件がある。メソッド用に設定され、メソッドが提示するサーバー証明書を信頼し、メソッドが使える資格情報を持つ必要がある。クライアント証明書のない証明書ベースのメソッドは、RADIUSが何かを見る前に失敗する。これはサーバーポリシーではなく配備の問題だ。

ポリシーを変える前に一度の試行を読む

ゲートウェイと認証サーバーで、承認された試行を一度キャプチャする。RADIUSリクエストにEAP-Message属性があるか探す。あればパススルー経路が使われており、なければ資格情報の交換を示す。

Linuxゲートウェイでは、RADIUSポートでのキャプチャが回線上にある属性を示す。

sudo tcpdump -ni any -X 'udp port 1812' -c 20

次に拒否点を比べる。RADIUSパケットより前にゲートウェイで失敗していれば、クライアントとゲートウェイがメソッドで合意していない。EAP属性を持つRADIUS拒否なら、両端がメソッドを実行し、どちらかが結果を拒否したということだ。

移行は端から端まで一つの変更として計画する

メソッドの変更は、クライアント設定、ゲートウェイの搬送対応、サーバーのメソッドポリシー、資格情報ストアをまとめて変えることだ。この順で行い、新しい経路が証明されるまで動く経路を残す。サーバー側だけの変更は推測であり、たいてい動いていたクライアントを壊す。グループに触れる前に、試験用のIDで変更を準備する。

動作する組み合わせを記録する。VPNプロトコル、EAPの搬送、相手のメソッド、サーバーのメソッド、資格情報の種類、サーバー身元の確認だ。

管理用ログインのAAAは、作業が明示的に両方を含まない限りVPN認証と分けておく。リモートアクセス向けの変更が、それを終端する機器を管理する能力を奪ってはいけない。