IPSEC 004 ---- 模板海纳百川，不定对端有容乃大

小咪咪 2024-04-19 11:02 26阅读 0赞

# IPSec模板海纳百川 #

自从天地会采用了IKE方式协商IPSec安全策略，IPSec配置和维护的工作量大减。然而之前天地会用过的手工方式IPSec安全策略或IKE方式IPSec安全策略都要求IPSec对端的IP固定。可是在公网IP几近枯竭的Internet上要拥有一个固定的公网IP谈何容易！天地会每次要申请一个固定公网IP地址都要大费周折。于是天地会提出疑问：配置IPSec VPN的通信双方必须使用固定的公网IP地址吗？  
当然不是。下面强叔就给大家介绍一种新的IPSec安全策略：模板方式IPSec安全策略。

跟IKE方式IPSec安全策略一样，模板方式IPSec安全策略也要依靠IKE协商IPSec隧道。模板方式IPSec安全策略最大的改进就是不要求对端IP地址固定：**可以严格指定对端IP地址（单个IP），可以宽泛指定对端IP地址（IP地址段）也可以干脆不指定对端IP（意味着对端IP可以是任意IP）。**  
模板方式IPSec安全策略就好像一员猛将，根本不把对端IP放在眼里，什么固定IP、动态地址、私网IP统统不在话下。只管放马过来，来多少都照单全收。正因为这种大将风范，模板方式IPSec安全策略特别适用于天地会总舵，用于响应众多分舵的协商请求。且分舵数量越多越明显：

*  采用IKE方式IPSec策略。总舵需要配置N个IPSec策略，N个IKE对等体。N=分舵数量
 *  采用模板方式IPSec策略。总舵需要配置1个IPSec策略，一个IKE对等体。与N的取值无关。

总之，模板方式IPSec安全策略的两大优点令他在IPSec阵营中始终保持明星地位：

*  对对端要求甚少，有固定IP或者没有无所谓
 *   配置简单，只要配置一个IKE Peer即可

但明星也是有缺点的，这个缺点也可以说是模板方式IPSec安全策略“不拘小节”的地方：**模板方式IPSec安全策略只能响应对端发起的协商请求，不能主动发起协商。**  
至此强叔已经介绍了三种IPSec安全策略：手工方式IPSec安全策略、IKE方式IPSec安全策略、模板方式IPSec安全策略。**这三种IPSec安全策略都可以配置在一个IPSec安全策略组中。**所谓IPSec安全策略组就是一组名称相同的IPSec安全策略。在一个IPSec安全策略组中最多只能存在一个模板方式IPSec安全策略，且其序号必须最大，即优先级最小。否则接入请求被模板接收了，优先级低的IKE方式IPSec策略则无法施展。切记！

# 分舵接入IP变，模板接收只等闲 #

总舵跟分舵1和分舵2之间建立IPSec 隧道的组网图如下所示。本图中分舵1和分舵2的出接口采用动态方式获取公网IP地址。要求在分舵1跟总舵、分舵2跟总舵之间建立IPSec隧道，分舵1跟分舵2之间也可以通过IPSec通信。  
 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70][]

模板方式IPSec安全策略配置流程如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1][]

