从零开始写个vpn系统

Published at 2024-08-08 | Last Update 2024-08-08

发展历史
概念区分
ISAKMP框架
IKE密钥交换协议
IPSEC 协议簇详解
- 两大协议（AH+ESP)
  - AH协议认证协议
  - ESP封装协议
- 两种模式
认证协议：
PPP协议：
L2TP协议：
开源实现
- SoftEtherVPN
- 自己实现一个vpn

发展历史

ipv4地址池枯竭。
CIDR(地址划分)1993年引入的，其推出是为了解决IPv4地址空间枯竭和路由表的爆炸性增长问题。在CIDR引入之前，IPv4地址空间的分配和路由表的管理主要依赖于传统的基于类别的划分方式。
1996 IANA 发布10.0.0.0/8,172.16.0.0/12，192.168.0.0/16设置为保留地址，nat技术发展。
出现内网划分，出现了区域接入内网的需求，随着pc发展，出现了个人终端接入内网需求
为应对区域接入内网的需求，出现了gre 隧道连接两个子网
为了应对个人终端接入内网需求，微软牵头发布了pptp协议（mac不支持）。pptp使用tcp完成控制信道。使用gre封装ppp协议完成数据通道。gre实现互联网的隧道。ppp协议提供认证，压缩等特性。
网络巨头思科也发布了l2f vpn标准，为统一市场标准，IETF将微软和思科两家拉在一起发布了l2tp.前面提到GRE主要是针对Site-to-Site网络组网场景，而PPTP则主要针对Point-to-Site终端远程接入场景，更是有着windows操作系统的加持，从而在桌面接入上无往不利。那么L2TP则是两者场景优势的结合，既支持Site-to-Site,也支持Point-to-Site。而L2TP则完全摒弃了GRE协议，而是将控制通道和数据通道，全部合并在UDP的1701端口，以虚拟通道的方式实现指令控制和数据传输。
前面提到了GRE、PPTP、L2TP三种主要协议，但是他们三者都有个共性，就是自身都没有加密能力，甚至连认证能力都较为有限。而随着internet使用越来越广泛，恶意攻击者、安全威胁也在增多，如何保证安全性成为一个越来越重要的命题。
IPSec(Internet Protocol Security) 应运而出，IPSec是一种网络协议安全套件，IPSEC 分为密钥协商和数据传输两个阶段。主要两用于对数据包进行身份验证和加密，以通过互联网协议网络在两台计算机之间提供安全的加密通信。
IPSEC 分为密钥协商和数据传输两个阶段 .于是，IKE(Internet Key Exchange) 应运而出。IKE共有两个版本，最初是IKEv1版本(RFC 2409开始) ，但是IKEv1版本有一些没有设计完善的地方，包括：1)、协商速度慢影响体验：主动模式协商需要9条消息，野蛮模式需要6条消息。2)、不支持Point-to-Site终端远程接入，必须依赖于L2TP绑定实现。
所以，为了安全起见，而此时ipsec不支持Point to Point，L2TP 需要ipsec的加持,ipsec也需要L2TP加持，所以出现了L2TP Over IPSec：通过IPSec为L2TP增强加密能力，windows操作系统就内置支持此模式。后来主流的l2tp都在ipsec的基础上运行，所以常见l2tp/ipsec，就是使用的ipsec 的 ikev1 密钥交换版本。
为了应对IKEv1的设计缺陷，IKEv2版本应运而生，IKEv2 版本(RFC 4306开始)，IKEv2特征如下: 1)、协商速度(较IKEv1)快：首次协商需要4条消息；后续协商仅需2条消息。 2)、支持Point-to-Site终端远程接入：通过增加EAP（Extensible Authentication Protocol）方式的身份认证，摆脱了对L2TP的依赖。 IPSEC使用IKEv2 和L2TP类似，既支持Site-to-Site网络组网场景，也支持Point-to-Site远程接入场景。同时，由于IPSEC本身是IP协议的扩展安全套件，所以，IPSEC还支持为IP层协议提供保护。
ipsec在IKEv2 版本中不在需要l2tp，而且ipsec自带身份认证和加密，同时连接速度还更快。IKEv2 成为主流。

概念区分

密钥

在加密通信中，密钥是用来加密和解密数据的秘密信息。密钥可以是对称的（相同的密钥用于加密和解密）或非对称的（使用公钥加密和私钥解密）。密钥的安全性和管理对于数据保护至关重要。

