ASA の VPN クライアントが誤った DHCP プールからアドレスを取得する
ASA の dhcp-server と dhcp-network-scope を別々のフィールドとして読み、プール外のルーティング可能なアドレスに scope を設定し、その後ルートを確認します。
AnyConnect クライアントが誤ったサブネットに現れる、あるいは DHCP サーバーがまったくアドレスを渡さないのに、グループポリシーは一見正しく見える。ASA には「アドレスがどこから来るか」と聞こえるフィールドが二か所にあり、誤った側を設定するとまさにこの症状になる。接続プロファイルは DHCP サーバーを指定し、グループポリシーはそのサーバーが選ぶサブネットを指定する。 どちらもプールを作らない。
三つのオブジェクト、三つの問い
まず割り当てモデルとプールを切り分ける。二つのモデルは設定を共有しない。ASA 自身がアドレスを配るなら、ローカルプールを定義してグループポリシーをそこに向ける。外部の DHCP サーバーが配るなら、接続プロファイルがそのサーバーを指定し、グループポリシーが scope のヒントを与える。両者を混ぜることが、アドレスが現れない通常の原因である。
| Intent | Objects involved |
|---|---|
| ASA allocates from its own pool | ip local pool plus the group policy's address-pool |
| External DHCP allocates | dhcp-server on the tunnel group, dhcp-network-scope on the group policy |
変更する前に有効値を読む
省略された行は明示的な none と同じではない。実行中の設定は入力した内容を示すが、show run all group-policy は継承された既定値を含め、ポリシーが実際に何に解決されるかを示す。scope が誤っていると判断する前に両方を確認する。既定ポリシーを継承するグループポリシーは、短い一覧には現れない値を与えることがある。
show running-config group-policy RemoteStaff
show run all group-policy RemoteStaff
show running-config tunnel-group RemoteStaff
group-policy RemoteStaff attributes
dhcp-network-scope ?? の出力は導入済みリリースで読む価値がある。受け付ける値とヘルプテキストはバージョン間で異なる。Cisco ASA 9.24 のグループポリシーのリファレンス は、この属性を目的のサブネット上のルーティング可能なアドレスで、割り当てプールの外にあり、インターフェースアドレスが望ましいと記述している。プールの範囲でもネットワーク番号でもない。
scope は範囲ではなくアドレスに設定する
サーバーに使わせたいプールが /24 上の 10.50.30.50 から 10.50.30.200 で、そのセグメントの ASA インターフェースが 10.50.30.1 だとする。scope の値は 10.50.30.1 である。10.50.30.0 はネットワーク番号なので失敗し、範囲を書いても属性は一つのアドレスしか取らないので失敗する。選んだアドレスがインターフェースアドレスでないなら、DHCP サーバーの応答が届くようにスタティックルートが必要だ。
group-policy RemoteStaff attributes
dhcp-network-scope 10.50.30.1この断片は一つのことだけを行う。DHCP サーバーを設定せず、そこにプールも作らず、部分的なリモートアクセスプロファイルを動作するものにもしない。ここで文書化されている動作は IPv4 のみで、DHCPv6 やプレフィックス委任を制御するとは期待しないこと。
ロールバックポイントとともに変更する
まずスナップショットを取る。ロールバックが再構築ではなくコマンドになる。編集前に関連する設定をファイルに保存し、no がリリース上で何を戻すかを知っておく。属性を既定値または継承値に戻すので、上のポリシーではなく none になることがある。
copy running-config flash:pre-dhcp-scope.cfg
conf t
group-policy RemoteStaff attributes
no dhcp-network-scope
dhcp-network-scope 10.50.30.1
end
write memory属性を外すことも診断の手順になる。scope を定義しないと DHCP サーバーは自身のプールから未割り当てのアドレスを探すため、クライアントは想定外の場所に落ちるが少なくとも接続はする。その結果は要求の経路が機能し、失敗しているのがプールの選択だと教えてくれる。
アドレス、ルート、権限を確認する
割り当てはクライアントのダイアログではなくセッションテーブルから読む。そのうえでアドレスがトンネルへ戻る経路でルーティング可能か、グループポリシーのフィルターが想定した通信を許可しているかを確かめる。割り当ての判断はルーティングの判断ではなく、正しいプールからアドレスを得たクライアントでもすべての要求が失敗しうる。
show vpn-sessiondb detail anyconnect filter name testuser
show ip local pool
show route | include 10.50.30
ping 10.50.30.61 source insideセッションが意図したアドレスを示すのに通信が死ぬなら、scope は容疑者として片付いた。戻りのルート、グループポリシーの split-tunnel やフィルターの設定、DHCP scope が ASA の実際にルーティングするセグメントにあるかを見る。