分舵2的配置与分舵1类似，请参考分舵1的配置。IKE安全提议和IPSec安全提议采用缺省配置（每个版本的缺省配置可能不同，请配置时注意）。

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置项</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>天地会总舵（采用模板方式IPSec</strong><strong>策略）</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>天地会分舵1</strong><strong>（采用IKE</strong><strong>方式IPSec</strong><strong>策略）</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置IKE</strong><strong>安全提议</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike proposal 10</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike proposal 10</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置IKE</strong><strong>对等体</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;ike-proposal 10</strong></p> <p><strong>pre-shared-key tiandihui1</strong></p> <p><strong><em>//</em><em>可以不配置remote-address</em><em>，也可以通过remote-address</em><em>指定IP</em><em>地址段。</em></strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;ike-proposal 10</strong></p> <p><strong>remote-address 1.1.1.1</strong></p> <p><strong>&nbsp;pre-shared-key tiandihui1</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>ACL</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>acl number 3000</strong></p> <p><strong>rule 5 permit ip destination 172.16.1.0 0.0.0.255</strong></p> <p><strong>rule 10 permit ip destination 172.16.2.0 0.0.0.255</strong></p> <p><strong><em>//</em><em>配置一条ACL</em><em>：</em></strong></p> <p><strong><em>rule5</em><em>允许分舵2</em><em>和总舵访问分舵1</em><em>，source</em><em>必须包括分舵2</em><em>和总舵，destination</em><em>为分舵1</em><em>。本例中不指定source</em><em>，表明source</em><em>可以为分舵2</em><em>也可以为总舵或其他IP</em><em>地址段。</em></strong></p> <p><strong><em>rule10</em><em>允许分舵1</em><em>和总舵访问分舵2</em><em>，source</em><em>必须包括分舵1</em><em>和总舵，destination</em><em>为分舵2</em><em>。本例中不指定source</em><em>，表明source</em><em>可以为分舵1</em><em>也可以为总舵或其他IP</em><em>地址段。</em></strong></p> <p>&nbsp;</p> </td> 
   <td style="vertical-align:top;"> <p><strong>acl number 3000</strong></p> <p><strong>rule 5 permit ip source 172.16.1.0 0.0.0.255</strong><em>&nbsp;<strong>//</strong></em><strong><em>允许分舵1</em><em>访问分舵2</em><em>和总舵，source</em><em>为分舵1</em><em>，destination</em><em>为分舵2</em><em>和总舵。本例中不指定destination</em><em>，表明source</em><em>可以为分舵2</em><em>也可以为总舵或其他IP</em><em>地址段。</em></strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>IPSec</strong><strong>安全提议</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ipsec proposal a</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ipsec proposal a</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>IPSec</strong><strong>安全策略</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ipsec policy-template tem1 1&nbsp;<em>//</em><em>配置IPSec</em><em>策略模板</em></strong></p> <p><strong>&nbsp;security acl 3000</strong></p> <p><strong>&nbsp;proposal a</strong></p> <p><strong>&nbsp;ike-peer a</strong></p> <p><strong>ipsec policy policy1 12 isakmp template tem1<em>//</em><em>配置模板方式IPSec</em><em>策略</em></strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ipsec policy policy1 1 isakmp</strong></p> <p>&nbsp;<strong>security acl 3000</strong></p> <p><strong>&nbsp;proposal a</strong></p> <p><strong>&nbsp;ike-peer a</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>应用IPSec</strong><strong>安全策略</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>interface GigabitEthernet0/0/1</strong></p> <p><strong>ip address 1.1.1.1 255.255.255.0</strong></p> <p><strong>ipsec policy policy1</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>interface GigabitEthernet0/0/1</strong></p> <p><strong>ip address 2.2.2.2 255.255.255.0</strong></p> <p><strong>ipsec policy policy1&nbsp;auto-neg<em>//</em><em>配置auto-neg</em><em>后，不需要流量触发就直接建立IPSec</em><em>隧道</em>。</strong></p> </td> 
  </tr> 
 </tbody> 
</table>