加密

加密是将明文数据（可读的内容）转换为密文（不可读的内容）的过程，以保护数据的机密性。加密使用密钥和算法来确保只有授权的用户能够解密和读取数据。

认证

用来确认身份。认证是验证用户或系统身份的过程，确保通信的双方确实是他们声称的身份。在网络安全中，认证通常包括用户名和密码、数字证书或其他验证机制，以防止未授权访问。

隧道协议

隧道协议用于创建一个虚拟的、安全的数据通道，通过公共网络传输数据包。它将数据包封装在另一个协议内，从而隐藏数据的真实内容和源目的地。常见的隧道协议包括GRE（Generic Routing Encapsulation）和IPsec，L2tp。

密钥交换协议

密钥交换协议是用于在通信双方之间安全地交换密钥的协议。它确保密钥在传输过程中不被窃取或篡改。常见的密钥交换协议包括Diffie-Hellman和Elliptic Curve Diffie-Hellman（ECDH）。

加密算法

加密算法是用于加密和解密数据的数学公式或方法。它定义了如何将明文数据转换为密文以及如何将密文转换回明文。加密算法可以是对称的（如AES、DES）或非对称的（如RSA、ECC）。

哈希算法

哈希算法是一种将输入数据（无论大小）转换成固定长度的散列值（哈希值）的算法。这种散列值通常用作数据的唯一标识符。哈希算法具有以下特点：输入数据的微小变化会导致哈希值的大幅改变；哈希值在理论上应是唯一的；且很难从哈希值反推出原始数据。常见的哈希算法包括MD5、SHA-1和SHA-256。哈希算法在数据完整性验证、数字签名和密码存储等方面具有重要作用。

ISAKMP框架

互联网安全关系钥匙管理协议（英语：Internet Security Association and Key Management Protocol，缩写为 ISAKM或 ISAKMP），互联网协议之一，用于在互联网上建立安全关系与加密密钥。这个协议在 RFC 2408 中定义，它提供了一个架构来进行授权与密钥交换，主要被设计来作为密钥交换之用。因特网密钥交换与Kerberized Internet Negotiation of Key等协议，提供了授权密钥的资料，可以在ISAKMP中使用。ISAKMP只提供了一个身份鉴权和钥匙交换的框架，其被设计为不受约束的钥匙交换。如IKE（因特网钥匙交换协议）和KINK（Kerberized 因特网钥匙协议）等协议都使用了ISAKMP所提供的授权钥匙的方案。例如：因特网钥匙交换协议(IKE)使用了Oakley和SKEME协议的一部分,通过ISAKMP连接获取授权了的钥匙信息。其同样对于其他的安全关联，如AH和ESP。

IKE密钥交换协议

IKE基础

IKE是一个复合协议。

因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）**500 **端口号，的应用层协议。

