强叔侃墙 VPN篇 L2TP NAS-Initiated VPN

上一篇贴子中我们讲过，Client-Initiated VPN可以让企业出差员工像都教授一样穿越“虫洞”，来去自如地访问总部网络。而企业分支机构用户就没有这么幸运，他们一般通过拨号网络接入Internet，面对浩瀚的Internet海洋，没有能力找到“虫洞”的入口，只能望洋兴叹。即使拨号网络演进到以太网，也只是解决了本地接入Internet的问题，无法访问总部网络。难道分支机构用户注定与总部网络无缘了吗？

幸好LAC横空出世，帮助分支机构解决了这一难题。一方面，LAC作为PPPoE Server，分支机构用户作为PPPoE Client与LAC建立PPPoE连接，让PPP欢快地跑在以太网上；另一方面，LAC作为LNS的“中介”，为分支机构提供“虫洞”的入口，在分支机构用户看来，通过LAC这扇传送门就可以到达总部网络。

因为在VPDN里LAC还有一个别名叫做NAS，所以这种L2TP VPN也称为NAS-Initiated VPN。可能把NAS-Initiated VPN改为LAC-Initiated VPN大家更习惯一些，因为组网图中明明标的是LAC，却非得叫一个已经搁置不用的“曾用名”，这对于后来者而言确实有点不明所以。

NAS-Initiated VPN的建立过程有点小复杂，为了便于记忆强叔给大家画了一张简图，方便后续对着这张图一一道来。

 

为了复习一下PPPoE的相关知识，我们用一台防火墙作为PPPoE Client，模拟PC的PPPoE Client：

 

阶段1 拨号口对VT口的呼唤：建立PPPoE连接

PPP屈尊落户以太网变为PPPoE后，为了在以太网上模拟PPP的拨号过程，PPPoE发明了两个虚拟接口——Dialer接口和VT接口。Dialer接口用于PPPoE Client侧，VT接口用于PPPoE Server（即LAC）侧，在这两个接口上配置PPPoE相关参数。

 

PPPoE Client

PPPoE Server（LAC）

interface dialer 1

dialer user user1

dialer-group 1

dialer bundle 1

ip address ppp-negotiate       //协商模式下实现IP地址动态分配

ppp chap user user1  //PPPoE Client的用户名

ppp chap password cipher Password1   //PPPoE Client的密码

dialer-rule 1 ip permit

interface GigabitEthernet0/0/1

pppoe-client dial-bundle-number 1   //在物理接口上启用PPPoE Client并绑定dial-bundle

interface Virtual-Template 1

ppp authentication-mode chap

interface GigabitEthernet 0/0/1

pppoe-server bind virtual-template 1        //在物理接口上启用PPPoE Server并绑定VT接口

aaa

local-user user1 password Password1

 local-user user1 service-type ppp

注：在L2TP中，用户的IP地址都是由总部（LNS或AAA服务器）统一进行分配的，所以LAC上不需要配置地址池（即使配置了地址池，在L2TP隧道已经建立的情况下，也会优先使用总部的地址池进行地址分配），而普通的PPPoE拨号则必须在PPPoE Server上配置地址池。

 

通过抓包来分析PPPoE连接的建立过程：

 

这里重点介绍PPPoE发现阶段的协商过程，PPPoE Client和PPPoE Server之间通过交互PADI、PADO、PADR和PADS报文，确定对方以太网地址和PPPoE会话ID： 

步骤1

PPPoE Client：广播广播，我想接入PPPoE，谁来帮帮我？

步骤2

PPPoE Server：PPPoE Client，找我呀，我可以帮助你！

步骤3

PPPoE Client：太好了，PPPoE Server，我想跟你建立PPPoE会话。

步骤4

PPPoE Server：没问题，我把会话ID发给你，我们就用这个ID建立PPPoE会话吧。

 

阶段2 建立L2TP隧道：3条消息协商进入虫洞时机

LAC和LNS通过交互三条消息协商L2TP隧道，这个过程我们在“Client-Initiated VPN”一篇中已经介绍过了，这里再复习一遍。首先来看一下LAC和LNS的具体配置：

LAC

LNS

l2tp-group 1

 tunnel authentication   //避免假冒LAC接入LNS

tunnel password cipher Password1

 tunnel name lac

 start l2tp ip 1.1.1.2 fullusername user1      //指定隧道对端地址

l2tp enable

interface Virtual-Template 1

 ppp authentication-mode chap

 ip address 172.16.0.1 255.255.255.0

 remote address pool

l2tp-group 1

 tunnel authentication   //避免假冒LAC接入LNS

 tunnel password cipher Password1

 tunnel name lns

allow l2tp virtual-template 1 remote lac     //允许远端接入

l2tp enable

aaa

 local-user user1 password Password1

 local-user user1 service-type ppp

 ip pool 0 172.16.0.2

 

抓包信息如下：

 

隧道ID协商过程：

步骤1

LAC：LNS，使用1作为Tunnel ID跟我通信吧。

步骤2

LNS：OK。LAC，你也用1作为Tunnel ID跟我通信。

步骤3

LAC：OK。

-

 

