1、协商的报文整体观察
从整体上出发,L2TP的协商被我的红框分为上面几个步骤,首先是客户端向服务端发送RQ隧道协商请求,然后服务端回复,最后客户端再确认,这个阶段完成后会协商出一个隧道ID。然后就是会话协商,也是三次数据包的交互,最后协商出一个会话ID。然后就是PPP协议中的LCP协商,到CHAP的认证,到最后的IPCP网络层地址协商。
2、L2TP的协商
SCCRQ报文:
其实和大部分的协商请求报文类似,无非是协商一些版本一些控制参数,Host Name就是客户端的标识符,这样虽然LNS上可能配置了多个l2tp隧道,这样就可以知道使用什么配置用于回应,Assigned Tunnel ID就是用于双方的隧道ID的协商的一个字段,Challenge这个主要就是用于隧道验证,它将我们的隧道密码和Hash函数结合在一起,比较简单的一种验证方式就i是将密码与盐做hash计算,然后交给服务端,服务端如果计算出来的hash值是相同的,那么就验证通过。其他就是一些用于拨号网络什么的控制参数,无伤大雅。
SCCRP报文:
可以看到在SCCRP报文中还多了一个Challenge Response的字段,它和Challenge字段共同用于隧道的身份验证。
SCCCN报文:
这是隧道ID协商的最后一个报文,主要起确认作用,里面的信息不是很多。
ICRQ报文:
会话ID协商请求报文
ICRP报文:
会话ID协商响应报文
ICCN报文:
可以看见在确认包中确认了相关的隧道ID和会话ID
所以总共经过六个包的协商协商了一些L2TP上的控制参数,隧道认证以及隧道ID和会话ID的确认。后续的传输报文就使用这些确定的控制参数,隧道ID以及会话ID进行数据传输。