IKE协商两种SA：
- IKE(ISAKMP) SA (阶段一）
- IPSEC SA（阶段二）
IKE负责建立和维护IKE SAs 和 IPSec SAs。功能主要体现在如下几个方面：
- 对双方进行认证
- 交换公共密钥，产生密钥资源，管理密钥
- 协商协议参数（封装、加密、验证…..）
IKE的三个组件：
- SKEME：实现公钥加密认证的机制
- Oakley：基于到达两个对等体间的加密密钥的机制
- ISAKMP：在两个实体间进行分组格式及状态转换的消息交换的体系结构。
IKE有两个版本:
- IKEV1
- IKEV2——-华为默认
IKE与IPSec的关系：

IKE与IPSec的关系如上图所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。

IKE的安全机制

IKE具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA：

身份认证

身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证。

在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。

DH 密钥交换算法

DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。

MD5、SHA1、DES、3DES、AES等算法都可以采用DH算法来共享对称密钥。

DH使用密钥组定义自己产生的密钥长度。密钥组长度越长，产生的密钥就越强壮。

IKE的精髓在于它永远不在不安全的网络上传送密钥，而是通过一些数据的交换，通信双方最终计算出共享的密钥，并且即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。其中的核心技术就是DH（Diffie Hellman）交换技术。

PFS

短暂的一次性密钥系统称为“完善的前向保密“PFS（Perfect Forward Secrecy）
如果加密系统中有个密钥是所有对称密钥的衍生者（始祖），便不能认为那是一个“完美向前保密”的系统。在这种情况下、一旦破解了跟密钥，便能拿到其他衍生的所有密钥，收那些密钥保护的全部数据都会曝光。
在IPsec 里，PFS是通过在IPSec SA协商阶段重新进行一个DH交换来实现的。
完善的前向安全性PFS（Perfect Forward Secrecy）是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。IPSec SA的密钥是从IKE SA的密钥导出的，由于一个IKE SA协商生成一对或多对IPSec SA，当IKE的密钥被窃取后，攻击者将可能收集到足够的信息来导出IPSec SA的密钥，PFS通过执行一次额外的DH交换，保证IPSec SA密钥的安全。

IKE的两个阶段：

采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。

IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。

经典版本的IKEv1有两个阶段：

阶段一： IKE SA

主模式（6个包）：

包含了三次双向交换，用到了六条ISAKMP信息。协商过程如下图所示：

IKEv1协商

这三次交换分别是：

消息①和②用于策略交换

发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
消息③和④用于密钥信息交换

双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。

nonce是个随机数，用于保证IKE SA存活和抗重放攻击。

主模式9个包

野蛮模式（3个包）

主模式与野蛮模式的区别：

交换的消息：主模式为6个包，野蛮模式为3个包，野蛮模式能够更快创建IKE SA
NAT支持：对预共享密钥认证：主模式不支持NAT转换，而野蛮模式支持。而对于证书方式认证：两种模式都能支持
对等体标识：主模式只能采用IP地址方式标识对等体；而野蛮模式可以采用IP地址方式或者Name方式标识对等体。这是由于主模式在交换完3、4消息以后，需要使用预共享密钥来计算SKEYID，当一个设备有多个对等体时，必须查找到该对等体对应的预共享密钥，但是由于其对等体的ID信息在消息5、6中才会发送，此时主模式的设备只能使用消息3、4中的IP报文源地址来找到与其对应的预共享密钥；如果主模式采用Name方式，Name信息却包含在消息5、6中，而设备必须在消息5、6之前找到其对等体的预共享密钥，所以就造成了矛盾，无法完成Name方式的标识。而在野蛮模式中，ID消息在消息1、2中就已经发送了，设备可以根据ID信息查找到对应的预共享密钥，从而计算SKEYID。但是由于野蛮模式交换的2个消息没有经过加密，所以ID信息也是明文的，也相应造成了安全隐患。
提议转换对数量：在野蛮模式中，由于第一个消息就需要交换DH消息，而DH消息本身就决定了采用哪个DH组，这样在提议转换对中就确定了使用哪个DH组，如果第一个消息中包含多个提议转换对，那么这多个转换对的DH组必须相同(和DH消息确定的DH组一致)，否则消息1中只能携带和确定DH组相同的提议转换对。
协商能力：由于野蛮模式交换次数的限制，因此野蛮模式协商能力低于主模式。
主模式常用，野蛮已经不推荐使用,推荐使用中主模式
两者之间的协商过程不同
场景不同：

野蛮模式的场景：

与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护，但它可以满足某些特定的网络环境需求：

当IPSec隧道中存在NAT设备时，需要启动NAT穿越功能，而NAT转化会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享密钥验证方式时，NAT穿越只能在野蛮模式中实现。
v 如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。
如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。

主模式场景：

要求两端都是固定IP地址

阶段二：IPSec SA

快速模式（3个包）

IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。

阶段二

IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：

协商发起方发送本端的安全参数和身份认证信息。

安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。

IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。

如果启用PSF，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
发送方发送确认信息，确认与响应方可以通信，协商结束。

IKEv2版本

IKEv1的主要问题

不支持远程用户接入
协商建立IPSec SA的时间太长

IKEv2的改进

IKEv1是一个混合型协议，其自身的复杂性不可避免地带来一些安全及性能上的缺陷，已经成为目前实现IPSec系统的瓶颈。
IKEv2协议保留了IKEv1的基本功能，并针对IKEv1研究过程中发现的问题进行修订，同时兼顾简洁性、高效性、安全性和见健壮性的需要，整合了IKEv1的相关文档，由RFC4306单个文档替代。通过核心功能最小化规定，新协议极大提高了不同IPSec VPN系统的互操作性。

IKEv2与IKEv1相比有以下优点

简化了安全联盟的协商过程，提高了协商效率。

IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。
修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
加入对EAP（Extensible Authentication Protocol）身份认证方式的支持，提高了认证方式的灵活性和可扩展性。

EAP是一种支持多种认证方法的认证协议，可扩展性是其最大的优点，即若想加入新的认证方式，可以像组件一样加入，而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。
通过EAP协议解决了远程接入用户的认证问题，彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。

安全联盟SA

定义： 安全联盟是要建立IPSec 隧道的通信双方对隧道参数的约定，包括隧道两端的IP地址、隧道采用的验证方式、验证算法、验证密钥、加密算法、共享密钥以及生命周期等一系列参数。

SA由三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。

SA是单向的逻辑连接，因此两个IPSec对等体之间的双向通信，最少需要建立两个SA来分别对两个方向的数据流进行安全保护。

SA是IPSec的一个基本组成部分，SA是SADB的一个条目，它包含双方关于IKE和IPSec已经协商完毕的安全信息。

IKE or ISAKMP SA：双向的，决定了IKE协议处理相关细节
IPSec SA：单向的，与封装协议相关，决定了具体加密流量的处理方式。

两种类型的SA都是由IKE协议协商产生的。

IPSEC 协议簇详解

两大协议（AH+ESP)

