ASA のリモートユーザーがサブネットには届くのにアプリに届かない理由
ルートはトンネルが機能していることを示すだけで、ユーザーがアプリを開けることまでは示しません。セッションが受け取った実際のフィルターを読み、許可された接続と拒否された接続の両方を試してください。
ユーザーは接続し、アドレスを取得し、アプリのサブネット内のサーバーに ping が通るのに、そのサーバー上のサービスを開けません。この組み合わせは ASA では普通のことです。なぜなら トンネルの確立と、使える権限は、別々の設定で決まるからです。分割トンネルリストは、どの宛先をトンネルに入れるかを選びました。VPN フィルターと宛先自身のアクセスルールが、復号された要求が何に到達できるかを決めます。ルート一覧を広げる前に、三つの判断を順番に確認してください。
混同しやすい三つの判断
受け入れは、ユーザーがそもそもトンネルを確立できるかを決めます。資格情報、証明書、任意の第二要素です。経路選択は、クライアントがどの宛先をトンネルに送るかを決めます。認可は、復号された要求がサービスに到達できるかを決めます。ユーザーが報告するエラーを生むのは三つ目だけです。
見分ける近道は、変更によって何が壊れるかを問うことです。分割リストからルートを外すと、何も許可しないままそのサブネットへの通信が止まります。VPN フィルターに ACE を足すと、クライアントがトンネルに入れるものは変えずに宛先を許可できます。
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
セッションが実際に受け取ったフィルターを読む
適用されていると思う設定ではなく、稼働中のセッションから始めます。show vpn-sessiondb detail anyconnect は、割り当てられたグループポリシーと、そのセッションに付いたフィルター名を表示します。この項目が空なら、何も強制しているフィルターはなく、遮断は別の場所で起きています。
次に、その値を所有するポリシーを、既定値を含めて読みます。フィルターは、見ている場所に書かれているとは限らず、継承されていることがあるからです。
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
セッション上のフィルター名を、いま編集した ACL と比べます。ユーザーが受け取っていない、似た名前の ACL はそのセッションのリソースポリシーを変えられません。正しく見える変更が効かない最も一般的な理由がこれです。
優先順位が残りを説明します。フィルター設定では、DAP レコードがユーザー名属性より優先され、ユーザー名属性がグループポリシーより優先されます。想定外のフィルターがセッションに表示されたら、グループに触れる前にそのユーザーに一致する DAP ポリシーを探してください。
分割リストとフィルターは別の項目です
ASA 9.x では、グループポリシーは split-tunnel-network-list と vpn-filter を別の設定として保持しており、9.22 のグループポリシーガイドが両者を分けて記述しているのはそのためです。ネットワークリストはクライアントへの経路のヒントであり、フィルターは復号された通信に適用されるアクセス制御リストです。
ユーザーがサブネット内の HTTPS サービスを一つだけ必要とするとき、この区別が効きます。サブネットを分割リストに入れてパケットをトンネルに向け、そのうえでフィルターではそのサービスだけを許可します。ルート一覧を広げても何も認可されず、狭めても強制の仕組みにはなりません。
インターフェイス ACL が経路上にあるかどうかを確認する
復号されたリモートアクセスの通信は、人が思うようには必ずしも外側インターフェイスの ACL を通りません。sysopt connection permit-vpn が有効な場合、ASA はその通信に文書化された VPN バイパスを適用し、該当する VPN フィルターはその後も適用されます。設定は show run all sysopt で確認し、トポロジ図から推測しないでください。
いずれにせよ、宛先ホスト自身のファイアウォールとアプリの認可は経路上に残ります。TCP 443 を許可する ASA のルールは、アプリがユーザーを受け入れることにはなりません。
拒否される接続でも変更を確認する
許可されたテストだけではほとんど何も証明できません。フィルターの有無にかかわらず、正常なトンネルは同じ最初のパケットを生むからです。クライアントから目的のサービスを開き、次に閉じたままであるべき宛先を試して、正しい理由で失敗することを確かめます。
チケットを閉じるときは四つの事実を記録します。受け入れられた身元、セッションが実際に受け取ったポリシーとフィルター、分割リスト内の宛先、ユーザーに到達が許可されたリソースです。この四つがあれば、ルート一覧をファイアウォールに変えずに、通信がどこで制御されているかを説明できます。
フィルターが許可した後もサービスが拒否するなら、ホスト側に移ります。待ち受けアドレス、ホストのファイアウォール、アプリ自身のユーザーマッピングです。その時点でトンネルは役割を果たしており、これ以上の ASA の変更はリスクを増やすだけです。