阶段3 建立L2TP会话：3条消息唤醒虫洞门神

LAC和LNS通过交互三条消息协商Session ID，建立L2TP会话。同样，我们再复习一遍这个过程。

 

Session ID协商过程：

步骤1

LAC：LNS，使用4作为Session ID跟我通信吧。

步骤2

LNS：OK。LAC，你也使用4作为Session ID跟我通信吧。

步骤3

LAC：OK。

-

 

阶段4-5  LNS冷静接受LAC：LNS认证，分配IP地址

1、LNS认证&二次认证（可选）

LAC将用户信息发给LNS进行验证，但LNS清醒认识到LAC“中介”的本来面目，对此LNS有三种态度：

lLAC代理认证：相信LAC是可靠的，直接对LAC发来的用户信息进行验证。

l强制CHAP认证：不相信LAC，要求重新对用户进行“资格审查”（强制重新对用户进行CHAP验证）。

lLCP重协商：不仅不相信LAC，还对前面签订的业务合同不满，要求跟用户重新“洽谈业务”（重新发起LCP协商，协商MRU参数和认证方式）。

后两种方式统称为LNS二次认证，若LNS配置二次认证而PPPoE Client不支持二次认证，将会导致L2TP VPN无法建立。两种二次认证的共同特征是LNS都绕过了LAC直接验证PPPoE Client提供的用户信息，可以为VPN业务提供了更高的安全保障。  

LAC代理认证*

缺省，不用配置

LNS直接对LAC发来的用户信息进行验证，验证通过即成功建立PPP连接。

强制CHAP认证**

l2tp-group 1

 mandatory-chap

LNS重新对用户进行CHAP验证，LNS发送挑战，PPPoE Client使用挑战将用户名和加密后的密码发给LNS，LNS验证通过成功建立PPP连接。

LCP重协商***

interface virtual-template 1

ppp authentication-mode chap   //重协商后的验证方式在VT下指定

l2tp-group 1

 mandatory-lcp

LNS重新发起LCP协商，协商MRU参数和认证方式，然后进行CHAP验证，验证通过即成功建立PPP连接。

*代表优先级，三种方式同时配置时LCP重协商优先级最高。

 

2、分配IP地址

通过PPP IPCP协商，LNS为PPPoE Client分配IP地址。

关于地址池地址的规划问题，我们在“Client-Initiated VPN”一篇中也讲过。同样，建议把地址池地址和总部网络地址规划为不同的网段。如果地址池地址和总部网络地址配置为同一网段，则必须在LNS连接总部网络的接口上开启ARP代理功能，并且开启L2TP虚拟转发功能，保证LNS可以对总部网络服务器发出的ARP请求进行应答。

假设LNS连接总部网络的接口是GigabitEthernet0/0/1，开启ARP代理功能和L2TP虚拟转发功能的配置如下：

interface GigabitEthernet0/0/1

 ip address 192.168.0.1 255.255.255.0 

 arp-proxy enable             //ARP代理功能

 virtual-l2tpforward enable         //开启L2TP虚拟转发功能

总结一下NAS-Initiated VPN的特点：

NAS-Initiated VPN场景中，一对LAC和LNS的连接可存在多条隧道；一条隧道中可承载多条会话。接入用户1与LNS之间建立PPP连接1和L2TP会话1，接入用户2与LNS之间建立PPP连接2和L2TP会话2。

 

当其中一个用户拨号后，触发LAC和LNS之间建立隧道。只要此用户尚未下线，则其余用户拨号时，会在已有隧道基础上建立会话，而并非重新触发建立隧道。

阶段6 一路畅通：数据封装传输

PPPoE Client访问总部服务器的报文到达LAC后，LAC为报文穿上三层“马甲”，即L2TP头、UDP头和公网IP头，然后发送到LNS。LNS收到报文后，脱去这三层“马甲”，将报文转发至服务器。

 

报文封装和解封装的过程如下图所示：

 

借助于LAC的力量，分支机构员工使用PPPoE Client就可以畅通无阻访问总部网络。但是从总部服务器到PPPoE Client的回程报文是如何进入隧道返回的呢？还记得我们在“Client-Initiated VPN”一篇中介绍过的UNR路由吧，NAS-Initiated VPN也是这样处理的。LNS会为获得IP地址的PPPoE Client自动下发了一条UNR路由，下一跳为PPPoE Client本身的地址，出接口是InLoopBack0，这条路由将指引回程报文进入隧道。回程报文进入隧道后被封装上公网IP地址，然后LNS将会以该公网IP地址为目的地址再次查找路由，将封装后的回程报文送往LAC。

NAS-Initiated VPN场景中，分支机构用户必须拨号才能使用L2TP VPN，报文还要封装成PPPoE，太麻烦了。况且拨号网络逐渐消失，以太网一统江湖，分支机构用户就不能直接在以太网上访问总部网络吗？当然可以，人类偷懒的需求才是科技进步的原动力。下期强叔就为大家介绍LAC-Auto-Initiated VPN，由LAC自动拨号到LNS，省去了分支机构员工拨号的过程，堪称最省事的L2TP VPN，敬请期待。