Catalyst 3750系列交换机上的ISE流量重定向
目录
简介
本文介绍用户流量重定向如何工作，以及交换机重定向数据包所需的条件。
先决条件
要求
思科建议您具有思科身份服务引擎(ISE)配置方面的经验，并了解以下主题的基本知识：
- ISE部署和集中Web身份验证(CWA)流程
- Cisco Catalyst交换机的CLI配置
使用的组件
本文档中的信息基于以下软件和硬件版本：
- Microsoft Windows 7
- Cisco Catalyst 3750X系列交换机软件，版本15.0及更高版本
- ISE软件，版本1.1.4及更高版本
背景信息
对于大多数使用ISE的部署而言，交换机上的用户流量重定向是一个关键组件。所有这些流量都涉及交换机使用流量重定向：
- CWA
- 客户端调配(CPP)
- 设备注册(DRW)
- 本地请求方调配(NSP)
- 移动设备管理(MDM)
重定向配置错误是部署存在多个问题的原因。典型的结果是网络准入控制(NAC)代理无法正确弹出或无法显示访客门户。
对于交换机没有与客户端VLAN相同的交换机虚拟接口(SVI)的场景，请参阅最后三个示例。
故障排除
测试场景
在客户端上执行测试，应重定向到ISE进行调配(CPP)。 用户通过MAC身份验证绕行(MAB)或802.1x进行身份验证。ISE使用重定向访问控制列表(ACL)名称(REDIRECT_POSTURE)和重定向URL（重定向到ISE）返回授权配置文件：
bsns-3750-5#show authentication sessions interface g1/0/2
Interface: GigabitEthernet1/0/2
MAC Address: 0050.5699.36ce
IP Address: 192.168.1.201
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 10
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1
URL Redirect ACL: REDIRECT_POSTURE
URL Redirect: https://10.48.66.74:8443/guestportal/gateway?sessionId=
C0A8000100000D5D015F1B47&action=cpp
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A8000100000D5D015F1B47
Acct Session ID: 0x00011D90
Handle: 0xBB000D5E
Runnable methods list:
Method State
dot1x Authc Success
可下载ACL(DACL)允许此阶段的所有流量：
bsns-3750-5#show ip access-lists xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1
Extended IP access list xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1 (per-user)
10 permit ip any any
重定向ACL允许此流量而不重定向：
- 发往ISE的所有流量(10.48.66.74)
- 域名系统(DNS)和互联网控制消息协议(ICMP)流量
所有其它流量都应重定向：
bsns-3750-5#show ip access-lists REDIRECT_POSTURE
Extended IP access list REDIRECT_POSTURE
10 deny ip any host 10.48.66.74 (153 matches)
20 deny udp any any eq domain
30 deny icmp any any (10 matches)
40 permit tcp any any eq www (78 matches)
50 permit tcp any any eq 443
交换机与用户在同一个VLAN中有一个SVI:
interface Vlan10
ip address 192.168.1.10 255.255.255.0
在接下来的部分中，将对此进行修改以显示潜在影响。
流量未到达重定向ACL
当您尝试ping任何主机时，应收到响应，因为该流量未重定向。要确认，请运行以下调试：
debug epm redirect
对于客户端发送的每个ICMP数据包，调试应显示：
Jan 9 09:13:07.861: epm-redirect:IDB=GigabitEthernet1/0/2: In
epm_host_ingress_traffic_qualify ...
Jan 9 09:13:07.861: epm-redirect:epm_redirect_cache_gen_hash:
IP=192.168.1.201 Hash=562
Jan 9 09:13:07.861: epm-redirect:IP=192.168.1.201: CacheEntryGet Success
Jan 9 09:13:07.861: epm-redirect:IP=192.168.1.201: Ingress packet on
[idb= GigabitEthernet1/0/2] didn't match with [acl=REDIRECT_POSTURE]
要确认，请检查ACL:
bsns-3750-5#show ip access-lists REDIRECT_POSTURE
Extended IP access list REDIRECT_POSTURE
10 deny ip any host 10.48.66.74 (153 matches)
20 deny udp any any eq domain
30 deny icmp any any (4 matches)
40 permit tcp any any eq www (78 matches)
50 permit tcp any any eq 443
流量到达重定向ACL
场景1 — 目标主机位于同一个VLAN中，存在且为SVI 10 UP
当您向交换机直接可到达的第3层(L3)的IP地址发起流量（交换机的网络具有SVI接口）时，会出现以下情况：
- 客户端向同一VLAN中的目的主机(192.168.1.20)发起地址解析协议(ARP)解析请求，并接收响应（ARP流量从不重定向）。
- 即使交换机上未配置目的IP地址，交换机也会拦截该会话。客户端与交换机之间的TCP握手已完成。在此阶段，没有其它数据包在交换机外部发送。在此场景中，客户端(192.168.1.201)已发起与该VLAN(192.168.1.20)中的另一台主机的TCP会话，并且交换机的SVI接口为UP（IP地址为192.168.1.10）：
- 建立TCP会话并发送HTTP请求后，交换机返回重定向到ISE（位置报头）的HTTP响应。
这些步骤由debugs确认。有几个ACL命中：epm-redirect:IP=192.168.1.201: Ingress packet on [idb= GigabitEthernet1/0/2]
matched with [acl=REDIRECT_POSTURE]
epm-redirect:Fill in URL=https://10.48.66.74:8443/guestportal/gateway?sessionId=
C0A8000100000D5D015F1B47&action=cpp for redirection
epm-redirect:IP=192.168.1.201: Redirect http request to https:
//10.48.66.74:8443/guestportal/gateway?sessionId=C0A8000100000D5D015F1B47&action=cpp
epm-redirect:EPM HTTP Redirect Daemon successfully created
这也可以通过更详细的调试来证实：debug ip http all
http_epm_http_redirect_daemon: got redirect request
HTTP: token len 3: 'GET'
http_proxy_send_page: Sending http proxy page
http_epm_send_redirect_page: Sending the Redirect page to ... - 客户端直接连接到ISE(到10.48.66.74:8443的安全套接字层(SSL)会话)。 此数据包不会触发重定向：
epm-redirect:IP=192.168.1.201: Ingress packet on [idb= GigabitEthernet1/0/2] didn't
match with [acl=REDIRECT_POSTURE]
场景2 — 目标主机位于同一个VLAN中，不存在，且为SVI 10 UP
如果目的主机192.168.1.20发生故障（没有响应），客户端不会收到ARP应答（交换机不会拦截ARP），客户端也不会发送TCP SYN。从不发生重定向。
这就是为什么NAC代理使用默认网关进行发现。默认网关应始终响应并触发重定向。
场景3 — 目标主机处于不同的VLAN中，存在，并且为SVI 10 UP
以下是此场景中发生的情况：
- 客户端尝试访问HTTP://8.8.8.8。
- 该网络不在交换机的任何SVI上。
- 客户端将该会话的TCP SYN发送到默认网关192.168.1.10（目标MAC地址已知）。
- 重新定向的触发方式与第一个示例完全相同。
- 交换机拦截该会话并返回重定向到ISE服务器的HTTP响应。
- 客户端访问ISE服务器时不会出现问题（流量不会重定向）。
场景4 — 目标主机处于不同的VLAN中，不存在，并且为SVI 10 UP
此场景与场景3完全相同。远程VLAN中的目标主机是否存在并不重要。
场景5 — 目标主机处于不同的VLAN中，存在，并且处于SVI 10关闭状态
如果交换机与客户端不在同一个VLAN中设置SVI UP，则它仍然可以执行重定向，但仅当匹配特定条件时才可以执行。
交换机的问题是如何将响应从其他SVI返回到客户端。很难确定应使用哪个源MAC地址。
此流程与SVI启动时不同：
- 客户端向不同VLAN(192.168.2.20)中的主机发送TCP SYN，其中目标MAC地址设置为上游交换机上定义的默认网关。该数据包到达重定向ACL，如调试所示。
- 交换机检验它是否有返回客户端的路由。请记住，SVI 10已关闭。
- 如果交换机没有另一个SVI，该SVI具有返回客户端的路由，则即使企业策略管理器(EPM)日志指示到达ACL，该数据包也不会被拦截或重定向。远程主机可能返回SYN ACK，但交换机没有返回客户端(VLAN10)的路由并丢弃数据包。由于数据包到达重定向ACL，因此不能仅交换回(L2)。
- 如果交换机确实通过不同的SVI拥有到客户端VLAN的路由，它会拦截该数据包，然后照常执行重定向。使用URL重定向的响应不会直接发送到客户端，而是会根据路由决定通过不同的交换机/路由器。
注意这里的不对称性：
- 从客户端接收的流量被交换机本地拦截。
- 根据路由，通过上游交换机发送该响应（包括HTTP重定向）。
- 这时可能会发生典型的防火墙问题，并且需要TCP旁路。
- 流向ISE的流量（未重定向）是对称的。只有重定向本身是非对称的。
场景6 — 目标主机处于不同的VLAN中，不存在，并且SVI 10已关闭
此场景与场景5完全相同。远程主机是否存在并不重要。重要的是正确的路由。
场景7 - HTTP服务已关闭
如场景6所示，交换机上的HTTP进程发挥着重要作用。如果禁用HTTP服务，EPM会显示数据包到达重定向ACL:
epm-redirect:IP=192.168.1.201: Ingress packet on [idb= GigabitEthernet1/0/2] matched
with [acl=REDIRECT_POSTURE]
但是，重定向不会发生。
HTTP重定向不需要交换机上的HTTPS服务，但HTTPS重定向需要该服务。NAC代理可以使用两者进行ISE发现。因此，建议同时启用两者。
重定向ACL — 协议和端口不正确，无重定向
请注意，交换机只能拦截在标准端口（TCP/80和TCP/443）上运行的HTTP或HTTPS流量。 如果HTTP/HTTPS在非标准端口上运行，可以使用ip port-map http命令对其进行配置。此外，交换机的HTTP服务器必须在该端口(ip http port)上侦听。
相关信息
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
1.0 |
13-Feb-2014
|
初始版本 |
反馈