AH协议认证协议

AH是一种基于IP的传输层协议，协议号为51。
只能支持认证，不支持加密。
对整个头部进行认证。

其工作原理是在每一个数据包的标准IP报头后面添加一个AH报文头。如下所示：

AH包结构

ESP封装协议

ESP支持加密和认证。

ESP是一种基于IP的传输层协议，协议号为50。其工作原理是在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Tail和ESP Auth data）。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护。

esp包结构

两种模式

传输模式

在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。传输模式不改变报文头。

传输封装

传输模式下，AH协议的完整性验证范围为整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、传输层协议头、数据和ESP报尾，但不包括IP头，因此ESP协议无法保证IP头的安全。ESP的加密部分包括传输层协议头、数据和ESP报尾。

判断方法：

通信点地址和加密点地址相同
通信点地址可以被路由

隧道模式

在原IP头部之前插入ESP/AH头部，同时生成新的IP头部。

隧道封装

隧道模式下，AH协议的完整性验证范围为包括新增IP头在内的整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、原IP头、传输层协议头、数据和ESP报尾，但不包括新IP头，因此ESP协议无法保证新IP头的安全。ESP的加密部分包括原IP头、传输层协议头、数据和ESP报尾。

判断方法：

通信点地址和加密点地址不相同
通信点地址到internet能不能被路由，肯定是隧道

传输模式和隧道模式比较

传输模式和隧道模式的区别在于：

从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据报进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。
从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。

当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。

认证协议：

一般在链路层，用于网络接入的认证 PAP=>CHAP=>MS-CHAP=EAP(可扩展认证协议，RFC-3748定义，是一种普遍使用的支持多种认证方法的认证框架协议，主要用于网络接入认证， EAP协议一般运行在数据链路层上，与其说EAP是一个认证协议不如说EAP是一个认证框架，EAP本身不是认证协议，它自己不支持认证功能，它是为了承载多种认证协议而生的，EAP为扩展和协商认证协议提供了一个标准) https://lishiwen4.github.io/wifi/EAP-method

PAP（Password Authentication Protocol）*

PAP是一种简单的认证协议，使用明文密码进行用户身份验证。它通过将用户名和密码以明文形式发送到认证服务器进行验证，因此安全性较差，容易受到中间人攻击和密码嗅探。

CHAP（Challenge Handshake Authentication Protocol)

CHAP改进了PAP的安全性。它使用质询-响应机制来验证用户身份。在认证过程中，服务器发送一个随机质询（challenge）给客户端，客户端使用其密码和质询计算响应（response），然后将其发送回服务器。服务器使用相同的质询和密码计算响应值以进行验证。这种方法避免了密码的明文传输，提高了安全性，但仍可能面临某些攻击，如重放攻击。

MS-CHAP（Microsoft Challenge Handshake Authentication Protocol）

MS-CHAP是CHAP的一个扩展，由微软开发。它增强了CHAP的安全性，提供了两个版本：MS-CHAPv1和MS-CHAPv2。MS-CHAPv1引入了额外的加密机制和挑战响应过程，但仍存在一些安全漏洞。MS-CHAPv2进一步改进了加密机制，引入了对称密钥加密、握手验证以及相对较强的保护机制，但仍然存在一些已知的安全问题。

