2.4 案例研究
VPN故障诊断与排除
本节介绍的问题和解决方案没有前一节介绍的那么常见。
2.4.1 案例研究1：远程AAA
本案例研究讨论涉及远程AAA的配置可能出现的一些问题。
介绍所有的远程AAA问题时，都将使用图2.38所示的网络拓扑，其中有一个NAS（LODI_NAS1）和一台终点网关（PERRIS_HGW1），远程接入客户拨号到LODI_NAS1。
1．问题1：在AAA服务器上错误地配置了L2F隧道定义
将隧道定义和配置存储在AAA服务器上是一种管理L2F VPDN的方便方式。然而，如果隧道定义配置得不正确，隧道建立将失败。
隧道定义可使用Cisco AV对或标准IETF属性进行配置。在这个案例研究中，使用的是Cisco AV对。
排除这种故障时，首先要确定正确地从AAA服务器下载了隧道定义。为此，命令debug aaa authorization很有帮助，如程序清单2-98所示。
在加黑的第1和第2行，串行接口0/0:0连接到1111，异步接口38的状态变为up。远程接入客户连接到了NAS。
在加黑的第3行，创建了用户mjlnet.com。这是远程接入客户的验证响应提供的域名。
注意，在AAA服务器上，隧道定义是以对应于客户的域名的用户名的名义存储的。
接下来开始给用户mjlnet.com授权，如程序清单2-99所示。
加黑的第1行，LODI_NAS1请求网络服务授权。网络服务包括PPP，具体地说，请求有关PPP服务（加黑的第2行）和VPDN协议（加黑的第3行）的授权。
加黑的第4行表明，将使用默认方法列表；加黑的第5行指出，将由RADIUS服务器进行授权。
在程序清单2-100中，成功地进行了授权。
程序清单2-100中加黑的第1行表明授权成功（PASS_REPL）。从RADIUS服务器下载了一系列的属性-值（AV）对，如加黑的第2～4行所示。
看起来一切顺利，然而在加黑的第5行，串行接口0/0:0与1111断开；另外，在加黑的第6行，异步接口38的状态变为down。远程接入客户被断开。
为更清晰地说明这一点，可执行命令debug radius，如程序清单2-101所示。
在加黑的第1行，串行接口0/0:0连接到1111；在加黑的第2行，异步接口33的状态变为up。远程接入客户连接到了NAS。
在加黑的第3行，一条接入请求消息被发送给RADIUS服务器。该消息中包含一系列的属性，它们列在加黑的第3行后面。
在加黑的第4行，RADIUS服务器用一条接入接受消息进行应答，这表明验证获得了成功。同样，接入接受消息中也包含一系列的属性，如加黑的第5～7行所示。
下载而来的属性构成了隧道定义。
在加黑的第8和9行，串行接口0/0:0与1111断开，异步接口33的状态变为down，这表明客户已被断开。
NAS从RADIUS服务器下载隧道定义，然后立刻断开客户。这可能表明隧道定义本身有问题。因此，需要查看RADIUS服务器（这里为一台Cisco安全接入控制服务器[Cisco安全ACS]）上的隧道定义。
图2.39显示了RADIUS服务器中的隧道定义。
如果仔细查看隧道定义，将发现遗漏了一个重要的属性：终点网关的IP地址。
要定义终点网关的IP地址，可使用Cisco AV对（009/001）vpdn:ip-address = ip_address。将该属性加入到RADIUS服务器中的隧道定义。
注意，图2.39中的隧道定义没有包含Cisco AV对vpdn:tunnel-type = tunnel_protocol。这没有问题，因为在Cisco路由器上默认的隧道协议为L2F。
图2.40显示了重新配置后的隧道定义。
重新配置隧道定义后，当客户重新连接时，将成功地建立隧道。
这可以使用命令show vpdn tunnel all来核实，如程序清单2-102所示。
加黑的第1行表明，已经建立了一条隧道和一个会话；加黑的第2～4行显示了终点网关的名称（PERRIS_HGW1）、CLID（5）和IP地址（172.16.2.2）。
接下来使用命令show vpdn session来查看客户会话，如程序清单2-103所示。
从加黑的第1行可知，为客户joebloggs@mjlnet.com建立了一个会话。问题解决了。
排除隧道定义故障时，还有几个其他的问题需要注意。确保与RADIUS服务器中的隧道定义相关联的用户（域名）的密码被配置为cisco。在Cisco路由器上，以硬编码的方式为隧道定义指定了该密码。另外，确保服务类型（属性6）被配置为outbound或dialout framed。在Cisco 安全ACS上，这些属性可在Group setup中找到。最后，如果使用的是Cisco安全ACS，全部在User setup或Group setup中配置了No IP Assigment（属性8）。
注意，如果在命令debug radius的输出中看到消息No response from server，这表明服务器不可达。因此，应排除连接性故障。
注意：
有关IETF属性的更详细信息，请参阅RFC 2868以及下面的URL：
http://www.cisco.com/en/US/products/iosswrel/ps1830/products_feature_guide
09186a00800879eb.html。
有关RADIUS属性的更详细信息，请参阅下面的URL：
http://www.cisco.com/univercd/td/doc/product/software/ios121/121cgcr/secur_c/
scprt6/scdradat.htm。
可以将命令debug radius的输出粘贴到Cisco网站中的输出解释器（http://www.cisco.com/cig-bin/Support/OutputInterpreter/home.pl）中，获得其简要解释。要使用输出解释器，必须登录。
从Cisco IOS软件版本12.2(4)T起，在debug radius命令的输出中对属性进行了解码。
结束本案例研究之前，有必要看一下Merit格式的L2F隧道定义（使用Cisco AV对配置的）。
程序清单2-104列出了一个在Merit RADIUS服务器上配置正确的L2F隧道定义。
上述隧道定义的含义非常明确。第1行指定了域名（mjlnet.com），这是连接到NAS的远程接入客户提供的域名。这里还指定了Cisco路由器的硬编码密码（cisco）。第2行列出了服务类型（Outbound-User）。
隧道定义中其他的内容包括隧道ID（LODI_NAS1）、终点网关的IP地址（172.16.2.2）和隧道密码（这里都是cisco）。
2．问题2：远程接入客户未能通过远程AAA（RADIUS）验证
为支持大量的远程接入客户，一种可扩展性更好的解决方案是，将远程接入客户的用户名和密码存储在AAA服务器中。
在这种情况下，要排除客户验证故障，首先应使用命令debug aaa authentication。
程序清单2-105是命令debug aaa authentication的输出。
在加黑的第1行，虚拟接入接口1的状态变为up，客户通过L2F隧道连接到了终点网关。在加黑的第2行，创建了用户joebloggs@mjlnet.com。
验证即将开始，如程序清单2-106所示。
在加黑的第1行，开始PPP服务的登录验证。加黑的第2和第3行表明，默认方法列表中的第一种验证方法为本地验证。
在加黑的第4行，本地验证导致错误。在加黑的第5行，开始使用RADIUS进行验证（默认方法列表中的第二种验证方法）。加黑的第6行表明，使用RADIUS进行验证时失败。
接下来虚拟接入接口1的状态变为down（加黑的第7行），客户被断开。
要获得更详细的信息，可使用命令debug radius。程序清单2-107是命令debug radius的输出。
在加黑的第1行，虚拟接入接口1的状态变为up，客户连接到了终点网关；在加黑的第2行，终点网关发送一条接入请求消息给RADIUS服务器，以便对客户进行验证。
在加黑的第3行，RADIUS服务器发送一条接入拒绝消息给终点网关，验证失败；在加黑的第4行，虚拟接入接口1的状态变为down，客户被断开。
验证失败表明，在客户工作站或RADIUS服务器上，客户的用户名或密码可能配置得不正确。客户确认其用户名和密码配置正确后，可以肯定RADIUS服务器配置不正确。RADIUS服务器上配置的用户名是正确的，这意味着密码肯定配置不正确。因此重新配置密码。
在User Setup对话框中重新配置客户密码，如图2.41所示。
重新配置密码后，客户重新连接时，将通过验证。这可以使用命令show caller user来证明，如程序清单2-108所示。
加黑的第1行表明，用户连接到了虚拟接入接口1。
从加黑的第2～4行可知，同远程接入客户成功地完成了LCP、CHAP和IPCP协商。没有同客户协商多链路PPP，因此它处于关闭（Closed）状态。问题解决了。
注意，如果在命令debug radius的输出中看到消息No response from server，这表明服务器不可达。因此，应排除连接性故障。
注意：
有关RADIUS属性的更详细信息，请参阅下面的URL：
http://www.cisco.com/univercd/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/
scdradat.htm。
可以将命令debug radius的输出粘贴到Cisco网站中的输出解释器（http://www.cisco.com/cig-bin/Support/OutputInterpreter/home.pl）中，获得其简要解释。
要使用输出解释器，必须登录。
另外，从Cisco IOS软件版本12.2(4)T起，在debug radius命令的输出中对属性进行了解码。
3．问题3：对远程接入客户的远程AAA（RADIUS）授权失败
在终点网关上使用远程AAA时，RADIUS服务器不但要对客户进行验证，还需对客户使用的服务进行授权。如果授权配置不正确，客户连接将被断开。
可使用命令debug aaa authorization来调试这种问题，程序清单2-109只列出了相关的调试输出部分。
加黑的第1行表明，终点网关请求网络（NET）服务授权。注意，网络服务包括PPP，具体地说，终点网关请求有关PPP服务和VPDN协议的授权（见加黑的第2和第3行）。加黑的第4和第5行表明，终点网关从默认方法列表中选择了RADIUS授权。在加黑的第6行，授权失败。最后，在加黑的第7行，虚拟接入接口1的状态变为down。下面使用命令debug radius来获得更详细的信息。
程序清单2-111是命令debug radius的输出。
在加黑的第1行，虚拟接入接口1的状态变为up，客户已连接到终点网关。加黑的第2行表明，终点网关给RADIUS服务器发送了一条接入请求消息。在加黑的第3行，终点网关从RADIUS服务器那里收到了一条接入拒绝消息。加黑的第4行表明，终点网关没有收到针对客户的合适授权。最后，虚拟接入接口1的状态变为down，客户被断开。进行了授权，但类型不正确。
下面在RADIUS服务器上查看客户的用户设置和组设置。
图2.42是RADIUS服务器上客户的组设置。
正如读者看到的，在IETF RADIUS Attributes配置中，服务类型（Service-Type，属性6）被配置为登录（Login），分帧协议（Framed-Protocol，属性7）被配置为PPP。
分帧协议的配置是正确的，但服务类型配置错误。服务类型配置为Framed，而不是Login。
将服务类型重新配置为Framed，如图2.43所示。
重新配置服务类型后，客户重新连接时，授权将成功。这可以使用命令show caller user来核实。
程序清单2-112是命令show caller user的输出。
加黑的第1行表明，用户joebloggs@mjlnet.com已通过一条L2F隧道连接到终点网关。
从加黑的第2行可知，成功地同客户进行了LCP协商、PPP验证和IPCP协商。没有同客户进行多链路PPP（MP）协商，因此它处于关闭（Closed）状态。问题解决了。
注意，如果在命令debug radius的输出中看到消息No response from server，这表明服务器不可达。在这种情况下，应排除终点网关和RADIUS服务器之间的连接性故障。
注意：
有关RADIUS属性的更详细信息，请参阅下面的URL：
http://www.cisco.com/univercd/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/
scdradat.htm。
可以将命令debug radius的输出粘贴到Cisco网站中的输出解释器（http://www.cisco.com/cig-bin/Support/OutputInterpreter/home.pl）中，获得其简要解释。
要使用输出解释器，必须有CCO账户。
从Cisco IOS软件版本12.2(4)T起，在debug radius命令的输出中对属性进行了解码。
2.4.2 案例研究2：无法在负载分担服务器和终点网关之间建立L2F隧道
在多机架多链路PPP（MMP）环境中，除非使用多跳VPDN，否则将无法建立从负载分担服务器（offload server）到终点网关的隧道。
在MMP环境中使用栈组争控协议（Stack Group Bidding Protocol，SGBP）组时，多链路PPP连接和可能的常规PPP连接（如果使用命令sgbp ppp-forward）将通过L2F隧道（在较新的Cisco IOS软件版本中，为L2TP隧道）被连接到争控胜者（负载分担服务器）。
注意，可使用命令sgbp protocol {any | l2f | l2tp}来更改使用的协议。如果将经由这些MMP L2F隧道到达的PPP数据流，再通过隧道转发给终点网关，实际上是将来自SGBP成员的入站隧道与前往终点网关的出站隧道连接起来。要完成这种隧道互连，必须仔细进行配置。
在下面的案例中，两个前端NAS（LODI_NAS1和LODI_NAS2）被配置成将PPP数据流转发给一台负载分担服务器（LODI_OFFLOAD），而LODI_OFFLOAD被配置成通过隧道将PPP连接延伸到终点网关PERRIS_HGW1，如图2.44所示。
然而，虽然通过隧道将PPP数据流成功地从LODI_NAS1和LODI_NAS2转发到了负载分担服务器LODI_OFFLOAD，但从LODI_OFFLOAD到终点服务器的L2F隧道没有正确运行。
通过在LODI_OFFLOAD上执行命令show user可知，通过隧道建立了两个来自前端NAS（LODI_NAS1和LODI_NAS2）的MP会话，如程序清单2-113所示。
从程序清单2-115中加黑的第1行可知，总共有两条L2F隧道和两个活动的会话。从加黑的第2行可知，一条隧道从172.16.1.3（LODI_NAS2）到172.16.1.4（LODI_OFFLOAD）；从加黑的第3行可知，另一条隧道从172.16.1.1（LODI_NAS1）到172.16.1.4（LODI_OFFLOAD）。
这两条隧道的终点网关和NAS的名称都为LODI_STACK。这是因为LODI_NAS1、LODI_NAS2和LODI_OFFLOAD都被分配到SBGP组LODI_STACK组中，它们彼此进行验证。
然而，从程序清单2-113中的输出可以看出一个明显的问题：没有预期的从LODI_OFFLOAD到终点网关PERRIS_HGW1的隧道。
首先，采用常规的L2F故障排除方法。在这里，呼叫接收没有问题，因为PPP帧被成功地通过隧道从LODI_NAS1和LODI_NAS2转发到LODI_OFFLOAD，从前面的show命令的输出可以知道这一点。
接下来需要排除从LODI_OFFLOAD到PERRIS_HGW1的隧道建立故障。就这条隧道而言，LODI_OFFLOAD为L2F NAS设备，而PERRIS_HGW1为L2F终点网关。
由于已确定呼叫接收是成功的，因此接下来需要做的是，检查NAS（LODI_OFFLOAD）和终点网关（PERRIS_HGW1）之间是否有基本的IP连接性，为此可使用命令ping，如程序清单2-116所示。
在加黑的第1行，收到了一条来自LODI_STACK的L2F_CONF消息。现在，还不清楚该L2F_CONF消息是SGBP组LODI_STACK的哪个成员发送的。
在加黑的第2行，LODI_OFFLOAD打开一个到172.16.1.1（LODI_NAS1）的UDP套接字；在加黑的第3行，向LODI_NAS1发送一条L2F_CONF消息。这表明在加黑的第1行中的L2F_CONF来自LODI_NAS1。
在加黑的第4行，收到一条来自LODI_NAS1的L2F_OPEN消息。LODI_OFFLOAD用一条L2F_OPEN消息进行应答，L2F隧道建立过程完成。
接下来开始建立L2F客户会话，如程序清单2-118所示。
在加黑的第1行，收到一条来自LODI_NAS1的L2F_OPEN消息，这发起了L2F会话建立。在加黑的第2行，LODI_OFFLOAD以一条L2F_OPEN消息应答。在加黑的第3和第4行，虚拟接入接口3和2的线路协议状态变为up。
LODI_OFFLOAD用虚拟接入接口3端接从LODI_NAS1出发的MP链路。虚拟接入接口4用于捆绑MP链路（包括从LODI_NAS1出发的那条）。
接下来开始建立从LODI_NAS2出发的L2F隧道，如程序清单2-119所示。
在加黑的第1和第2行，LODI_NAS2和LODI_OFFLOAD交换L2F_OPEN消息，L2F会话建立完毕。最后，虚拟接入接口1上的线路协议状态变为up。该接口端接从LODI_NAS2出发的MP链路。
在LODI_NAS1、LODI_NAS2和LODI_OFFLOAD之间，能够正确地建立L2F隧道和会话。不幸的是，没有证据表明建立了从LODI_OFFLOAD到终点网关（PERRIS_HGW1）的L2F隧道。这意味着LODI_OFFLOAD可能存在配置错误。程序清单2-121列出了LODI_OFF-LOAD的配置中相关的部分。
咋一看，配置好像没有问题。然而，其中遗漏了一个重要命令。该命令让LODI_OFFLO-AD能够将通过从LODI_NAS1和LODI_NAS2出发的两条入站隧道传来的分组，转发到前往PERRIS_HGW1的隧道中。这个命令为vpdn multihop。
原来的两条隧道都恢复了，同时新增了一条从LODI_OFFLOAD到PERRIS_HGW1（172.16.5.1）的隧道。
最后一步是核实MP会话正确地终止于PERRIS_HGW1。为此，可使用命令show ppp multilink，如程序清单2-125所示。
从中可知，有两个通过隧道从LODI_OFFLOAD（172.16.2.1）延伸而来的MP会话，它们分别终止于虚拟接入接口1和2（见加黑的第2和第3行）。
在虚拟接入接口3上，这两个会话被捆绑在一起（见加黑的第1行）。问题解决了。
注意：
有关配置MMP的更详细信息，请参阅Cisco网站（www.cisco.com）中的文章“Multichassis Multilink PPP (MMP)”。
有关VPDN多跳特性的更详细信息，请参阅下面的URL：
http://www.cisco.com/univercd/cc/td/product/software/ios113ed/113t/113t_3/multih2.htm。