vault backup: 2026-11-07 16:33:44

2026-11-07 16:33:55 +08:00
commit 7015312702
1208 changed files with 132432 additions and 0 deletions
@@ -0,0 +1,419 @@
+**号主：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部**
+
+  
+
+上午好，我的网工朋友
+
+企业分支之间经常有互联的需求，企业互联的方式很多，可以使用专线线路或者Internet线路。  
+部分企业从成本和需求出发会选择使用Internet线路进行互联，但是使用Internet线路存在安全风险，如何保障数据在传输时不会被窃取？
+
+有的朋友会说[GRE](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=GRE&zhida_source=entity)，但**是在GRE隧道中不会对报文进行加密因此通过抓包是可以看到数据的报文信息，那怎么确保信息数据的安全呢？**
+
+这就要提到今天要讲的**[IPSec](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IPSec&zhida_source=entity) VPN**了，一起来看看IPSec VPN是如何运作并确保信息安全的。
+
+  
+
+**今日文章阅读福利：****《 VPN技术思维导图 》**
+
+****既然讲到VPN相关，另外再分析一份VPN相关的好资源给你，私信我，发送暗号**“VPN”**，即可获取技术之路一把好武器。****
+
+  
+
+# **01** **IPSec基本概念**
+
+IPsec（IP Security）协议族是IETF制定的一系列安全协议，**它为端到端IP报文交互提供了基于密码学的、可互操作的、高质量的安全保护机制。**
+
+通过对数据加密、认证，IPsec使得数据能够在Internet网络上安全的传输。**IPsec VPN技术可以和多种VPN技术结合使用，使得企业互联更加灵活安全。**
+
+![](https://pic3.zhimg.com/v2-461cf3f9dcd7880ca34a126d2f84b644_1440w.jpg)
+
+IPSec隧道
+
+  
+
+![](https://pic2.zhimg.com/v2-cdc038282e5583760f0b872476076b2b_1440w.jpg)
+
+GRE Over IPSec
+
+**IPSec不是一个单独的协议，它给出了IP网络上数据安全的一整套体系结构**，包括[AH](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=AH&zhida_source=entity)、[ESP](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=ESP&zhida_source=entity)、[IKE](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKE&zhida_source=entity)等协议。
+
+![](https://pic1.zhimg.com/v2-f8acd5d3d08a032624afa141e274798e_1440w.jpg)
+
+  
+
+**IPSec体系结构**
+
+IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输:
+
+- **数据来源验证:**接收方验证发送方身份是否合法:
+    
+  
+- **数据加密:**发送方对数据进行加密，以密文的形式在nternet上传送，接收方对接收的加密数据进行解密后处理或直接转发;
+    
+
+- **数据完整性:**接收方对接收的数据进行验证，以判定报文是否被改;
+    
+  
+- **抗重放:**接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
+    
+
+  
+
+****01 数据加密****
+
+**数据加密可以避免数据转发时被读取。数据加密一般有两种方案：**
+
+- **对称加密：**使用同一个密码加密/解密，效率很高，但是对称加密在互相交互密钥时存在密钥被截取的风险。
+    
+- **非对称加密：**使用公钥加密，私钥解密，安全性很高但是加解密效率很低。
+    
+
+  
+
+****02 数据认证****
+
+**数据认证的主要目的是确认数据是否被篡改，数据认证主要基于Hash算法。**
+
+- 数据通过Hash算法计算出一个唯一的Hash值，Hash值携带在数据中转发给对端。
+    
+  
+- 对端设备对数据重新进行Hash，得出Hash值。将收到的Hash值与计算出的Hash值进行比对，一致说明没有被篡改。
+    
+
+![](https://pic4.zhimg.com/v2-8987c97e8b087009f7170c13ff0f054f_1440w.jpg)
+
+数据认证方式简介
+
+  
+
+IPsec提供了两种安全机制：**加密和认证**。
+
+- IPsec采用对称加密算法对数据进行加密和解密。数据发送方和接收方使用相同的密钥进行加密、解密。
+    
+- IPsec采用HMAC（Hash-based Message Authentication Code）功能，比较数字签名进行数据完整性和真实性认证。
+    
+
+  
+
+****03 IPsec加密基本思路****
+
+IPsec同时使用对称加密与非对称加密，保证了安全也兼顾了性能。
+
+- 将对称加密所用的密钥，使用非对称算法加密并传递。
+    
+- 数据通过交互后的对称密钥加密。
+    
+
+![](https://pica.zhimg.com/v2-8165faddc5d68817e9736df6f8188bb2_1440w.jpg)
+
+IPsec加密基本思路
+
+  
+
+简单说就是双方通过使用非对称加密算法对同一密码进行加密得到一个对称秘钥，**然后使用该对称秘钥对数据进行加密**。一个前提就是密码是双方知道的，一般还是通过口头告知、文档等形式获取。
+
+  
+
+****04 安全联盟介绍****
+
+SA（Security Association，安全联盟） 可以帮助IPsec对特定要素进行约定，比如：**加密算法使用DES，认证算法使用MD5，封装方式使用Tunnel等。**
+
+IPsec技术在数据加密，数据验证，数据封装等方面有多种实现方式或算法，**两端的设备使用IPsec进行通信时需要保证一致的加密算法，验证算法等**。因此需要一种机制帮助两端设备协商这些参数。
+
+**建立IPsec SA一般有两种方式：**
+
+- **手工方式：**手工方式建立IPsec SA管理成本很高，加密验证方式需要手工配置，手工刷新SA，且SA信息永久存在安全性较低，适用于小型网络。
+    
+- **IKE方式：**IKE方式建立IPsec SA管理成本比较低，加密验证方式通过DH算法生成，SA信息有生成周期，且SA动态刷新，适用于小型，中大型网络。
+    
+
+IKE SA的主要作用是**构建一条安全的通道，用于交互IPsec SA。**
+
+IPsec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI、目的IP地址和使用的安全协议号（AH或ESP）。
+
+前面我们说到了IPSec框架中涉及到数据加密和认证，而实际情况下加密算法和认证算法很多，而IPSec中必须保证两端算法一致才能协商成功，那怎么协商呢？就是**通过SA来定义，通过在SA中指定加密算法、认证算法、封装模式、传输层协议等内容。**
+
+而在IPSec中有两个阶段：**IKE阶段和IPSec阶段，两个是承上启下的作用。**
+
+  
+
+****05 密钥交换介绍****
+
+**IPSec需要交互一个双方认可的对称秘钥，那怎么交互呢？**
+
+**现网中交互对称密钥一般会使用密钥分发协议：IKE（Internet Key Exchange，因特网密钥交换）。**
+
+IKE协议建立在[ISAKMP](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=ISAKMP&zhida_source=entity)（安全联盟和密钥管理协议）定义的框架上，是基于UDP的应用层协议。
+
+**它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。**
+
+![](https://pic3.zhimg.com/v2-bda576af0edfe2c74dd68cd486ba079c_1440w.jpg)
+
+密钥交换介绍
+
+  
+
+**IKE支持的认证算法有：**MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。
+
+**I****KE支持的加密算法有：**DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。
+
+ISAKMP由RFC2408定义，定义了**协商、建立、修改和删除SA的过程和包格式。**ISAKMP只是为SA的属性和协商、修改、删除SA的方法提供了一个通用的框架，并没有定义具体的SA格式。 **ISAKMP报文可以利用UDP或者TCP，端口都是500，一般情况下常用UDP协议，所以在防火墙上放通IPSec的流量可以允许UDP 500/4500端口的流量通过。**
+
+  
+
+****06 安全协议介绍****
+
+IPSec的加密与解密大致是在原有的报文头部增加一层或多层头部以实现加密，在传输层中
+
+IPsec有两种传输层协议提供认证或加密服务：**AH（认证头），ESP（封装安全载荷）。**
+
+- AH仅支持认证功能，不支持加密功能。
+    
+- ESP支持认证和加密功能。
+    
+
+AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。**AH协议的完整性验证范围为整个IP报文。**
+
+ESP支持认证和加密功能。 **ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data）。**
+
+与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。
+
+**关键字段含义：**
+
+- **Sequence Number：**是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
+    
+- **SPI：**IPsec安全参数索引，用于唯一标识IPsec安全联盟。
+    
+- **Authentication Data：**该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。
+    
+
+简单理解就是将内网源IP怎样进行再封装增加传输层报头，AH仅支持认证功能，**不支持加密功能，而ESP支持认证和加密功能,我一般情况下都是使用的ESP协议**。
+
+![](https://pica.zhimg.com/v2-fec62d7afc822baaca14c7ac17d77ec0_1440w.jpg)
+
+ESP模式
+
+  
+
+![](https://pic4.zhimg.com/v2-64ba3d01bb8a70fa7e0c23739c0ed873_1440w.jpg)
+
+AH模式
+
+  
+
+![](https://pic2.zhimg.com/v2-cfd4ed3896f8331386238e450c6a8247_1440w.jpg)
+
+不同模式的报文抓包
+
+### 
+
+****07 封装模式介绍****
+
+在传输层使用安全协议还涉及到一个封装模式的问题。**封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。**
+
+现网中多使用隧道模式进行封装。就是说这个报文的字段摆放顺序是怎样的。
+
+在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。**由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。**
+
+在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。
+
+**总结：**
+
+**IPSec是一个框架，通过IPSec实现的VPN称为IPSec VPN。IPSec通过加密和认证来实现安全传输。****第一阶段首先需要协商秘钥一致**，通过秘钥交换IKE来协商，生成一个IKE的SA(安全联盟)，里面定义了加密算法、认证算法、隧道模式等。
+
+**第二阶段使用一阶段的IKE SA进行加密数据**，可以选择AH或者ESP进行封装，AH不支持加密，ESP支持加密和认证，封装模式可以选择隧道模式或者传输模式，区别在于封装后数据包的头部不一样，一般情况下使用ESP安全协议以及隧道传输模式即可。
+
+  
+
+# **02** **IPSec VPN工作原理**
+
+IPsec的基本工作流程如下：
+
+- 通过IKE协商第一阶段协商出IKE SA。
+    
+- 使用IKE SA加密IKE协商第二阶段的报文，即IPsec SA。
+    
+- 使用IPsec SA加密数据。
+    
+
+![](https://pic1.zhimg.com/v2-96243e613ee4078e8179085238c62acc_1440w.jpg)
+
+IPsec基本工作流程
+
+  
+
+简单理解就是先创建一条安全协商的道路（IKE SA），然后通过IKE SA经过算法达到一个秘钥（IPSec SA）,接着使用IPSec SA对传输的流量进行加密与验证，这第三步就涉及到哪些流量需要加密，**我们需要通过一些方式将对应流量引入到IPSec VPN隧道中来进行传输。**
+
+  
+
+# **03** **IKE 协商**
+
+前面我们学习了IPSec双方需要协商出一个SA来进行算法的匹配，一般情况下我们使用IKE方式建立IPsec SA。**IKE是建立在ISAKMP定义的框架上，是基于UDP的应用层协议**。
+
+**它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。**
+
+简单说就是我们通过IKE这个框架协商出双方认可的**加密算法、认证算法、传输模式等等**。
+
+而IKE目前有两个版本：**[IKEv1](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKEv1&zhida_source=entity)和[IKEv2](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKEv2&zhida_source=entity)。**
+
+  
+
+****01 IKEv1****
+
+采用IKEv1协商安全联盟主要分为两个阶段：
+
+- **第一阶段：**通信双方协商并建立IKE协议本身使用的安全通道，即建立一个IKE SA；
+    
+  
+- **第二阶段：**利用第一阶段已通过认证与安全保护的安全通道，建立一对用于数据安全传输的IPsec SA。
+    
+
+![](https://pic2.zhimg.com/v2-91acb096759ca73ff526ff84b63c284b_1440w.jpg)
+
+IKEv1
+
+  
+
+**IKEv1协商第一阶段介绍：**
+
+IKEv1协商第一阶段的目的是建立IKE SA。**IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。**
+
+IKEv1协商第一阶段支持两种协商模式：**主模式（Main Mode） 和野蛮模式（Aggressive Mode）。**
+
+**主模式：**
+
+**主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：**
+
+- **消息①和②用于提议交换，发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。**匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
+    
+  
+- 消息③和④用于**密钥信息交换**，双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
+    
+
+- 消息⑤和⑥用于**身份和认证信息交换（双方使用生成的密钥发送信息）**，双方进行身份认证和对整个主模式交换内容的认证。
+    
+
+**野蛮模式：**
+
+野蛮模式只用到**三条信息**，**前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。**
+
+与主模式相比，野蛮模式**减少了交换信息的数目**，提高了协商的速度，但是没有对身份信息进行加密保护。
+
+实际情况下如果双方都有公网IP使用主模式，如果一方是拨号网络使用野蛮模式，因为IP不固定，而且野蛮模式需要协商发起方主动向固定IP的一端发起，**野蛮模式安全性相对较低。**
+
+**IKEv1协商第二阶段介绍：**
+
+IKEv1协商第二阶段的目的是建立用来安全传输数据的IPsec SA，并为数据传输衍生出密钥。
+
+第二阶段采用**快速模式（Quick Mode）**。该模式使用IKEv1协商第一阶段中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。
+
+![](https://pic4.zhimg.com/v2-84c7cb34d813267dd23a0bff8a86799b_1440w.jpg)
+
+快速模式协商过程
+
+  
+
+至此IKEv1就成功协商出了IKE SA和IPSec SA用于数据加密。
+
+  
+
+****02 IKEv2****
+
+**IKEv2简化了IKEv1协商SA的过程。IKEv2通常使用2次交换共4条消息就可以完成一对IPsec SA的建立**，如果要求建立的IPsec SA大于一对时，每一对IPsec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
+
+IKEv2定义了三种交换：**初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）**。
+
+  
+
+#### **1.初始交换**
+
+IKEv2通过初始交换就可以完成第一对IPsec SA的协商建立。初始交换包含两次交换四条消息。
+
+![](https://pic1.zhimg.com/v2-21cfaf691383be566b52ef05bab5bede_1440w.jpg)
+
+IKEv2初始交换介绍
+
+  
+
+**工作过程：**
+
+- 消息①和②属于**第一次交换**（称为IKE_SA_INIT交换），**以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换**。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPsec SA的所有密钥。
+    
+  
+- 消息③和④属于**第二次交换**（称为IKE_AUTH交换），**以加密方式完成身份认证、对前两条信息的认证和IPsec SA的参数协商**。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
+    
+
+就是如果是一条IPSec SA的建立只需要初始交换就可以完成，不需要用到子SA交换等等，更加简单快捷。
+
+报文抓包如下：
+
+只需要4个报文即可完成协商。
+
+![](https://pic4.zhimg.com/v2-61c76cc751c9f41c11046133b1f5c943_1440w.jpg)
+
+IKEv2是一次性把需要协商的数据都发送过去的模式。
+
+![](https://pic1.zhimg.com/v2-48fa5933d9312f32d5e87be5789e278e_1440w.jpg)
+
+IKEv2的初始交换中，**并没有直接区分为主模式（Main Mode）和野蛮模式（Aggressive Mode）这两种模式**，而是通过初始交换（Initial Exchanges）来完成类似于IKEv1中这两种模式的协商过程。
+
+**在IKEv2中，初始交换包括IKE_SA_INIT交换和IKE_AUTH交换，这两个交换过程顺序完成后，可以建立一个IKEv2 SA和一对IPsec SA。**
+
+**具体来说，IKEv2的初始交换配置如下：**
+
+- **IKE_SA_INIT交换：**这个交换完成IKEv2 SA参数的协商以及密钥交换。它对应于IKEv1的主模式的第1、3个包，以及野蛮模式的第1、2个包。
+    
+  
+- **IKE_AUTH交换：**这个交换完成通信对等体的身份认证以及IPsec SA的创建。它对应于IKEv1的主模式的第5、6个包，以及野蛮模式的第3个包。
+    
+
+**在IKEv2中，通过配置不同的认证方法和参数，可以实现类似于IKEv1中主模式和野蛮模式的功能。**例如，如果需要快速完成身份认证和密钥交换，可以使用类似于野蛮模式的配置，减少消息交换的数量。**如果需要更安全的身份认证过程，可以使用类似于主模式的配置，增加消息交换的数量以提供更强的安全性。**
+
+  
+
+#### **2.创建子SA交换介绍**
+
+当一个IKE SA需要创建多对IPsec SA时，需要使用创建子SA交换来协商多于一对的IPsec SA。**创建子SA交换还可以用于IKE SA的重协商。**
+
+创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。
+
+![](https://pic2.zhimg.com/v2-f2405e4af5ce12071708e35d446589e1_1440w.jpg)
+
+创建子SA交换介绍
+
+  
+
+#### **3.IKEv2通知交换介绍**
+
+运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的。
+
+通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。**控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。**
+
+![](https://pic2.zhimg.com/v2-c91630c533d997edf55a426171d29491_1440w.jpg)
+
+IKEv2通知交换介绍
+
+  
+
+# **04** **定义IPsec被保护流**
+
+**前面通过IKE已经协商出IPSec SA了，现在需要对分支间的数据进行保护，哪些流量需要进行加密保护呢？**我们需要通过一些方式来进行定义。
+
+IPsec是基于定义的感兴趣流触发对特定数据的保护，可以通过以下两种方式定义：
+
+- **ACL方式**，由ACL来指定要保护的数据流范围，筛选出需要进入IPsec隧道的报文。
+    
+- **路由方式**，通过IPsec虚拟隧道接口建立IPsec隧道，将所有路由到IPsec虚拟隧道接口的报文都进行IPsec保护。
+    
+
+ACL可以**更加精细控制源目地址、源目端口等流量，路由方式比较便捷**，但是**需要创建tunnel隧道接口方式**来实现，支持动态路由协议。
+
+通过IKE协商出**IPSec SA秘钥**，通过ACL或者路由匹配到感兴趣流量，最后将IPSec策略应用到指定的接口就可以实现IPSec VPN了。
+
+**总结：**
+
+通过IKE协商SA，IKE分v1和v2，一般情况下我用的应该是v1，v2可以快速协商出SA，然后通过ACL或者路由定义感兴趣流量，**将IKE提议、IPSec提议、创建IPSec策略、应用到接口串联起来就可以实现IPSec VPN的应用了，其实就是理论比较复杂，实际配置不算太难。**  
+
+  
+
+**整理：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部**
@@ -0,0 +1,29 @@
+根据搜索结果，“TLCP”指的是**传输层密码协议**（Transport Layer Cryptography Protocol），是中国国家标准（GB/T 38636-2020）中定义的、完全采用国密算法（如SM2、SM3、SM4）的安全通信协议。
+
+至于GmSSL项目中为何能看到TLS 1.2、1.3和TLCP，却没有TLS 1.0和1.1，主要有两个原因：一是国密标准的特殊性，二是基于安全性和合规性的设计。
+
+为了让你更清晰地了解GmSSL所支持的协议及其特点，我整理了下面的表格：
+
+| 协议名称              | 标准依据                                       | GmSSL支持情况         | 主要特点与目的                                                 |
+| :---------------- | :----------------------------------------- | :---------------- | :------------------------------------------------------ |
+| **TLCP**          | 国家标准 **GB/T 38636-2020**，前身是GM/T 0024-2014 | **支持** (TLCP 1.1) | **纯国密算法**。为中国网络环境定制的传输层安全协议，强调合规性，是GmSSL的重点支持协议。        |
+| **TLS 1.3**       | 国际标准 (RFC 8446)                            | **支持**            | **现代国际标准**。安全性最高、性能最佳。GmSSL也支持其中国密算法套件（RFC 8998）。       |
+| **TLS 1.2**       | 国际标准 (RFC 5246)                            | **支持**            | **广泛兼容的国际标准**。为了与现有国际互联网生态兼容，GmSSL同样支持包含国密算法套件的TLS 1.2。 |
+| **TLS 1.1 / 1.0** | 国际标准 (已过时)                                 | **不支持**           | **陈旧且存在已知安全缺陷**。出于安全性考虑，现代密码库（包括GmSSL）通常已放弃支持。          |
+
+### 🔍 深入解析两个核心问题
+
+**1. TLCP是什么？**
+TLCP是一个独立的国家标准协议。它并非国际TLS协议的直接修改版，而是基于中国密码标准体系重新设计的。其核心特点包括：
+- **强制使用国密算法**：全面采用SM2（非对称加密/签名）、SM3（杂凑）、SM4（对称加密）等国密算法。
+- **独特的“双证书”体系**：要求服务器端同时使用“加密证书”和“签名证书”两套证书，将密钥交换与身份认证分离，增强了安全性与监管能力。
+- **独立的协议版本号**：为了避免与国际TLS协议混淆，TLCP在通信中使用独立的协议版本号 `0x0101`。
+
+**2. 为什么GmSSL不支持TLS 1.0/1.1？**
+这是GmSSL主动的设计选择，主要基于两方面原因：
+- **安全性考量**：TLS 1.0和1.1协议已被证实存在多个严重安全漏洞，在现代安全实践中已被普遍弃用。
+- **合规性聚焦**：GmSSL的核心目标是提供符合中国密码管理要求的解决方案。它优先实现了**代表国密标准的TLCP**，以及**当前最安全、最主流的国际标准TLS 1.3和广泛使用的TLS 1.2**，并在这些版本中集成了国密算法套件。这样既确保了合规，又兼顾了安全性与互通性。
+
+总而言之，你可以将GmSSL理解为：一个以支持**国密标准TLCP**为核心，同时兼容**安全的国际标准TLS 1.2/1.3（含国密套件）**，并主动摒弃了**过时不安全协议**的密码工具箱。
+
+如果你正在使用GmSSL进行开发，需要根据你的通信对方（是国密环境还是国际环境）来选择启用TLCP或TLS协议。
@@ -0,0 +1,28 @@
+TLS 1.0 与 TLS 1.1 的主要区别在于，TLS 1.1 是对 TLS 1.0 已知安全漏洞的**针对性修补版本**。虽然它们现在都已过时，但了解其区别有助于理解安全协议的演进脉络。
+
+下面的表格清晰地列出了它们的核心差异：
+
+| 特性/方面          | **TLS 1.0** (RFC 2246, 1999年)                      | **TLS 1.1** (RFC 4346, 2006年)                           | 区别的意义与影响                                  |
+| :------------- | :------------------------------------------------- | :------------------------------------------------------ | :---------------------------------------- |
+| **针对CBC攻击的防护** | **无**。初始化向量(IV)是显式且可预测的，易受**BEAST攻击**。             | **有**。规定必须使用**显式的、不可预测的IV**，并建议在记录中发送IV。                | 这是最重要的安全修补，直接封堵了TLS 1.0最危险的理论攻击路径之一。      |
+| **应对填充预言攻击**   | **无防护**。对填充错误的处理方式，可能泄露信息，导致**Lucky Thirteen**等攻击。 | **有改进**。规定必须统一所有错误的处理方式（统一返回“bad_record_mac”警报），但未根本解决。 | 提高了攻击难度，但真正的解决是在TLS 1.2中引入了HMAC等更健壮的验证方式。 |
+| **IANA注册与扩展**  | **未明确定义**。对协议扩展和新算法的支持方式比较模糊。                      | **明确定义**。为算法参数等引入了IANA注册机制，为未来协议扩展铺平了道路。                | 提升了协议的灵活性和可维护性，是协议成熟化的标志。                 |
+| **其他调整**       | 依赖**MD5/SHA-1**等较弱的哈希函数。                           | 新增对 **AES** 密码套件的正式支持。                                  | 反映了当时密码学的发展，但未触及核心算法弱点。                   |
+
+### 🔍 核心区别详解
+
+**1. 对抗CBC攻击：从“可预测”到“显式IV”**
+这是最关键的改进。在TLS 1.0中，每条加密记录的初始向量(IV)是**从前一条记录的密文中推导出来的**，这使得攻击者有可能预测并构造恶意请求（BEAST攻击）。TLS 1.1强制要求每条记录的IV都必须是**独立、显式且不可预测的**，从根本上切断了这种攻击的可能性。
+
+**2. 错误处理：从“信息泄露”到“统一模糊”**
+在TLS 1.0中，服务器对接收到的错误数据包（如填充错误、MAC校验错误）可能会返回不同的错误警报。攻击者可以像“询问神谕”一样，通过观察这些细微的差异来逐步破解密文。TLS 1.1规定，对于这类错误必须**统一返回完全相同的通用错误警报**，使攻击者无法从服务器响应中获取有效信息。
+
+### 💎 总结与定位
+
+- **关系**：TLS 1.1本质上是TLS 1.0的**安全补丁版**。它修复了最紧迫的安全问题，但没有进行架构或算法上的重大革新。
+- **根本局限**：两者都**深度依赖已不安全的MD5和SHA-1哈希算法**，且TLS 1.1未能完全解决填充预言攻击（直到TLS 1.2才彻底解决）。因此，它们的安全基线在当今看来仍然很低。
+- **现状**：**TLS 1.0和1.1均已遭全球淘汰**。所有主流浏览器、操作系统和现代安全标准（如PCI DSS）都已默认禁用它们。目前的标准是**TLS 1.2和1.3**。
+
+因此，虽然TLS 1.1比1.0更安全，但这只是“五十步”与“一百步”的区别。在现代应用中，两者都应被**视为不安全协议而严格禁用**。
+
+如果你是在维护一个必须兼容古董设备的特殊系统，了解这些细节可能有用；但在任何新项目或安全审计中，正确的做法都是直接启用TLS 1.2/1.3，并明确禁用1.0和1.1。
@@ -0,0 +1 @@
+deliver 函数
@@ -0,0 +1,65 @@
+
+进入编译环境
+sh dev.sh
+
+
+进入 nginx 目录
+cd nginx-1.18.0
+
+make clean
+修改版编译参数
+```
+./configure \
+--prefix=/usr/local/nginx \
+--with-http_ssl_module \
+--with-http_stub_status_module \
+--with-http_realip_module \
+--with-http_auth_request_module \
+--with-threads \
+--with-openssl="/app/gmssl/gmssl" \
+--with-cc-opt="-Iapp/gmssl/gmssl/include" \
+--with-ld-opt="-lm" \
+--with-stream \
+--with-stream_ssl_module \
+--with-debug
+```
+
+
+GMSSL 版本（不建议）
+```
+./configure --prefix=/usr/local/nginx \
+--with-http_ssl_module \
+--with-gmssl=./GmSSL/ \
+--with-stream \
+--with-stream_ssl_module \
+--without-http_upstream_zone_module \
+--without-stream_upstream_zone_module \
+--with-http_auth_request_module \
+--with-debug
+```
+
+
+GMSSL 版本（不建议）
+```
+./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_auth_request_module --without-http_upstream_zone_module --with-gmssl=./GmSSL/ --with-debug
+```
+
+
+
+make
+make install
+
+容器内路径：/usr/local/nginx
+容器外路径：/app/ssl/gateway.lib/target-nginx
+
+
+
+进入 docker-image 目录，进行容器构建。
+拷贝 nginx 文件为 gateway
+test1.sh 测试
+国密浏览器访问 8443 端口
+
+打包
+sh build.sh
+docker tag gateway.lib gateway.lib:20251209
+docker save gateway.lib:20251209 -o gateway.lib.20251209.tar
@@ -0,0 +1,634 @@
+该文章已生成可运行项目，预览并下载项目源码
+
+      在[数字经济](https://so.csdn.net/so/search?q=%E6%95%B0%E5%AD%97%E7%BB%8F%E6%B5%8E&spm=1001.2101.3001.7020)加速发展的今天，网络通信安全已成为关键基础设施的核心保障。我国自主研发的国密算法（如 SM2、SM3、SM4 等）作为国家密码标准，在金融、政务、能源等关键领域的合规要求日益明确。然而，传统 Web 服务器（如 Nginx）主要支持国际通用加密算法（如 RSA、ECC），难以直接满足国密合规需求。在此背景下，openHiTLS 社区推出的 “nginx-with-openHiTLS” 项目应运而生，通过集成自主创新的 openHiTLS 密码库，为 Nginx 赋予国密算法与 TLCP 协议支持，成为构建安全可靠加密体系的重要技术方案。
+
+### 国密改造的核心诉求：
+
+       [国密算法](https://so.csdn.net/so/search?q=%E5%9B%BD%E5%AF%86%E7%AE%97%E6%B3%95&spm=1001.2101.3001.7020)（国家商用密码算法）是我国自主设计的加密标准，包括 SM2（非对称加密）、SM3（哈希算法）、SM4（对称加密）等，旨在保障国家信息安全与数据主权。随着《网络安全法》《密码法》等法规的实施，关键行业对 “国密合规” 的要求已从 “可选” 变为 “强制”。
+
+      传统 Nginx 作为全球主流的 Web 服务器，虽支持 TLS 1.2/1.3 等国际协议，但缺乏对国密算法及 TLCP（传输层密码协议，我国基于国密算法的 TLS 协议标准）的原生支持。若要在关键业务中使用 Nginx，必须通过技术改造实现国密协议与算法的集成 —— 这正是 openHiTLS 社区的核心目标：**基于 Nginx 稳定版本（1.24），通过集成 openHiTLS 密码库，让 Web 服务无缝支持国密标准，同时保留 Nginx 原有的高性能与稳定性**。
+
+### nginx-with-openHiTLS：技术特性解析
+
+nginx-with-openHiTLS 并非对 Nginx 的重构，而是在其基础上进行模块化扩展，核心特性包括：
+
+1. **原生支持 TLCP 协议**  
+    作为国密标准的传输层协议，TLCP 可基于 SM2/SM3/SM4 算法实现端到端加密，解决了传统 TLS 协议依赖国际算法的合规性问题。
+    
+2. **兼容 TLS 1.2 协议**  
+    保留对国际通用协议的支持，满足混合加密场景需求（如同时服务国内合规用户与国际用户）。
+    
+3. **完善的客户端证书验证机制**  
+    支持基于国密证书的双向认证，可通过配置 CA 证书链与验证深度，强化对客户端身份的合法性校验，适用于金融交易、政务服务等高安全场景。
+    
+
+### 部署指南：从编译到运行的全流程
+
+nginx-with-openHiTLS 的部署需依赖 openHiTLS 密码库的编译与集成，以下为详细步骤（基于 Linux 系统）：
+
+#### 1. 环境准备
+
+确保系统满足基础依赖：
+
+- 操作系统：Linux（如 CentOS、Ubuntu）
+- 编译工具：GCC 编译器、Make 工具
+- 依赖库：PCRE（正则表达式支持）
+
+#### 2. 编译 openHiTLS 密码库
+
+bash
+
+```cobol
+# 1. 克隆代码仓库git clone https://gitcode.com/openHiTLS/openhitls.git # 2. 进入目录并创建构建文件夹cd openHiTLS && mkdir -p ./build && cd ./build # 3. 生成构建配置（根据架构选择）# 3.1 通用64位构建python3 ../configure.py --enable hitls_bsl hitls_crypto hitls_tls hitls_pki hitls_auth --lib_type static --bits=64 --system=linux # 3.2 x86_64架构优化构建python3 ../configure.py --enable hitls_bsl hitls_crypto hitls_tls hitls_pki hitls_auth --lib_type static --bits=64 --system=linux --asm_type x8664 # 3.3 armv8架构优化构建python3 ../configure.py --enable hitls_bsl hitls_crypto hitls_tls hitls_pki hitls_auth --lib_type static --bits=64 --system=linux --asm_type armv8 # 4. 生成构建脚本并编译安装cmake ..make && make install
+```
+
+#### 3. 编译并安装 nginx-with-openHiTLS
+
+bash
+
+```cobol
+# 1. 配置Nginx编译选项（指定openHiTLS路径）cp auto/configure ../configure --prefix=/path/to/install \  --with-cc-opt="-std=c99" \  --with-http_ssl_module \  --with-openhitls=/path/to/openhitls  # 替换为openHiTLS实际安装路径 # 2. 编译并安装make && make install
+```
+
+#### 4. 国密协议配置示例
+
+部署完成后，需通过 Nginx 配置文件启用 TLCP 协议与国密证书，典型配置如下：
+
+nginx
+
+```cobol
+server {    listen 443 ssl;    server_name example.com;  # 替换为实际域名     # 启用TLCP协议（国密传输层协议）    ssl_protocols TLCP;        # 国密证书配置（需同时指定签名与加密证书）    ssl_certificate /path/to/sign.crt;     # 签名证书（SM2）    ssl_certificate /path/to/enc.crt;      # 加密证书（SM2）    ssl_certificate_key /path/to/sign.key; # 签名私钥    ssl_certificate_key /path/to/enc.key;  # 加密私钥        # 客户端证书验证（双向认证场景）    ssl_verify_client on;                         # 开启客户端验证    ssl_client_certificate /path/to/ca-chain.crt; # 客户端CA证书链    ssl_verify_depth 3;                           # 验证深度（最多追溯3级CA）}
+```
+
+#### 5. 启动与验证
+
+bash
+
+```cobol
+# 进入安装目录cd /path/to/nginx # 指定配置文件启动./sbin/nginx -c ./conf/nginx.conf # 验证启动状态（查看错误日志排查问题）tail -f /path/to/nginx/error.log
+```
+
+### 关键注意事项与故障排除
+
+1. **证书格式与权限**  
+    国密证书需使用 PEM 格式，且证书 / 私钥文件权限需限制为`600`（仅所有者可读写），避免权限泄露导致安全风险。
+    
+2. **TLCP 协议的特殊要求**  
+    启用 TLCP 时必须同时配置签名证书与加密证书（国密算法设计要求），缺少任一证书会导致协议握手失败。
+    
+3. **常见错误排查**
+    
+    - 证书格式错误：通过`openssl x509 -in cert.crt -text`验证 PEM 格式合法性；
+    - 依赖缺失：编译失败时检查 GCC、PCRE 等依赖是否安装完整；
+    - 协议不兼容：客户端需支持 TLCP 协议才能建立连接，可通过`openssl s_client -connect example.com:443 -tls1_2`测试基础连通性。
+
+### 开源实践：nginx-with-openHiTLS开源代码实现
+
+代码下载链接：[GitCode - 全球开发者的开源社区,开源代码托管平台](https://gitcode.com/openHiTLS/nginx/tree/branches/stable-1.24/src "GitCode - 全球开发者的开源社区,开源代码托管平台")
+
+> 【openHiTLS密码开源社区】
+> 
+>  openHiTLS旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件，通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求，让密码技术应用更简单，同时探索后量子等先进算法创新实践，构建密码前沿技术底座！  
+>  项目地址:[https://gitcode.com/openHiTLS/openhitls](https://gitcode.com/openHiTLS/openhitls "https://gitcode.com/openHiTLS/openhitls")
+
+![](https://i-blog.csdnimg.cn/direct/c19256d9901241a6a30afa567744a1bc.png)密码开源先锋聚焦密码学与开源技术的知识分享平台
+
+![](https://g.csdnimg.cn/extension-box/2.0.0/image/weixin.png)微信公众号
+
+![](https://g.csdnimg.cn/extension-box/2.0.0/image/ic_move.png)
+
+本文章已经生成可运行项目一键运行
+
+生成项目![查看更多](https://csdnimg.cn/release/blogv2/dist/pc/img/btnInscodeAiAskWhite.png)
+
+关注博主即可阅读全文 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/arrowDownAttend.png) 
+
+[![](https://i-avatar.csdnimg.cn/355cd0deee474cf1ba93a435aae2c294_openHiTLS.jpg!1)openHiTLS密码开源社区](https://openhitls.blog.csdn.net/)
+
+关注
+
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/like.png)38
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/unlike.png)
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/collect.png)32
+    
+    觉得还不错?一键收藏![](https://csdnimg.cn/release/blogv2/dist/pc/img/collectionCloseWhite.png)
+    
+- [![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/comment.png)0](https://blog.csdn.net/openHiTLS/article/details/150497042#commentBox)
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/share.png)分享
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/more.png)
+
+专栏目录
+
+[
+
+_nginx_ 同一端口同时支持_国密_和标_密_功能
+
+](https://blog.csdn.net/Big_Bristlegass/article/details/140845641)
+
+[Big_Bristlegass的博客](https://blog.csdn.net/Big_Bristlegass)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1810
+
+[
+
+_nginx_支持同一端口，支持_国密_和标_密_
+
+](https://blog.csdn.net/Big_Bristlegass/article/details/140845641)
+
+[
+
+_NGINX_学习记录__nginx_ root
+
+](https://blog.csdn.net/qq_43542296/article/details/127204254)
+
+12-19
+
+[
+
+worker_processes和worker_connections可以实际的设置_nginx_的总体最大连接数,比如worker_processes设置为2,worker_connections设置为1024,那么_nginx_的总体最大连接数就是2048个。但是这些连接数,不仅包含了_nginx_和客户端的链接,还包含了_nginx_和被代理的服务端的链接,因此不代表_nginx_的并发能力是2048,具体设置多少,要根据压测...
+
+](https://blog.csdn.net/qq_43542296/article/details/127204254)
+
+[
+
+HTTPS配置_-__-_基于_nginx_
+
+](https://blog.csdn.net/nero_claudius/article/details/91891384)
+
+12-12
+
+[
+
+_nginx__:_[emerg]the"ssl"parameter requires ngx_http_ssl_modulein/usr/local/_nginx_/conf/_nginx_.conf 智能体编程shell 1 查看你最初配置_nginx_时的参数 /usr/local/_nginx_/sbin/_nginx_ _-_V 智能体编程shell 1 显示如下(如果没有–_with__-_http_ssl_module,则说明未添加http_ssl_module模块) configure arguments_:_ _-__-_pref...
+
+](https://blog.csdn.net/nero_claudius/article/details/91891384)
+
+[
+
+_nginx__国密_证书(gmssl)安装
+
+](https://blog.csdn.net/qq_44877496/article/details/138184055)
+
+[qq_44877496的博客](https://blog.csdn.net/qq_44877496)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 4237
+
+[
+
+本文档基于此安装包安装若目标机无法上网，无法执行yum，可通过手动下载安装包，rpm执行安装，部分rpm安装包如下。
+
+](https://blog.csdn.net/qq_44877496/article/details/138184055)
+
+[
+
+_nginx_深度学习2——https之生成秘钥和CA证书
+
+](https://blog.csdn.net/qq_22059611/article/details/89082938)
+
+[苏云南雁的博客](https://blog.csdn.net/qq_22059611)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 665
+
+[
+
+openssl version 查看 _nginx_ _-_v 1，生成秘钥和CA证书 步骤一：生成key秘钥 步骤二：生成证书签名请求文件（csr文件） 步骤三：生成证书签名文件（CA证书，一般是第三方，学习过程可以自己弄） 具体步骤，在_nginx_下建立一个目录，输入： openssl genrsa _-_idea _-_out jesonc.key 1024 然后输入验证_密_码，然后...
+
+](https://blog.csdn.net/qq_22059611/article/details/89082938)
+
+[
+
+配置_Nginx_,完善_Nginx_启动脚本_上线时脚本修改_nginx_配置
+
+](https://blog.csdn.net/jun54555/article/details/4207961)
+
+12-18
+
+[
+
+Starting _nginx__-_0.6.17_:_ start_-_stop_-_daemon_:_ /lib/tls/libc.so.6_:_ version `GLIBC_2.4' not found (required by start_-_stop_-_daemon) # ls _-_lt /lib/tls/libc* # 版本过低,在Ubuntu中【/lib/libc.so.6 _-_> libc_-_2.6.1.so】 lrwxrwxrwx 1 root root 13 Mar 1 2007 /lib/tls/libc.so.6 _-_> l...
+
+](https://blog.csdn.net/jun54555/article/details/4207961)
+
+[
+
+深度学习_Nginx_第二章_:__Nginx_ 关于SSL安全协议__nginx_ ssl 算法
+
+](https://blog.csdn.net/ligupeng7929/article/details/97752462)
+
+9-27
+
+[
+
+深度学习_Nginx_第二章_:__Nginx_ 关于SSL安全协议 本文深入探讨了_Nginx_在SSL安全协议中的作用,包括对称加_密_、非对称加_密_原理,CA如何验证证书及防止证书过期,以及不同类型的SSL证书。此外,还详细介绍了TLS通讯过程,并着重分析了_Nginx_在握手性能方面的考虑,特别是对称加_密_和非对称加_密_算法的影响。
+
+](https://blog.csdn.net/ligupeng7929/article/details/97752462)
+
+[
+
+【_密_码学实战】_openHiTLS_ mac命令行：消息认证码工具
+
+最新发布
+
+](https://openhitls.blog.csdn.net/article/details/152713883)
+
+[开源代码仓：https://gitcode.com/openHiTLS/openhitls](https://blog.csdn.net/openHiTLS)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1107
+
+[
+
+`hitls mac`是_openHiTLS__密_码工具包中用于计算消息认证码（MAC）的命令行工具，核心功能为验证消息完整性与真实性。它支持HMAC、CMAC、GMAC及_国密_（SM3、SM4_-_CBC_-_MAC）等多类算法，提供_密_钥（明文/十六进制）、输入输出（文件/标准流、二进制/十六进制）等丰富选项，兼具硬件加速、大文件分块处理等性能优化特性。
+
+](https://openhitls.blog.csdn.net/article/details/152713883)
+
+[
+
+天安tassl+原生_nginx_搭建_国密_网站
+
+](https://blog.csdn.net/qlau2007/article/details/139225533)
+
+[qlau2007的博客](https://blog.csdn.net/qlau2007)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2107
+
+[
+
+基于天安tassl和原生_nginx_搭建_国密_网站测试
+
+](https://blog.csdn.net/qlau2007/article/details/139225533)
+
+[
+
+_Nginx___nginx_100%windows
+
+](https://blog.csdn.net/m0_74337295/article/details/134035058)
+
+12-19
+
+[
+
+_Nginx_配置 3.1 _nginx_的基本功能 3.2 _nginx_的扩展功能 4. _nginx_的模块与工作原理 4.1 _nginx_的模块分类 4.2_nginx_工作原理 4.3echo模块用法 5.1_nginx_的安装 5.2_nginx_安装后配置 6.1 _nginx_.conf配置详解 6.2 用于调试、定位问题的配置参数 6.3 正常运行必备的配置参数 ...
+
+](https://blog.csdn.net/m0_74337295/article/details/134035058)
+
+[
+
+_Nginx_手册_输入一个路径,实现将该路径下所有的文件归类。相同类型的文...
+
+](https://blog.csdn.net/weixin_38374686/article/details/127720596)
+
+12-17
+
+[
+
+–prefix=/usr/local/_nginx_ –user=_nginx_ –group=_nginx_ –_with_out_-_http_uwsgi_module –_with_out_-_http_scgi_module –_with_out_-_http_browser_module –_with__-_pcre –_with__-_http_addition_module –_with__-_http_ssl_module –_with__-_http_realip_module –_with__-_http_sub_module ...
+
+](https://blog.csdn.net/weixin_38374686/article/details/127720596)
+
+[
+
+_Nginx__国密__改造_
+
+](https://blog.csdn.net/qq_49081692/article/details/130964954)
+
+[qq_49081692的博客](https://blog.csdn.net/qq_49081692)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 4771
+
+[
+
+_国密_web服务器，_国密__nginx_，_nginx__国密_，_国密__改造_
+
+](https://blog.csdn.net/qq_49081692/article/details/130964954)
+
+[
+
+搭建支持_国密_GmSSL的_Nginx_环境
+
+](https://blog.csdn.net/Bejpse/article/details/145804164)
+
+[](https://blog.csdn.net/Bejpse)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1672
+
+[
+
+2、安装包准备：需要GmSSL、_国密__Nginx_，可通过互联网下载或者从 https_:_//download.csdn.net/download/m0_46665077/89936158 下载_国密_GmSSL安装包和_国密__Nginx_安装包。1.配置 _nginx_ 开机自启，创建 /etc/systemd/system/_nginx_.service 的服务文件。_国_际RSA证书存放：/usr/local/gmssl/ssl/rsa/_国密_证书存放：/usr/local/gmssl/ssl/gm/
+
+](https://blog.csdn.net/Bejpse/article/details/145804164)
+
+[
+
+RSA盲签名技术解析及代码实现_实践__rsa rfc
+
+](https://blog.csdn.net/openHiTLS/article/details/153263461)
+
+11-28
+
+[
+
+5.2 技术_实践__:__openHiTLS_的标准化实现 值得关注的是,_openHiTLS_已基于RFC9474标准完成了RSA盲签名技术的工程化实现,为开发者与企业提供了标准化、高可用的技术工具包。该实现严格遵循“盲化_-_签名_-_去盲”的核心流程,通过关键函数封装算法逻辑,以下结合核心代码片段说明其实现思路_:_ ...
+
+](https://blog.csdn.net/openHiTLS/article/details/153263461)
+
+[
+
+_nginx__-_tmp.tar.gz
+
+](https://download.csdn.net/download/w277608109/19855832)
+
+06-27
+
+[
+
+标签中的“_国密_服务器”表明这个_Nginx_配置是为满足中_国_对加_密_技术的要求而优化的，能够处理基于SM2、SM3和SM4的加_密_通信。 “gmssl静态库_国密_版”进一步确认了库文件是GMSSL的静态版本，集成了中_国_的加_密_算法。 ...
+
+](https://download.csdn.net/download/w277608109/19855832)
+
+[
+
+信创_-__nginx__-__国密_ssl_改造_
+
+](https://blog.csdn.net/twobun/article/details/136169543)
+
+[twobun的博客](https://blog.csdn.net/twobun)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2348
+
+[
+
+信创 _nginx_ _国密__改造_
+
+](https://blog.csdn.net/twobun/article/details/136169543)
+
+[
+
+_国密_GmSSL安装包+_国密__Nginx_安装包+搭建_国密_应用服务器
+
+](https://download.csdn.net/download/m0_46665077/89936158)
+
+10-30
+
+[
+
+_国密_GmSSL和_国密__Nginx_是专门为中_国_商用_密码算法_设计的安全工具包，它们在确保网络安全、数据传输加_密_以及防止信息泄露方面发挥着重要作用。GmSSL是基于OpenSSL_改造_的，它支持_国_产_密码算法_，如SM2、SM3、SM4等，可...
+
+](https://download.csdn.net/download/m0_46665077/89936158)
+
+[
+
+换_Nginx__-__with__-_Gmsslv3 怎么编译到_nginx_里面
+
+](https://wenku.csdn.net/answer/5xd6vcxqnr)
+
+09-13
+
+[
+
+现在用户明确询问如何将_Nginx__-__with__-_Gmsslv3（即支持_国密_SSL协议版本3的_Nginx_）编译到_Nginx_中。注意，用户提到的“_Nginx__-__with__-_Gmsslv3”可能是一个特定的支持_国密_的_Nginx_分支或补丁。 根据之前的知识，我们知道...
+
+](https://wenku.csdn.net/answer/5xd6vcxqnr)
+
+[
+
+编译 _Nginx__-__with__-_GmSSLv3 时可能会遇到哪些常见错误及解决办法？
+
+](https://wenku.csdn.net/answer/12findmsna)
+
+09-13
+
+[
+
+如何验证_Nginx__-__with__-_GmSSLv3是否成功支持_国密_算法？ 2. 在_Nginx__-__with__-_GmSSLv3中如何配置_国密_双证书？ 3. 运行_Nginx__-__with__-_GmSSLv3时可能遇到哪些问题？ 4. 如何调试_Nginx__-__with__-_GmSSLv3的TLS握手过程？ ### 编译 ...
+
+](https://wenku.csdn.net/answer/12findmsna)
+
+[
+
+编译_nginx_支持_国密_SSL协议
+
+](https://devpress.csdn.net/v1/article/detail/108080409)
+
+[gmssl的博客](https://blog.csdn.net/gmssl)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 6619
+
+[
+
+1 背景 _Nginx_自身支持标准的SSL协议，但并不支持_国密_SSL协议。本文描述了_Nginx_配置的_国密_SSL协议（单向）的完整过程，仅供学习和参考之用。 _Nginx_无需修改源码、支持任意版本_Nginx_。 2 环境 服务器OS是CentOS7.7的64位版本，IP位192.168.0.98，客户端OS是WindowsXP。 _Nginx_是_Nginx__-_1.18.0。 浏览器是360安全浏览器（支持_国密_）。 3 安装方法一：源码编译 GMSSL.cn提供一个OpenSSL的_国密_版库，可与_nginx_编译，生成的ngi
+
+](https://devpress.csdn.net/v1/article/detail/108080409)
+
+[
+
+_Nginx__国密_化
+
+](https://blog.csdn.net/xuxunaa/article/details/126589156)
+
+[前端摸鱼第一名](https://blog.csdn.net/xuxunaa)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2984
+
+[
+
+【代码】_Nginx__国密_化保姆教程
+
+](https://blog.csdn.net/xuxunaa/article/details/126589156)
+
+[
+
+ubuntu18.04搭建基于_国密_算法的_nginx_环境
+
+](https://devpress.csdn.net/v1/article/detail/122635880)
+
+[a1309525802的博客](https://blog.csdn.net/a1309525802)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 4741
+
+[
+
+ubuntu18.04搭建基于_国密_算法的_nginx_环境 ubuntu18.04安装 https_:_//mirrors.tuna.tsinghua.edu.cn/ubuntu_-_releases/18.04/ 可以选择安装桌面版的或者服务器版的,看个人需求 安装基本依赖 #进入root用户 sudo _-_i #更新源 apt update apt upgrade #安装gcc apt install gcc #安装make apt install make #安装git apt install git #安装li
+
+](https://devpress.csdn.net/v1/article/detail/122635880)
+
+[
+
+麒麟V10安装支持_国密_GmSSL的_Nginx_
+
+](https://blog.csdn.net/qq_37437139/article/details/145136608)
+
+[qq_37437139的博客](https://blog.csdn.net/qq_37437139)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1867
+
+[
+
+按照官网的操作配置完了不好使，还没解决
+
+](https://blog.csdn.net/qq_37437139/article/details/145136608)
+
+[
+
+构建网络信息安全的中_国_方案 _-_ _国密_SSL/_TLCP_协议介绍以及_国密__Nginx_服务器部署
+
+热门推荐
+
+](https://devpress.csdn.net/v1/article/detail/134562784)
+
+[new9232的博客](https://blog.csdn.net/new9232)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1万+
+
+[
+
+_国密_SSL协议指的是采用_国密_算法，符合_国密_标准的安全传输协议。简而言之，_国密_SSL就是SSL/TLS协议的_国密_版本。
+
+](https://devpress.csdn.net/v1/article/detail/134562784)
+
+- [关于我们](https://www.csdn.net/company/index.html#about)
+- [招贤纳士](https://www.csdn.net/company/index.html#recruit)
+- [商务合作](https://fsc-p05.txscrm.com/T8PN8SFII7W)
+- [寻求报道](https://marketing.csdn.net/questions/Q2202181748074189855)
+- ![](https://g.csdnimg.cn/common/csdn-footer/images/tel.png)400-660-0108
+- ![](https://g.csdnimg.cn/common/csdn-footer/images/email.png)[kefu@csdn.net](mailto:webmaster@csdn.net)
+- ![](https://g.csdnimg.cn/common/csdn-footer/images/cs.png)[在线客服](https://csdn.s2.udesk.cn/im_client/?web_plugin_id=29181)
+- 工作时间 8:30-22:00
+
+- [公安备案号11010502030143](http://www.beian.gov.cn/portal/registerSystemInfo?recordcode=11010502030143)
+- [京ICP备19004658号](http://beian.miit.gov.cn/publish/query/indexFirst.action)
+- [京网文〔2020〕1039-165号](https://csdnimg.cn/release/live_fe/culture_license.png)
+- [经营性网站备案信息](https://csdnimg.cn/cdn/content-toolbar/csdn-ICP.png)
+- [北京互联网违法和不良信息举报中心](http://www.bjjubao.org/)
+- [家长监护](https://download.csdn.net/tutelage/home)
+- [网络110报警服务](https://cyberpolice.mps.gov.cn/)
+- [中国互联网举报中心](http://www.12377.cn/)
+- [Chrome商店下载](https://chrome.google.com/webstore/detail/csdn%E5%BC%80%E5%8F%91%E8%80%85%E5%8A%A9%E6%89%8B/kfkdboecolemdjodhmhmcibjocfopejo?hl=zh-CN)
+- [账号管理规范](https://blog.csdn.net/blogdevteam/article/details/126135357)
+- [版权与免责声明](https://www.csdn.net/company/index.html#statement)
+- [版权申诉](https://blog.csdn.net/blogdevteam/article/details/90369522)
+- [出版物许可证](https://img-home.csdnimg.cn/images/20250103023206.png)
+- [营业执照](https://img-home.csdnimg.cn/images/20250103023201.png)
+- ©1999-2025北京创新乐知网络技术有限公司
+
+[![](https://i-avatar.csdnimg.cn/355cd0deee474cf1ba93a435aae2c294_openHiTLS.jpg!1)](https://openhitls.blog.csdn.net/)
+
+[openHiTLS密码开源社区](https://openhitls.blog.csdn.net/ "openHiTLS密码开源社区")
+
+博客等级 ![](https://csdnimg.cn/identity/blog6.png)
+
+码龄1年
+
+[
+
+189
+
+原创
+
+](https://openhitls.blog.csdn.net/)
+
+3991
+
+点赞
+
+3127
+
+收藏
+
+881
+
+粉丝
+
+关注
+
+[私信](https://im.csdn.net/chat/openHiTLS)
+
+### 更多优质【一键运行】博文
+
+- [1WPS表格在一列里批量导入图片](https://blog.csdn.net/qq_41674785/article/details/134180384)
+- [2NumPy常用30个经典案例](https://blog.csdn.net/m0_75067629/article/details/145543113)
+- [3基于STM32的智能指针仪表盘系统设计与实现](https://blog.csdn.net/weixin_29476595/article/details/153556122)
+- [4chrome浏览器禁用js中的debugger](https://blog.csdn.net/A20190518/article/details/111037945)
+- [5C语言 根据年份数与月份数计算某月天数](https://blog.csdn.net/XD_YinG_Ye/article/details/153514582)
+
+[查看更多![查看更多](https://csdnimg.cn/release/blogv2/dist/pc/img/runBlogWhite.png)](https://blog.csdn.net/rank/list/blog_project)
+
+### 热门文章
+
+- [一文搞懂一次性密码：OTP、HOTP、TOTP详解 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 3159](https://openhitls.blog.csdn.net/article/details/151608861)
+- [SM4算法工作模式（ECB、CBC、CFB、OFB、CTR、GCM、CCM 、XTS）：原理、特点与应用 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2737](https://openhitls.blog.csdn.net/article/details/151288800)
+- [无密码认证FIDO2 框架：重构数字世界的信任基石（附代码示例） ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2712](https://openhitls.blog.csdn.net/article/details/150954617)
+- [唯密文攻击（Ciphertext Only）深度技术解析及未来趋势 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2684](https://openhitls.blog.csdn.net/article/details/153332376)
+- [ChaCha20 密码算法：从原理到代码实现的全方位解析【附源码】 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2541](https://openhitls.blog.csdn.net/article/details/151066232)
+
+### 分类专栏
+
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)开源社区动态](https://blog.csdn.net/openhitls/category_12997573.html)25篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)前沿技术动态](https://blog.csdn.net/openhitls/category_12989402.html)56篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)密码学实战](https://blog.csdn.net/openhitls/category_13027034.html)65篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756757.png?x-oss-process=image/resize,m_fixed,h_64,w_64)密码学基础](https://blog.csdn.net/openhitls/category_13034220.html)59篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756930.png?x-oss-process=image/resize,m_fixed,h_64,w_64)密码行业标准](https://blog.csdn.net/openhitls/category_13026355.html)12篇
+
+上一篇：
+
+[SLH-DSA：抗量子时代的 X.509 PKI 数字签名方案](https://blog.csdn.net/openHiTLS/article/details/150487435)
+
+下一篇：
+
+[后量子迁移：Composite ML-DSA复合签名方案解析](https://blog.csdn.net/openHiTLS/article/details/150511107)
+
+### 大家在看
+
+- [Git提交无数量限制](https://blog.csdn.net/zhangchen124/article/details/156199759)
+- [华为云CSBS代理核心作用解析 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 518](https://blog.csdn.net/yunlaoda7/article/details/156153098)
+- [AI大模型工程师学习指南](https://blog.csdn.net/YoungOne2333/article/details/156199286)
+- [爬虫入门：从零解析代码 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 546](https://blog.csdn.net/2401_88591507/article/details/156050630)
+- [CSS核心概念详解](https://blog.csdn.net/2511_94359082/article/details/156195300)
+
+### 最新文章
+
+- [成长故事 | 华中科技大学金轩宇：从CTF走进开源世界，我的开源探索之旅](https://openhitls.blog.csdn.net/article/details/156070157)
+- [成长故事 | 西安电子科技大学杨文杰：从密码套件的调用者成长为开源社区的贡献者](https://openhitls.blog.csdn.net/article/details/155803890)
+- [任正非最新讲话！1.4万字全文，信息量很大（任正非与ICPC主席、教练及获奖选手座谈会纪要）](https://openhitls.blog.csdn.net/article/details/155735120)
+
+2025
+
+[12月6篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=12)
+
+[11月7篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=11)
+
+[10月50篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=10)
+
+[09月55篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=09)
+
+[08月62篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=08)
+
+[07月6篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=07)
+
+[06月4篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=06)
+
+### 目录
+
+1. [国密改造的核心诉求：](https://blog.csdn.net/openHiTLS/article/details/150497042#t0)
+2. [nginx-with-openHiTLS：技术特性解析](https://blog.csdn.net/openHiTLS/article/details/150497042#t1)
+3. [部署指南：从编译到运行的全流程](https://blog.csdn.net/openHiTLS/article/details/150497042#t2)
+4. 1. [1. 环境准备](https://blog.csdn.net/openHiTLS/article/details/150497042#t3)
+    2. [2. 编译 openHiTLS 密码库](https://blog.csdn.net/openHiTLS/article/details/150497042#t4)
+    3. [3. 编译并安装 nginx-with-openHiTLS](https://blog.csdn.net/openHiTLS/article/details/150497042#t5)
+    4. [4. 国密协议配置示例](https://blog.csdn.net/openHiTLS/article/details/150497042#t6)
+    5. [5. 启动与验证](https://blog.csdn.net/openHiTLS/article/details/150497042#t7)
+5. [关键注意事项与故障排除](https://blog.csdn.net/openHiTLS/article/details/150497042#t8)
+6. [开源实践：nginx-with-openHiTLS开源代码实现](https://blog.csdn.net/openHiTLS/article/details/150497042#t9)
+
+收起 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/arrowup-line-top-White.png)
+
+[![](https://i-operation.csdnimg.cn/images/df6c67fa661c48eba86beaeb64350df0.gif)](https://mall.csdn.net/vip?utm_source=25618_vip_blogrighticon)[![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/Group.png)](https://ai.csdn.net/chat?utm_source=cknow_pc_blogdetail&spm=1001.2101.3001.10583)![](https://g.csdnimg.cn/side-toolbar/3.6/images/mobile.png)![](https://g.csdnimg.cn/side-toolbar/3.6/images/customer.png)![](https://g.csdnimg.cn/side-toolbar/3.6/images/totop.png)
@@ -0,0 +1,36 @@
+tls_ctx_init(&ctx, TLS_protocol_tlcp, TLS_server_mode)
+tls_ctx_set_cipher_suites(&ctx, server_ciphers, sizeof(server_ciphers)/sizeof(int))
+tls_ctx_set_tlcp_server_certificate_and_keys(&ctx, certfile, signkeyfile, signpass, enckeyfile, encpass)
+	tls_ctx_set_ca_certificates(&ctx, cacertfile, TLS_DEFAULT_VERIFY_DEPTH)
+
+bind
+accept
+
+tls_init(&conn, &ctx)
+tls_set_socket(&conn, conn_sock)
+tls_do_handshake(&conn)
+tls_recv
+tls_send
+tls_socket_close
+
+
+
+
+tls_ctx_init
+tls_ctx_set_cipher_suites
+
+
+
+
+
+
+
+
+
+
+{ERR_REASON(SSL_R_DECRYPTION_FAILED), "decryption failed"},  
+{ERR_REASON(SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC),  
+ "decryption failed or bad record mac"},
+
+
+SSL_read /  / ssl3_get_record
@@ -0,0 +1 @@
+![[4c7c04b4a5b75a31c9e5a5054560bef2.png]]
@@ -0,0 +1,180 @@
+个人博客：www.fuzoupyy.work
+
+前两天有个刚做网络的小兄弟问我：“现在不都流行SSL VPN或者[WireGuard](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=WireGuard&zhida_source=entity)了吗？[IPsec](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=IPsec&zhida_source=entity)这种‘老古董’是不是没必要学了？”
+
+我当时差点一口老血喷屏幕上。
+
+兄弟，你这就好比在说，现在开自动挡的车多了，手动挡的原理就不重要了？IPsec这玩意儿，就像是网络世界的“重型装甲车”，它是笨重，配置是繁琐，但在Site-to-Site（站点对站点）的连接上，它依然是无可撼动的霸主。你看看现在的公有云，AWS也好，阿里云也罢，跟IDC做专线互联备份的时候，哪个推荐的不是IPsec？
+
+别看WireGuard现在火得一塌糊涂，真到了复杂的企业级环境，还得是IPsec坐镇。
+
+今天咱们就来扒一扒IPsec的底裤，顺便教大家用开源神器[StrongSwan](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=StrongSwan&zhida_source=entity)搭建一套企业级的VPN。
+
+### **为什么IPsec让人头大？**
+
+咱们先不谈配置，先聊聊为什么这玩意儿难懂。
+
+绝大多数人晕菜，是因为被IKE、[ISAKMP](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=ISAKMP&zhida_source=entity)、[ESP](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=ESP&zhida_source=entity)、[AH](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=AH&zhida_source=entity)、Phase 1、Phase 2这些缩写给绕晕了。
+
+其实，你把IPsec想象成**“押镖”**。
+
+你要把一车黄金（数据包）从北京运到上海。路上有土匪（黑客），你不能直接运。
+
+**第一种方式：AH（Authentication Header）** 这就像是在车厢上贴了个封条，上面盖了皇帝的印（签名）。到了上海，一看封条没坏，就知道东西没被换过，也是朝廷发出来的。 **但是！** 封条只能保证东西没被换，**它不加密**。黄金还是黄金，土匪在路边能看个精光。而且，最坑爹的是，AH会对整个IP头做签名。大家都知道现在网络到处都是NAT（地址转换），路由器一改IP地址，签名就这就对不上了，封条就“碎”了。所以，**在现在的网络环境里，AH基本就是个废柴，很少用。**
+
+**第二种方式：ESP（Encapsulating Security Payload）** 这个厉害了。它不仅贴封条，还把黄金装进了保险箱（加密）。土匪截了车，只能看到一个铁箱子，里面是啥完全不知道。 ESP最骚的操作是“隧道模式”。它不光把数据加密，它还把原来的车牌（原IP头）也给拆下来扔进保险箱，然后在外面挂个新车牌（新IP头）。这就是为什么我们在隧道里抓包，只能看到两个网关之间的公网IP在通信，完全看不到内网IP。
+
+### **那个让人抓狂的协商过程：IKE**
+
+真正让人掉头发的，是IKE（Internet Key Exchange）。
+
+你想啊，两个网关（路由器或服务器）素不相识，怎么建立信任？怎么商量用什么密码？直接在公网上喊：“喂！密码是123456！”那不找死吗？
+
+所以得谈判。这个谈判过程就是IKE。
+
+**第一阶段（Phase 1）：建立管理连接** 这就像两个外交官见面，先得在一个绝对安全的屋子里坐下来。 他们要确认对方身份（Pre-Shared Key预共享密钥，或者证书），然后商量：“咱俩待会怎么聊天？用什么加密算法？” 这一步要是通了，就建立了一个叫**ISAKMP SA**的东西。你可以理解为，外交官的保密电话接通了。
+
+这里有个大坑。Phase 1有两种模式：**主模式（Main Mode）**和**野蛮模式（Aggressive Mode）**。 名字听着挺唬人。主模式慢，一来一回6个包，但是安全，它会隐藏身份信息。野蛮模式快，3个包搞定，但是它会把身份ID明文广播出去。 以前为了快，很多老设备喜欢用野蛮模式，现在为了安全，大家基本都切回主模式了。
+
+**第二阶段（Phase 2）：建立数据连接** 外交官电话通了（Phase 1成功），现在开始聊正事：怎么运黄金。 这时候商量的才是真正用来加密用户数据的密钥（IPsec SA）。 这就是所谓的“快速模式”（Quick Mode）。
+
+这也是为什么你看日志的时候，经常看到Phase 1过了，Phase 2报错。通常是因为两边的“感兴趣流”（Subnet，也就是你要通的内网网段）没对上。左边说我要通192.168.1.0/24，右边配置写的是192.168.2.0/24，聊不到一块去，崩了。
+
+### **[NAT-T](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=NAT-T&zhida_source=entity)：穿越NAT的救命稻草**
+
+刚才说了，AH过不了NAT。其实ESP过NAT也费劲。 因为NAT路由器会修改端口号，而IPsec设计之初是基于IP层的，没端口号这概念（ESP协议号是50）。
+
+为了解决这个问题，聪明的工程师搞了个**NAT-T（NAT Traversal）**。 简单说，就是把ESP数据包再包一层UDP头部，通常是用UDP 4500端口。这样NAT路由器一看：“哦，是UDP啊，改端口我会！” 于是，IPsec就能在NAT环境里活下来了。
+
+**敲黑板：** 如果你的VPN服务器在防火墙后面，记得防火墙除了开**UDP 500**（IKE协商用），还得开**UDP 4500**（NAT穿透用）。好多人配半天不通，就是因为4500端口没开。
+
+  
+
+---
+
+  
+
+### **实战：用StrongSwan搭建从阿里云到本地IDC的隧道**
+
+理论扯多了容易困，咱们来点实操。 Linux下做IPsec，以前有Openswan、Libreswan，但现在**StrongSwan**是绝对的一哥。它对IKEv2的支持最好，配置也相对“阳间”一点（虽然也没好到哪去）。
+
+假设场景：
+
+- **阿里云（左边 Left）：**  
+    
+
+- 公网IP：1.1.1.1
+- 内网段：172.16.0.0/16
+
+  
+
+- **本地IDC（右边 Right）：**  
+    
+
+- 公网IP：2.2.2.2
+- 内网段：192.168.10.0/24
+
+  
+
+系统咱们就用[CentOS 7](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=CentOS+7&zhida_source=entity)或者[Ubuntu 20.04](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=Ubuntu+20.04&zhida_source=entity)，都差不多。
+
+**1. 安装StrongSwan** 这就不用我教了吧？ `yum install strongswan` 或者 `apt install strongswan`。
+
+**2. 开启内核转发（这点最容易忘！）** 很多人配好了VPN，发现ping不通内网，查了一圈发现是Linux没开启路由转发。 编辑 `/etc/sysctl.conf`：
+
+```bash
+net.ipv4.ip_forward = 1
+# 如果有IPv6也顺手开了
+net.ipv6.conf.all.forwarding = 1
+```
+
+执行 `sysctl -p` 生效。
+
+**3. 配置 ipsec.conf** 这是核心配置文件。虽然StrongSwan出了新的 `swanctl.conf` 格式，但为了照顾老玩家的习惯，咱们还是用经典的 `ipsec.conf`。
+
+阿里云那台机器（1.1.1.1）的配置 `/etc/strongswan/ipsec.conf`：
+
+```bash
+config setup
+    # 开启调试日志，排错的时候很有用，平时可以关了
+    charondebug="ike 2, knl 2, cfg 2"
+    uniqueids=no
+
+conn ali-to-idc
+    authby=secret       # 使用预共享密钥认证
+    auto=start          # 服务启动时自动连接
+    type=tunnel         # 隧道模式
+    keyexchange=ikev2   # 强烈建议用IKEv2，比v1快且稳
+    
+    # 左边（本机/阿里云）配置
+    left=1.1.1.1        # 本机公网IP
+    leftid=1.1.1.1      # 标识ID，通常和IP一样
+    leftsubnet=172.16.0.0/16  # 本机要暴露给对端的内网段
+    
+    # 右边（远端/IDC）配置
+    right=2.2.2.2
+    rightid=2.2.2.2
+    rightsubnet=192.168.10.0/24
+    
+    # 加密算法（这个得两边商量好，必须一模一样！）
+    ike=aes256-sha256-modp1024!
+    esp=aes256-sha256!
+    
+    # 存活检测
+    dpddelay=30s
+    dpdtimeout=120s
+    dpdaction=restart
+```
+
+**本地IDC那台机器的配置，基本就是反过来。** 把 `left` 换成 2.2.2.2，`right` 换成 1.1.1.1，subnet也对调一下。
+
+这里有个细节：**`left` 不一定非得写公网IP。** 如果你的服务器是在NAT后面（比如AWS EC2，或者家里路由器后面的虚拟机），`left` 其实应该写内网IP，然后 `leftid` 写公网IP。这块逻辑如果没理顺，StrongSwan根本起不来。
+
+**4. 配置密码 ipsec.secrets** 这个文件简单，就是存密码的。两边得一样。
+
+```bash
+# 格式：IP1 IP2 : PSK "你的超强密码"
+1.1.1.1 2.2.2.2 : PSK "YoyouIsHandsome2025"
+```
+
+记得这个文件权限要设成600，不然StrongSwan会报错说不安全。
+
+**5. 启动与排错** 启动：`systemctl start strongswan` 查看状态：`strongswan statusall`
+
+如果一切顺利，你会看到类似 `Security Associations (1 up, 0 connecting)` 的字样，那就是通了！
+
+### **要是通不了怎么办？（运维的日常崩溃）**
+
+这时候就显出真本事了。 要是状态里显示 `CONNECTING` 然后一直卡着，或者直接 `0 up`，千万别慌。
+
+**第一招：看日志。** `tail -f /var/log/syslog` 或者 `/var/log/messages`。 如果你看到 `NO_PROPOSAL_CHOSEN`，这绝对是两边加密算法没对齐。比如一边配了AES128，另一边是AES256；或者一边是SHA1，另一边是SHA256。仔细检查 `ike=` 和 `esp=` 这两行。
+
+**第二招：检查防火墙。** 再强调一遍，UDP 500 和 UDP 4500。 还有，云厂商的安全组！阿里云的安全组入方向开了吗？
+
+**第三招：MSS（最大报文段长度）问题。** 这是个隐形杀手。 VPN加上了ESP头，包变大了。如果原来是1500字节，加上头就超了，会被分片或者丢弃。 现象就是：**ping是通的，但SSH连不上，或者网页打不开。** 这时候需要在防火墙（iptables）里做个手脚，把MSS改小点：
+
+```bash
+iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
+```
+
+或者暴力点，直接设成1300：
+
+```bash
+iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300
+```
+
+这招下去，90%的“怪病”都能好。
+
+### **总结**
+
+说实话，配置IPsec VPN是一件挺枯燥的事，配置文件里哪怕多了一个空格，或者少了一个感叹号，都能让你查半天。
+
+但这就是运维的价值所在啊。 当那条隧道打通，两边内网的数据像流水一样无缝传输的时候，那种成就感，真的是WireGuard这种“傻瓜式”工具给不了的（虽然我也很爱WireGuard，哈哈）。
+
+而且，搞懂了IPsec，你再去看SD-WAN，看云专线，其实底层逻辑都是通的。
+
+我知道这篇内容有点硬，可能大家得消化一会儿。建议收藏起来，下次被VPN折磨的时候，拿出来对一对配置，说不定就救了你的命。
+
+技术这东西，没有什么捷径，就是一遍遍试错试出来的。
+
+如果你在配置过程中遇到了奇葩的报错，或者对加密算法的选择有疑问，欢迎在评论区留言，咱一起探讨探讨。
@@ -0,0 +1,12 @@
+![[Pasted image 20251204155744.png]]
+
+
+![[73ed7d2b9783ef80009955aaae11eea7.png]]
+
+
+![[64c875d94cda00b1e27f782f87c80945.png]]
+
+
+
+
+