EAP（Extensible Authentication Protocol）

EAP是一种灵活的认证框架，不是一个具体的认证协议，而是支持多种认证机制的协议体系。EAP允许使用不同的认证方法，如证书、一次性密码、智能卡、以及基于密钥的认证等。EAP被广泛应用于无线网络（如Wi-Fi）和其他需要强认证的场景。EAP可以与其他协议（如RADIUS）结合使用，以提供更强的安全性和灵活性。

PPP协议：

背景

SLIP（Serial Line Internet Protocol，串行线路因特网协议）是一种在串行线路上承载网络层数据包的链路层协议，在RFC 1055中有详细描述。此协议应用简单，只在异步接口上支持。手动配置IP即可在串口上运行ip协议 https://www.h3c.com/cn/d_202204/1585783_30005_0.htm 因slip简单，所以有了PPP协议：https://www.h3c.com/cn/d_200805/605738_30003_0.htm

介绍

点到点协议（Point-to-Point Protocol，PPP）提供了一种在点到点链路上封装网络层协议信息的标准方法。PPP 最初设计是为两个对等节点之间的 IP 流量传输提供一种封装协议，在 TCP-IP 协议集中它是一种用来同步调制连接的数据链路层协议（OSI模式中的第二层），替代了原来非标准的第二层协议，即 SLIP。除了 IP 以外 PPP 还可以携带其它协议，包括 DECnet 和 Novell 的 Internet 网包交换（IPX）。　