部署完成后进行验证：  
1. 在总舵IPSec网关上可以查看到总舵跟分舵1和分舵2都正常建立了第一阶段和第二阶段安全联盟。  
2. 分舵1、分舵2、总舵可以互相通信。  
问题：若在接口上应用IPSec策略时不配置auto-neg参数，分舵1跟分舵2可以直接通信吗？  
1. 在分舵1和分舵2的网关取消接口上应用的IPSec策略后，重新应用时不配置auto-neg参数。由分舵1的PC2 ping分舵2的PC3，无法ping通。  
2. 查看分舵1上安全联盟的建立情况。  
<FW\_B> display ike sa  
current ike sa number: 2  
\---------------------------------------------------------------------  
conn-id    peer                    flag          phase vpn  
\---------------------------------------------------------------------  
40022      1.1.1.1                RD|ST         v2:2  public  
7           1.1.1.1                RD|ST         v2:1  public  
分舵1跟总舵之间的安全联盟正常建立。  
3. 查看分舵2上安全联盟的建立情况。  
<FW\_C> display ike sa  
current sa Num :0  
**分舵2跟总部之间没有建立安全联盟。原因在于总部配置了模板方式IPSec安全策略，只能响应协商。所以分舵1到总舵的安全联盟正常创建了，而总舵到分舵2的安全联盟没法建立。****在分舵1跟分舵2上应用IPSec安全策略时带上auto-neg参数后，IPSec安全联盟自动创建**。由于分舵1到总舵、总舵到分舵2之间的安全联盟都已创建好，所以分舵1跟分舵2可以通信。同样总舵可以ping通分舵。  
模板方式IPSec安全策略与IKE方式IPSec安全策略都需要通过IKE来协商IPSec隧道。协商的过程一样，这里强叔就不多说了。本篇重点讲讲模板方式IPSec安全策略的“特色”之处。

# 模板神功露破绽，个性化接入化圆满（仅USG9000系列防火墙支持） #

IPSec模板中只能引用一个IKE Peer。而一个IKE Peer中只能配置一个预共享密钥，因此所有与之对接的对端都必须配置相同的预共享密钥。于是问题来了，只要有一个IPSec网关的预共享密钥泄露，则所有其他网关的IPSec安全都受到威胁。  
那么在总舵跟多个分舵对接的点到多点的组网中，分舵可以配置不同的预共享密钥吗？既然预共享密钥跟密钥生成和身份认证相关，只要把预共享密钥与设备身份挂钩就可以。预共享密钥认证方式下可以采用本地IP地址或设备名称进行身份认证。那通过IP地址来指定预共享密钥或通过设备名称来指定预共享密钥就可以为每个接入对端配置**“个性化的预共享密钥”**了。

*  **在总舵通过对端IP地址为每个分舵指定个性化预共享密钥**

**此方式适用于分舵出口IP地址固定的情况。将总舵在ike peer下面配置的remote-address和pre-shared-key删掉，改为在全局下为每个分舵配置remote-address和pre-shared-key就成，这样既保留模板的先进性，又巧妙规避了模板的局限性。**

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置项</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>天地会总舵</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>天地会分舵（分舵2</strong><strong>的配置跟分舵1</strong><strong>类似）</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置IKE</strong><strong>对等体</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;local-id-type ip</strong></p> <p><strong>ike-proposal 10</strong></p> <p>&nbsp;</p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;local-id-type ip</strong></p> <p><strong>ike-proposal 10</strong></p> <p><strong>remote-address 1.1.1.1</strong></p> <p><strong>&nbsp;pre-shared-key tiandihui1</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置个性化预共享密钥</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike remote-address 2.2.2.2 pre-shared-key tiandihui1</strong></p> <p><strong>ike remote-address 2.2.3.2 pre-shared-key tiandihui2</strong></p> </td> 
   <td style="vertical-align:top;"> <p>-</p> </td> 
  </tr> 
 </tbody> 
</table>

*  **在总舵通过对端设备名称指定预共享密钥**

**当分舵出口没有固定IP地址时，可以通过设备名称来标识身份（ike local-name），此时总舵在全局下为每个分舵配置remote-id和pre-shared-key即可。**

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置项</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>天地会总舵</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>天地会分舵1</strong><strong>（分舵2</strong><strong>的配置跟分舵1</strong><strong>类似）</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置IKE</strong><strong>对等体</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;local-id-type ip</strong></p> <p><strong>ike-proposal 10</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;local-id-type fqdn<em>//</em><em>通过设备名称进行身份认证时本地认证类型需配置为FQDN</em><em>或USER-FQDN</em><em>。</em></strong></p> <p><strong>ike-proposal 10</strong></p> <p><strong>remote-address 1.1.1.1</strong></p> <p><strong>&nbsp;pre-shared-key tiandihui1</strong></p> <p>&nbsp;</p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置本地名称</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>-</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike local-name tdhfd1</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置个性化预共享密钥</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>ike remote-id tdhfd1 pre-shared-key tiandihui1</strong></p> <p><strong>ike remote-id tdhfd1 pre-shared-key tiandihui2</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>-</strong></p> </td> 
  </tr> 
 </tbody> 
