固定 VPN IP：RADIUS の Framed-IP-Address かプール予約か

VPN クライアントに固定の内部アドレスを保持できる場所は 三つあり、所有すべきはそのうち 一つだけです。RADIUS は Access-Accept でアドレスを返せます。ゲートウェイはアカウントに対して静的なマッピングを保持できます。クライアントのアダプターは手動で設定できます。最初の 二つはポリシーであり、三つ目はゲートウェイが無視しても上書きしてもよいローカルな推測です。最初の 二つのどちらを選ぶかが本当の判断であり、それはネットワークアクセスサーバーが実際に何を実装しているかによって決まります。

固定アドレスが存在しうる 三つの場所

RADIUS は、応答が Framed-IP-Address を運び、ゲートウェイがその値をセッションに適用するときにアドレスを所有します。ゲートウェイは、管理者がアカウントをプール内の固定アドレスにマッピングするときに所有します。クライアントは何も所有しません。アダプターに手動アドレスが表示されていても、サーバーはネゴシエーション中に内部アドレスを割り当てるためであり、ローカル設定はサーバーが何も送らない場合にのみ意味を持ちます。三つとも動作中の接続では同じに見えるため、競合は遅れて表面化します。違いは再接続時、二台目の端末、ポリシー変更後に現れます。

所有者が 二つある構成が壊れます。RADIUS の応答が 172.28.4.77 を割り当て、ゲートウェイが 172.28.4.90 の静的マッピングを保持している場合、ベンダーのコードが先に確認した値が採用され、敗れた値はログ行も残さずに破棄されます。同じアカウントを 二台目の端末で使うと重複アドレスを受け取り、症状は割り当ての競合ではなくルーティング障害のように見えます。二つ目の仕組みを追加する前に所有者を決めてください。

クライアント側の選択肢は、除外できると示すためだけに挙げる価値があります。手動のアダプターアドレスは OS が提示しうる希望であり予約ではなく、別のセッションが同じアドレスを受け取るのを防げません。

RADIUS の応答が約束できることとできないこと

RFC 2865は Framed-IP-Address をユーザーに設定する IPv4 アドレスとして定義しており、これは Access-Accept に属します。Access-Request の同じ属性はサーバーが無視してよいヒントにすぎず、クライアントやゲートウェイが希望アドレスを提示する場合に重要になります。プロトコル上、ゲートウェイに応答の尊重を強制するものはありません。応答をセッションに適用するのはネットワークアクセスサーバーの役割だからです。

サポートはプロトコルではなく製品の問題です。既定でフレーム付きアドレスを適用するゲートウェイもあれば、グループレベルのスイッチを有効にしないと適用しないものもあり、属性を受け取ってもリモートアクセスセッションには決して使わないものもあります。最後のケースが危険で、アカウンティング記録には応答が残るのにクライアントはプールアドレスを受け取ります。動作は、実際に運用しているゲートウェイの型番とファームウェアで確認してください。姉妹製品のドキュメントでは不十分です。

ゲートウェイが無視する応答は、決して送られなかった応答とまったく同じに見えます。Access-Accept とセッションのアドレスを並べて読むことが、二つのケースを分ける唯一の方法です。

すでにルーティングしているプールの内側でアドレスを予約する

固定アドレスは、ゲートウェイがすでにルーティングし、ファイアウォールがすでに信頼しているプールのサブネットから選びます。その範囲外のアドレスは、ポリシー変更をルーティングのプロジェクトに変えてしまい、VPN は上がってもその背後にあるものは応答できません。アドレス単位のアクセスルールがある場合は、同じ変更で固定アドレスも追加してください。

二つ目の同時セッションがどう振る舞うべきかを決めます。一つのアドレスを 二回割り当てるのは端末管理ではなく、結果として生じる衝突は両方のセッションで断続的な接続として現れます。端末ごとに別の ID を発行するか、別の割り当てを発行するか、あるいは Simultaneous-Use のような対応済みのチェックで同時接続を強制し、古いセッションが切れるまでクライアントが再接続しないことを期待しないでください。

戻りルートにも割り当てと同じ注意が必要です。ゲートウェイにはプールへのルートが必要で、内部ルーターにはゲートウェイへの戻りルートが必要で、固定アドレスはその両方を継承します。一台のクライアントだけが動き他がすべて失敗する場合、通常はプールのルートはあっても予約アドレスのホストルートがないことを意味します。

リースを信頼する前に応答をテストする

AAA 側とセッション側は別々にテストしてください。失敗する理由が異なるからです。ローカルのradtestは、ゲートウェイを関与させずにサーバーがアカウントに対して何を返すかを示し、users ファイルのエントリはサーバーが何に一致すべきかを示します。その後クライアントを再接続し、受け取ったアドレスを応答の属性と比較します。

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

属性のない Access-Accept は、サーバーがエントリに一致しなかったか、そのユーザーに属性が適用されなかったことを意味します。属性のある Access-Accept でクライアントが依然プールアドレスを受け取るなら、ゲートウェイが無視したことになります。Access-Reject は資格情報またはグループポリシーに戻すものであり、これらの結果はクライアントのアダプターを編集してデバッグすべきではありません。

再接続後と、別の端末からの 二回目のログイン後に、同じ確認を繰り返します。最初のセッションでしか保たない予約は、起きるのを待っているプールの競合であり、監査中に見つけるより今見つけるほうが安く済みます。

所有者を 一つ選び、書き留める

ゲートウェイがフレーム付きアドレスを確実に適用するなら、割り当ては RADIUS に所有させ、同じアカウントの静的マッピングはすべて削除します。適用しないなら、ゲートウェイに所有させ、応答から属性を削除して、二つの情報源が食い違わないようにします。どちらもほぼ動くからと両方を残すと、将来のセッションが誤ったアドレスで、しかも明らかな原因もなく起きます。

選んだ所有者、予約したアドレス、その由来のプールをアカウント記録に書きます。次に端末を追加する人は、どちらかを変更する前に、そのアドレスが AAA のポリシーなのかゲートウェイのマッピングなのかを確認できます。