ASA 원격 사용자가 서브넷에는 닿지만 앱에는 닿지 않는 이유
경로는 터널이 동작함을 증명할 뿐, 사용자가 앱을 열 수 있음을 증명하지 않습니다. 세션이 실제로 받은 필터를 읽고, 허용된 연결과 거부된 연결을 모두 시험하십시오.
사용자는 연결하고 주소를 받고 애플리케이션 서브넷의 서버에 핑이 통하는데도 그 위의 서비스를 열지 못합니다. 이 조합은 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 변경은 위험만 더합니다.