</table>

***说明：本地配置的“对端IP”或“对端ID”必须与对端网关上配置的“本地ID”一致。***

# IP变化不打紧，域名映射获真身 #

分舵用动态IP地址接入的情况，IKE方式IPSec安全策略是否真的束手无策呢？  
强叔闭目打坐通过对数通知识的融会贯通、举一反三，也找到了一个可以帮助IKE方式IPSec安全策略解决问题的方法：对端IP地址不固定，当然也就无法配置remote-address，但总部可以通过其他方式间接获知IP地址，比如通过域名。即总部可以用指定remote-domain代替remote-address；分部配置DNS获得域名和IP地址之间的映射关系，开启DDNS保证映射关系能够实时更新。**当然配置动态域名的方式也适用于模板方式IPSec策略。**  
说明：此处仅给出配置差异部分。

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>配置调整</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>总舵</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>分舵</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>IPSec</strong><strong>配置</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>仅IKE Peer</strong><strong>中配置有变化</strong></p> <p><strong>ike peer a</strong></p> <p><strong>&nbsp;ike-proposal 10</strong></p> <p><strong>pre-shared-key tiandihui1</strong></p> <p><strong>remote-domain&nbsp;www.adcd.3322.org</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>无变化</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>新增配置</strong></p> </td> 
   <td style="vertical-align:top;"> <p>&nbsp;</p> </td> 
   <td style="vertical-align:top;"> <p><strong>1</strong><strong>、开启域名解析</strong></p> <p><strong>dns resolve</strong></p> <p><strong>dns server 200.1.1.1</strong></p> <p><strong>2、配置DDNS策略<em>//</em><em>以下配置需联系DDNS</em><em>服务提供商，并根据DDNS</em><em>服务提供商的说明操作。</em></strong></p> <p><strong>ddns policy abc</strong></p> <p><strong>&nbsp;ddns client&nbsp;www.adcd.3322.org</strong></p> <p><strong>&nbsp;ddns server&nbsp;www.3322.org</strong></p> <p><strong>&nbsp;ddns username abc123 password abc123</strong></p> <p><strong>3</strong><strong>、应用DDNS</strong><strong>策略</strong></p> <p><strong>ddns client enable</strong></p> <p><strong>interface dialer 1</strong></p> <p><strong>&nbsp;ddns apply policy abc</strong></p> </td> 
  </tr> 
 </tbody> 
</table>

**此方案的局限在于动态接入方必须有固定域名，另外增加了DNS和DDNS的配置，有点小复杂，所以强叔至今的感受是“不得不用时才会使用”。**  
模板方式IPSec安全策略很强大吧？实际场景中，他并不是孤军作战的，只有模板方式IPSec安全策略和IKE方式IPSec安全策略联合作战才能全线告捷：

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>场景</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>总舵</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>分舵</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>总舵IP</strong><strong>地址固定+</strong><strong>分舵IP</strong><strong>地址固定</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>IKE</strong><strong>方式IPSec</strong><strong>策略或模板方式IPSec</strong><strong>策略</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>IKE</strong><strong>方式IPSec</strong><strong>策略</strong></p> <p>&nbsp;</p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>总舵IP</strong><strong>地址固定+</strong><strong>分舵IP</strong><strong>地址动态获取</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>IKE</strong><strong>方式IPSec</strong><strong>策略（指定对端域名）或模板方式IPSec</strong><strong>策略</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>IKE</strong><strong>方式IPSec</strong><strong>策略</strong></p> </td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;"> <p><strong>总舵IP</strong><strong>地址动态获取+</strong><strong>分舵IP</strong><strong>地址动态获取</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>IKE</strong><strong>方式IPSec</strong><strong>策略（指定对端域名）或模板方式IPSec</strong><strong>策略</strong></p> </td> 
   <td style="vertical-align:top;"> <p><strong>IKE</strong><strong>方式IPSec</strong><strong>策略（指定对端域名）</strong></p> </td> 
  </tr> 
 </tbody> 
