RouterOS OpenVPN と NPS: auth ではなく user-auth-method を設定する

RouterOS では auth がトンネルのダイジェストを選び、user-auth-method が RADIUS 要求の検査方法を決めます。後者を NPS ポリシーに合わせてください。

RouterOS は OpenVPN ログインで NPS に到達しても拒否されることがあり、よくある原因はどちらも認証のように聞こえる 二つの設定です。一方はトンネル用の暗号ダイジェストを選び、もう一方はユーザーの資格情報を RADIUS にどう提示するかを決めます。ダイジェストを変えても PAP 要求が MS-CHAPv2 になることは決してなく、サービスを何度再起動しても同じです。以下のチェックリストはこの 二つを分け、その後で 一件の失敗したログインを、それを判定した NPS ポリシーまで追跡します。

ステップ 1: どちらかを変更する前に両方の設定を読む

トンネルを終端するルーターで有効な OpenVPN サーバー設定を出力します。バックアップやコピーしたフォーラム投稿からではありません。重要な 二つのフィールドは通常同じメニューにあり、代替手段のように読めます。そうではありません。一方はデータチャネル、もう一方は資格情報の交換に関するものです。

/interface ovpn-server server print
/interface ovpn-server server export

auth フィールドは sha1 や sha256 などのダイジェストを列挙し、トンネルパケットを認証する HMAC を制御します。user-auth-method フィールドは pap か mschap2 を選び、ルーターがユーザーの資格情報を RADIUS にどう提示するかを決めます。ダイジェストの変更は 二つ目の動作を変えられず、だからこそ同じ拒否が 一つ目への調整のたびに残ります。

お使いのリリースが user-auth-method をまったく公開していない場合は、ここで止めてください。古い RouterOS ビルドでは OpenVPN サーバーで提供されないことがあり、修正は新しいものからコピーしたコマンドではなく、サポートできるリリースに属します。

ステップ 2: 実際にログインを拒否したポリシーを見つける

NPS 側では、接続要求がネットワークポリシーに対して評価され、一致したポリシーに記載された認証方法は、クライアントが実際に提示したものでなければなりません。要約件数を読むのではなく、一件の失敗したログインを時刻とユーザーで関連付けます。セキュリティログは許可された要求と拒否された要求を理由コード付きで記録し、ルーターの一般的な失敗行よりはるかに多くを伝えます。

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

イベントでは 三つを読みます。一致したポリシー名、認証方法、理由コードです。MS-CHAPv2 を要求するポリシーは、パスワードが正しくても PAP 要求を拒否し、ドメインアカウントを要求するポリシーはローカルアカウントを拒否します。RADIUS クライアントのエントリもルーターの送信元アドレスと一致する必要があり、そうでなければポリシーが参照される前に要求が破棄されます。これらのどれも OpenVPN ログには現れません。

要求が NPS にまったく届かない場合は、ここで止めてください。それは共有シークレット、クライアントアドレス、または UDP 1812 の問題であり、認証方法を変えても解決しません。

ステップ 3: 両側で 一つの方法を変更する

承認された設計が MS-CHAPv2 なら、ルーターに設定し、一致するポリシーがそれを受け入れることを確認します。片側を変えて再テストし、その後に反対側を変えます。両方を一度に変えると、どちらが重要だったのか言えなくなります。

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

エラーを消すために NPS でより弱い方法をすべて有効にしないでください。バックエンドには、選んだ方法が検証できる材料が必要です。MS-CHAPv2 はパスワードまたはドメインへのアクセスを必要とし、ポリシーはその材料を発明できません。ポリシーを広げると、攻撃者が同じアカウントに対して試せることも広がります。方法、ポリシー名、変更参照をまとめて記録し、次の人が推測ではなく決定を引き継げるようにします。

トンネルの証明書検証は以前とまったく同じに保ちます。資格情報の方法はサーバー ID の代わりにはならず、テストを通すために TLS チェックを下げることは 一つの問題をより悪い問題と交換します。

ステップ 4: 三件のログインと 一つの権限をテストする

許可されたユーザー、誤ったパスワード、除外されたユーザーを、それぞれ新しいセッションでテストします。一つ目は経路を証明し、二つ目は資格情報の検査が本物であることを証明し、三つ目はポリシーが除外すべき人を依然として除外していることを証明します。キャッシュされたセッションは 三つすべてを隠せるので、試行の間に切断してください。

/log print where topics~"ovpn"
/radius monitor 0

認証の成功はチェックリストの終わりではありません。クライアントが受け取ったアドレスと、そのアドレスが到達できるリソースを確認します。ユーザーは正しく認証しても間違ったプールに落ちることがあるからです。割り当てられたアドレスが間違っている場合、問題は方法ではなく、プロファイルまたは RADIUS 応答属性にあります。チケットを閉じる前に両方を確認してください。

ルーター設定と NPS ポリシーが同じ方法を示し、許可されたユーザーが新しいセッションで接続し、誤ったパスワードが拒否され、除外されたユーザーが引き続き除外され、割り当てられたアドレスが意図したプールと一致するとき、チェックリストは完了です。それ未満では次のログインが偶然に委ねられます。

関連記事