![img](https://lj72808up.gitbooks.io/-tcp-ip/content/ppp2.png

PPP协议使用场合

用户到ISP的链路使用PPP协议。该协议可以验证用户身份并且自动分配IP地址

三个组成部分

PPP 协议有三个组成部分

一个将 IP 数据报封装到串行链路的方法。
链路控制协议 LCP (Link Control Protocol)。建立并维护数据链路连接。
网络控制协议 NCP (Network Control Protocol)。允许在点到点连接上使用多种网络层协议，如图所示：

PPP协议的工作状态

当用户拨号接入 ISP 时，路由器的调制解调器对拨号做出确认，并建立一条物理连接。
PC 机向路由器发送一系列的 LCP 分组（封装成多个 PPP 帧）。
这些分组及其响应选择一些 PPP 参数，和进行网络层配置，NCP 给新接入的 PC机分配一个临时的 IP 地址，使 PC 机成为因特网上的一个主机。
通信完毕时，NCP 释放网络层连接，收回原来分配出去的 IP 地址。接着，LCP 释放数据链路层连接。最后释放的是物理层的连接。

L2TP协议：

LAC和LNS

LAC

一般是分支机构的L2TP发起隧道的设备，也就是l2tp Client设备

LAC是附属在交换网络上的具有PPP端系统和L2TP协议处理能力的设备，主要用于为PPP类型的用户提供接入服务 LAC位于LNS和用户之间，用于在LNS和用户之间传递信息包，它把用户收到的信息包按照L2TP协议进行封装并送往LNS，同时也将从LNS收到的信息包进行解封装并送往用户。LAC与用户之间采用本地连接或PPP链路，VPDN应用中通常为PPP链路。

LNS

一般是总部的L2TP server设备

LNS既是PPP端系统，又是L2TP协议的服务器端，通常作为一个企业内部网的边缘设备。 LNS作为L2TP隧道的另一侧端点，是LAC的对端设备，是LAC进行隧道传输的PPP会话的逻辑终止端点。通过在公网中建立LAC隧道，将用户的PPP连接的另一端由原来的LAC在逻辑上延伸了企业网内部的LNS。

三种场景

用户PPPoE接入LAC（NAS-Initiated）

nas-inititated

用户无感，出口为LAC设备（）

LAC自动拨号

用户直接拨入LNS设备（Client-Initiated）

三种方式比较

隧道和会话建立原理：

隧道和会话：

在LNS和LAC对之间存在着两种类型的连接。

隧道（Tunnel）连接：它定义了互相通信的两个实体LNS和LAC。

在一对LAC和LNS之间可以建立多条隧道。隧道由一个控制连接和至少一个会话组成。
L2TP首先需要建立L2TP隧道，然后在L2TP隧道上建立会话连接，最后建立PPP连接。所有的L2TP需要承载的数据信息都是在PPP连接中进行传递的。

会话（Session）连接：它复用在隧道连接之上，用于表示承载隧道连接中的每个PPP连接过程。

会话是有方向的，从LAC向LNS发起的会话叫做Incoming会话，从LNS向LAC发起的会话叫做Outgoing会话。

每个接入用户和LNS之间均建立一条隧道；每条隧道中仅承载一台L2TP会话和PPP连接。

控制消息和数据消息

控制消息：控制消息用于隧道和会话连接的建立、维护以及传输控制；位于隧道和会话建立过程中。控制消息的传输是可靠传输，并且支持对控制消息的流量控制和拥塞控制；主要的控制消息包括控制报文、会话报文等。

控制报文用于建立和拆除、维持隧道，主要包括：

SCCRQ（Start-Control-Connection-Request）：控制连接发启请求。由LAC或者LNS向对端发送，用来初始化LAC和LNS之间的隧道，开始隧道的建立过程。NGFW的应用场景中，一般都是由LAC向LNS发起请求。
SCCRP（Start-Control-Connection-Reply）：表示接受了对端的连接请求，隧道的建立过程可以继续。
SCCCN（Start-Control-Connection-Connected）：对SCCRP的回应，完成隧道的建立。
StopCCN（Stop-Control-Connection-Notification）：由LAC或者LNS发出，通知对端隧道将要停止，控制连接将要关闭。另外，所有活动的会话都会被清除。
HELLO：隧道保活控制消息。L2TP使用Hello报文来检测隧道的连通性。LAC和LNS定时向对端发送Hello报文，如果在一段时间内未收到Hello报文的应答，隧道将被清除。

会话报文用于建立和拆除会话，主要包括：

ICRQ（Incoming-Call-Request）：当LAC检测到有用户拨入电话的时候，向LNS发送ICRQ，请求在已经建立的隧道中建立会话。
ICRP（Incoming-Call-Reply）：用来回应ICRQ，表示ICRQ成功，LNS也会在ICRP中标识L2TP会话必要的参数。
ICCN（Incoming-Call-Connected）：用来回应ICRP，L2TP会话建立完成。
CDN（Call-Disconnect-Notify）：由LAC或者LNS发出，通知对端会话将要停止。

数据消息：用于承载用户的PPP连接数据报文，并在隧道上进行传输。数据消息的传输是不可靠传输，若数据报文丢失，不予重传。不支持对数据消息的流量控制和拥塞控制。

L2TP VPN的报文封装

NAS-Initiated VPN隧道和会话建立过程：

建立PPPoE连接
LAC对用户进行认证。
建立L2TP隧道

L2TP数据以UDP报文形式发送。L2TP注册了UDP端口1701，但是这个端口仅用于初始的隧道建立过程。L2TP隧道发起方（LAC）任选一个空闲端口（未必是1701）向接收方（LNS）的1701端口发送报文；LNS收到报文后，使用1701端口给LAC的指定端口回送报文。至此，双方的端口选定，并在隧道保持连通的时间段内不再改变。
1. LAC检查用户的LCP协商中的认证信息（Domain、Username等），查找能够匹配的L2TP组，根据L2TP组的配置对某个LNS进行L2TP呼叫建立L2TP隧道。如果此时LAC发现L2TP隧道已经建立，则LAC发起会话连接，否则首先建立L2TP隧道。
2. LAC端向指定的LNS发送CHAP challenge信息，LNS回送该challenge响应消息CHAP response，并发送LNS侧的CHAP challenge，LAC返回该challenge的响应消息CHAP response。
  
  LAC和LNS之间通过SCCRQ、SCCRP和SCCCN消息完成L2TP隧道的建立，并且双方都知道对方的Tunnel ID等信息，后续的数据报文都会添加Peer的Tunnel ID信息，这样接收者就可以知道收到的L2TP报文属于本地的哪个隧道。
建立L2TP会话

LAC和LNS使用ICRQ、ICRP和ICCN消息建立L2TP会话，这些消息都在前面建立的L2TP隧道中传递，并且都会添加隧道对端的Tunnel ID信息。

在ICCN消息中，LAC端将用户CHAP response、response identifier和PPP协商参数传送给LNS，以便后续LNS与用户建立PPP连接。
LNS根据用户名、密码等信息对用户进行认证。
LNS对用户进行二次认证（可选）
LNS对用户在此认证（可选）
用户与LNS之间建立PPP连接。

完成了L2TP会话以后，LAC会将Client的相关PPP参数通过L2TP会话转发给LNS，LNS和用户进行PPP的认证。

LNS向用户分配地址然后建立PPP连接，注意此时的PPP连接在用户和LNS之间建立，并不是在LAC和LNS之间。

此时的LAC也保持着和用户的PPP连接，用于将来自LNS的L2TP数据报文解封装以后通过PPP连接传递给Client。
用户访问内网资源。

认证方式

LAC端认证方式

LAC端可对用户进行PAP或CHAP认证。在命令行配置中，使用VT接口下配置的PPP认证方式。

LNS端认证方式

LNS对用户的认证方式除由PPP认证方式决定外，还取决于配置的L2TP认证方式。L2TP认证方式有三种：代理认证、强制CHAP认证和LCP重协商。其中，LCP重协商的优先级最高，代理认证优先级最低。

LCP重协商

如果需要在LNS侧进行比LAC侧更严格的认证，或者LNS侧需要直接从用户获取某些信息（当LNS与LAC是不同厂商的设备时可能发生这种情况），则可以配置LNS与用户间进行LCP重协商。LCP重协商使用相应VT接口配置的认证方式。此时将忽略LAC侧的代理认证信息。
强制CHAP认证

如果只配置强制CHAP认证，则LNS对用户进行CHAP认证，如果认证不通过，会话就不能建立成功。
代理认证

代理认证就是LAC将它从用户得到的所有认证信息及LAC配置的认证方式传给LNS，LNS会利用这些信息和LAC端传来的认证方式对用户进行认证。

NAS-Initiated VPN中，在PPP会话开始时，用户先和LAC进行PPP协商。若协商通过，则由LAC初始化L2TP隧道连接，并将用户信息、认证信息等传递给LNS，由LNS根据收到的代理认证信息判断用户是否合法。

开源实现

SoftEtherVPN

C 语言实现的vpn，支持ike、l2tp/ipsec 、openvpn 、SSL-VPN等协议

以下是源码分析中启动UDP监听，并判断ike消息后进行处理返回的函数调用; 此框架非常庞大，集成了线程管理，List数据管理等。

StartProcess
	->StStartServer
		->SiNewServer
		->SiNewServerEx
		->SiInitConfiguration
			->NewIPsecServer
				->NewL2TPServer
				->NewIKEServer
				->NewUdpListener(IPsecServerUdpPacketRecvProc recv_proc)
					->NewUdpListenerEx(IPsecServerUdpPacketRecvProc recv_proc)
						->u->RecvProc = recv_proc; // 注册udp package处理函数
						->UdpListenerThread{//Main loop}
							->NewUDPEx2
								->NewUDP4
									->socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
									->bind(s, (struct sockaddr *)&addr, sizeof(addr))
							->RecvFrom
								->recvfrom
							->Add(recv_list, p);
							->u->RecvProc(u, recv_list) //调用udp package 处理函数IPsecServerUdpPacketRecvProc
								->IPsecProcPacket
									->p->DestPort == 4500 //处理ipsec esp协议 设置p->type
									->p->DestPort == 500  //处理IKE ISAKMP 协议 设置p->type
									->p->DestPort == 50   //处理ipsec ah协议 设置p->type
									ProcL2TPPacketRecv // 处理l2tp协议
									ProcIKEPacketRecv // 处理IPsec ike
										->ProcIkeMainModePacketRecv //处理主模式
										->IKE_EXCHANGE_TYPE_AGGRESSIVE //处理野蛮模式
										->IKE_EXCHANGE_TYPE_QUICK //处理快速模式
										->IKE_EXCHANGE_TYPE_INFORMATION //处理信息交换
							->SendTo
								->SendToEx
									->sendto //发送返回udp包
							->Disconnect
								->closesocket(s);

自己实现一个vpn

源码: https://github.com/gregnietsky/simpletun/blob/master/simpletun.c

简单vpn实现示意图，本质上是通过select 机制完成 tun设备的ethernet数据封装在 tcp协议里

« 从零开始写个文件系统记录一次kvm下Windows蓝屏问题 »

若鸟的博客