</table>

看似通过上面三大方案基本可以完美应对总舵-分舵IPSec VPN的各种场景了，但实际上是江湖之所以为江湖就是因为永远会有点风浪：分舵申请不到公网IP地址，只能配置私网IP地址。怎么办，强叔？强叔之所以为强叔，就是因为真的强大，敬请关注下期的强叔侃墙。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c11ecb53bfdc4fc199c20c4664108467.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/ef590555999d473c80e120831c81c22d.png

发表评论取消回复

表情：

评论列表（有 0 条评论，26人围观）

还没有评论，来说两句吧...

相关阅读

相关 IPSEC 004 ---- 模板海纳百川，不定对端有容乃大

IPSec模板海纳百川自从天地会采用了IKE方式协商IPSec安全策略，IPSec配置和维护的工作量大减。然而之前天地会用过的手工方式IPSec安全策略或IKE方式...

小咪咪/ 2024年04月19日 11:02/ 0 赞/ 27 阅读

相关 [模板] 斯坦纳树

斯坦纳树斯坦纳树解决的是这样的一类问题: 在有边权/点权无向图上找到总权值最小的子图, 使得给定的关键点互相连通. 容易发现得到的子图会是一棵树. //to up

野性酷女/ 2023年08月17日 17:16/ 0 赞/ 104 阅读

相关阿里百川sdk用法 php,阿里百川电商SDK安全图片的使用和踩坑

我觉得阿里百川可以考虑换技术支持了——文档写的太烂了！安全图片本人用的是AndroidStudio 3，首先使用Gradle添加依赖的时候，技术文档说支持到Gradle

分手后的思念是犯贱/ 2023年01月16日 02:55/ 0 赞/ 149 阅读

相关 d时间及hnsec(百纳秒)

[原地址][Link 1] 作者:`Steven Schveighoffer`. `Duration`严格用`hnsecs`.而`MonoTime`存储在实现定义的`钟

￡神魔★判官ぃ/ 2022年10月19日 15:00/ 0 赞/ 314 阅读

相关 GRE over IPsec，IPsec不服，要求IPsec over GRE

上个实验介绍了GRE over IPsec，就是GRE在IPsec之上，在报文封装的时候先封装GRE，再封装IPsec，从报文结构上看起来就是一个IPsec封装的报文，看不到G

傷城~/ 2022年08月31日 00:46/ 0 赞/ 263 阅读

相关川大计算机基础几个学分,川大计算机应用基础第一次作业

《川大计算机应用基础第一次作业》由会员分享，可在线阅读，更多相关《川大计算机应用基础第一次作业(8页珍藏版)》请在人人文库网上搜索。 1、你的得分：完成日期： 2018年12

朱雀/ 2022年08月30日 13:59/ 0 赞/ 144 阅读

相关 ipsec

[ipsec][] 早在2005年，为解决国内办公室访问香港邮件服务器时连接被随机中断而产生大量重复邮件的问题，我们在香港IDC机房的NetScreen防火墙上部署了IP

以你之姓@/ 2022年02月18日 07:46/ 0 赞/ 584 阅读

相关 [无用]LNC李纳川的日常NC操作

NC说他从不CE ![1708004-20190614103003170-1740758225.png][] NC说他想明白了 ![1708004-20190614103

红太狼/ 2021年12月07日 13:17/ 0 赞/ 66 阅读

相关 Django-C004-模板

此文章完成度【100%】留着以后忘记的回顾。多写多练多思考，我会努力写出有意思的demo，如果知识点有错误、误导，欢迎大家在评论处写下你的感想或者纠错。【Dja

梦里梦外;/ 2021年10月23日 10:57/ 0 赞/ 339 阅读

相关安卓阿里百川hotfix集成

首先参考官方文档一步一步配置 \[[http://baichuan.taobao.com/docs/doc.htm?spm=a3c0d.7629140.0.0.7U

痛定思痛。/ 2021年09月26日 03:10/ 0 赞/ 295 阅读