分析xfrm中在网关-网关应用模式下为何不能配置成transport+tunnel模式

分析xfrm中在网关-网关应用模式下为何不能配置成transport+tunnel模式

author: cyliu

1 为何Linux中不能配置出局域网到局域网的transport+tunnel模式
    
linux内核vpn中策略到SA的配置过程是这样的：
    
一数据包,其源地址/目的地址分别为packet_s,packet_d。在packet_s,packet_d匹配到了vpn策略后，开始查找关联的SA。
        
现在解释一下SP和SA：
        
策略中有一成员tmp,保留了需要关联的SA的部分信息，也就是说通过该tmp关联起SP和SA。如果tmp是transport,则使用数据报packet_s,packet_d作为查找SA的hash参数;如果tmp是tunnel，则使用tmp内部的tmp_s,tmp_d作为查找SA的Hash参数。
        
这里tmp还有一个特点：多个tmp（就是vpn嵌套方式）时，后面的tmp如果是transform需要继承前面的tmp的源地址/目标地址。默认transform的tmp源地址/目标地址为0。
        
SA中也有源地址/目的地址(SA_s,SA_d),并且使用这两个地址计算hash然后插入到表中。
        
注意：计算hash这里有连个地点了：一个是SA创建时，根据SA_s,SA_d作为参数插入到表中；另一个是流程中SP通过tmp查找SA时，使用数据报packet_s,packet_d(transform)或者tmp中的tmp_s,tmp_d作为参数计算hash来查找SA。
        
一旦SA_s,SA_d和最后查找SA时使用的源地址/目的地址不同，那么计算出来的hash就是不同，从而也就找不到SA了。
        
这样transprot+tunnel对于两端时subnet方式就无法配出，当然针对主机还是可以配出来的。
    
2 有没有好的解决办法呢？
    
应该可以通过下面方式解决：

2.1 修改ike，对传输模式的源地址和目的地址也从配置中读取，而不采用默认为零的条件。当然，这里处理不是这么简单，需要好多特别的注意。这不过是个思路。
        
2.2 修改内核，把查找过程对于传输模式使用数据报地址修改tmp中地址来查找SA。
        
通过这个修改可以解决上面问题。
        
3 缺点
    
3.1 违反了传输模式的rfc定义。因为传输模式就是针对主机间使用的，如果修改了就违反了定义。
    
3.2 没有必要。因为transport+tunnel 和 tunnel + tranport方式对最后数据报基本达到了相同的效果，而且也符合规范。
    
所以，这里说了这么多，仅是作为技术上的探讨。