安定した VPN クライアントアドレスのための RADIUS Framed-IP-Address

RADIUS は特定のユーザーに対してアドレスを返すことができますが、トンネルが実際にそれを受け取るかどうかはゲートウェイ次第です。安定したアドレスの計画の多くは、返されたアドレスと適用されたアドレスの間のこの隙間で失敗します。テスト応答に属性があることは、サーバーがそれを送信できることを証明するだけで、リモートアクセスサービスがそれを適用することを証明するものではありません。以下の手順では、アドレスがファイアウォールの規則に入る前に両方を確認します。

どの層がアドレスを所有するかを決める

リモートアクセスゲートウェイには通常ローカルプールがあり、多くは認証応答からアドレスを受け取ることもできます。どちらが優先されるかはプラットフォーム、プロトコル、サービスの構成によって異なるため、使用中の正確なリリースの優先規則を確認してください。ローカルプールが優先される場合、属性は飾りにすぎず、クライアントは結局ランダムなアドレスに落ち着きます。返された値がプールの範囲内にある必要があるか、範囲外でもよいかを決めて記録してください。

RFC 2865 は Framed-IP-Address をユーザーに設定すべきアドレスと定義しており、特定のゲートウェイがそれを尊重するかどうかについては何も述べていません。優先順位についての権威は属性の定義ではなく、ベンダーのドキュメントです。

テスト要求を送り、応答を読む

まずサーバーを単独でテストし、属性の欠落をゲートウェイの問題と誤解しないようにします。radtest はひとつの Access-Request を送信し、返ってくる属性を表示します。

radtest alice 'S3cret' 127.0.0.1 0 testing123

Access-Accept の中に Framed-IP-Address があることを確認し、値が意図したものであって、フォールバック規則によるプールアドレスではないことを確かめます。属性がない場合、ユーザーエントリまたは認可ポリシーが一致しておらず、ゲートウェイの調整ではサーバーが一度も送らなかったものを補えません。応答を特定の規則にたどるのが難しい場合は、サーバーをデバッグモードで実行したまま要求を繰り返します。共有シークレットは、上のプレースホルダーが資格情報ではないため、シェル履歴やチケットに残さないでください。

ゲートウェイが値を尊重したことを確認する

正しい応答は契約の半分にすぎません。トンネルインターフェースに現れるアドレスが重要であり、ゲートウェイの構成から推測するのではなくクライアントで読み取ります。

ip -4 addr show tun0

そのアドレスを Access-Accept の属性と比較します。不一致は、ゲートウェイが値を無視したか書き換えたことを意味し、最初の節の優先順位の問いが再び開きます。最初の試行だけで機能する予約は、通常、古いセッションまたは前の接続がまだ保持しているリースを示すため、もう一度接続し直してください。ゲートウェイのリリースとプロトコルを結果の横に記録し、次の担当者が動作がバージョン固有かどうかを判断できるようにします。

同時接続と失効を計画する

ゲートウェイがログイン以外の何かでセッションを区別しない限り、ひとつのユーザー名を複数のデバイスで同一のアドレスに対応させることはできません。対応付けが個人、登録済みデバイス、証明書 ID のどれに属するかを決め、その選択をポリシーストアに明記します。ここでの衝突は後になってルーティングの障害として再発するため、同時に接続するふたつ目のクライアントをテストし、割り当てられた両方のアドレスを比較してください。古いファイアウォール規則がまだそのアドレスを参照している間に再割り当てすると認可の不具合になるため、失効の計画にも同じ注意が必要です。

安定したアドレス指定は規則とログを単純にしますが、パケットを誰が生成したかを決して証明しません。そのアドレスが後で別のセッションに移るとき、認証と宛先の認可は依然として重要です。