自我总结IPsec隧道和传输模式

即使使用传输模式，在L2L的模型中，Set Peer X.X.X.X的IP地址和原本IP包头中的目的地址不相同的话，也会在外层再添加一个新的IP包头，

这个新的包头就是set peer X.X.X.X为目的地址的包头，源地址用发出接口的地址来发出数据包。等于自动转换成了隧道模式。所以必须要做到原始数据包中的目的IP地址和set peer语句中的ip地址一样才能是传输模式，否则会自动转换为隧道模式

如GRE over IPsec 就可以使用传输模式。而且推荐使用传输模式。因为如果是隧道模式 IPsec将会在原来的最外层ip包头的更外层添加一个以set peer x.x.x.x为目的地址和本身发出接口地址为源地址的数据包，如图所示：

这个是传输模式，配置了set peer 为20.0.0.2 因为匹配最外层IP数据包的地址，所以不在更外层添加新的地址。说一下过程，ping R2 的Loop接口，路由器首先查看路由表，发现下一条是tunnel接口，所以用tunnel接口事先定义的源和目的地址来封装数据包。也就是用10.0.0.1到20.0.0.2来封装数据包，然后送到S0/0物理接口，由于在物理接口上有一个crypto map 路由器查看这个流量是否和crypo map的感兴趣流匹配，（感兴趣流定义 permit gre host 10.0.0.1 host 20.0.0.2）由于与定义的感兴趣流匹配，也就是GRE协议的10.0.0.1到20.0.0.2，所以与set peer对端建立IKE阶段1 2 的协商，由于是传输模式，而且set peer的地址同最外层IP包头的地址相同，所以不进行再次封装。而是直接插入AH头后从物理口送出。

这个是隧道模式，可以看到在最外层的数据包的更外层又添加了一个新的匹配 set peer x.x.x.x的IP包头，浪费了资源

这个是set peer 1.1.1.1 符合IP包目的地址的数据包分析，可以运行在传输模式，要注意让源地址也要符合对方的目的地址才可以建立连接 可以用 crypto map name local-address interface 来定义封装数据包的源端口。

总结：set peer 定义了封装的目的地址。crypto map name local-address interface定义了封装的源地址,(默认是用出接口的地址)。

如果是传输模式那么要求Set peer 的地址和原始的（也就是最内层的）IP数据包的目的地相同，否则自动变为隧道

模式

有一点要注意就是IPSEC也是只处理最外部的IP包头，比如下图的这种情况，如果要指定感兴趣流，只能制定10.0.0.1 到20.0.0.2 的流量，因为是在物理接口上绑定的crypto map

而GRE的封装发生在进入这个物理口之前。所以IPsec不管GRE封装里面的原始地址（1.1.1.1 到 2.2.2.2），他只能加密外层的（10.0.0.1 到 20.0.0.2）

2.0.0.0/32 is subnetted, 1 subnets

S 2.2.2.2 is directly connected, Tunnel0

也就是数据包首先到达tunnel0接口，然后进行GRE封装，添加新的IP包头（如下图所示），然后送到物理口s0/0，这时在s0/0接口上有一个CRYPTO MAP 查看感兴趣流是否触发加密（感兴趣流为ip host 1.1.1.1 host 2.2.2.2），但是由于最外面封装的是10.0.0.1到20.0.0.2的IP包，所以不会触发加密，所以以明文传输。

对于IPsec over GRE来说，举一个失败的例子。

首先定义cry map，设置对等体（set peer）为R2的物理接口地址（20.0.0.2）。设置感兴趣流为1.1.1.1到2.2.2.2。cry map绑定在tun0接口。 传输集为传输模式。设置静态路由为从1.1.1.1 到2.2.2.2 出口为tun0接口 首先发出一个ping包 目的地址为2.2.2.2 源地址为1.1.1.1 这个包先到达tun0接口，由于tunnel0接口上有一个crypto map 所以路由器查看crypto map，发现这个流量和感兴趣流匹配，虽然是传输模式，但是由于set peer 的地址（20.0.0.2）和原本数据包的目的地址（2.2.2.2）不匹配，所以用目的地址20.0.0.2和源地址——送出接口的IP地址，封装原本的数据包。

但是这样封装后，最外层的IP包（10.0.0.1 到 20.0.0.2）就不是经过tunnel0 的数据包了，所以也就不会在触发GRE的封装了。所以数据包从原本的物理接口送出。也就没有实现IPsec over GRE。

但是有一点比较疑惑就是为什么set peer不指定tunnel0的接口地址？原因是发出数据包的源地址为物理接口也就是s0/0的地址。即使指定 cry map zzz local-address tunnel 0系统也是认为是发出的源地址为物理接口地址（tunnel source地址）。但是这仅限于cisco的路由器，如果是别的路由器，tunnel0接口的IP地址（12.12.12.1）为源地址的话。应该是可以完成IPsec over GRE的，因为原始的数据包为1.1.1.1到2.2.2.2 触发了IPsec的感兴趣流，然后IPsec将这个数据包再封装一次，源到目的为12.12.12.1到12.12.12.2，然后送到tunnel出口，tunnel出口由事先定义好的，tunnel source 10.0.0.1 tunnel destination 20.0.0.2 再次封装。我的理解数据包应该是这样的，但是我不确定是不是正确 IP包头 S10.0.0.1 D20.0.0.2 GRE头 IP包头 S 12.12.12.1 D 12.12.12.2 AH 或者 ESP IP包头 S 1.1.1.1 D 2.2.2.2

下面说一个IPsec over GRE 成功的例子，并解释其原理：

还是如图所示

Crypto Map: \

Crypto Map \ Peer = 2.2.2.2

Extended IP access list 100

access-list 100 permit ip host 1.1.1.1 host 2.2.2.2 Current peer: 2.2.2.2

Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ zhang, }

Interfaces using crypto map zzz: Tunnel0

2.0.0.0/32 is subnetted, 1 subnets

S 2.2.2.2 is directly connected, Tunnel0

这是R1 的关键配置。传输集为传输模式。

首先1.1.1.1到2.2.2.2这个数据包到tunnel0接口，由于tunnel0接口上有一个crypto map ，所以系统查看crypto map 的感兴趣流设置，1.1.1.1到2.2.2.2 和一个感兴趣流匹配，所以开始与对等体2.2.2.2建立IKE阶段1的安全链接，又由于是传输模式，set peer 2.2.2.2和原始数据包中目的地址匹配，且发送的源地址为loopback0的地址（和R2 的配置匹配）。所以不对数据包进行再次封装，插入AH的头后从tunnel0口发出，出tunnel0的时候tunnel0口负责对数据包进行再次封装，也就是添加最外层的包头10.0.0.1到20.0.0.2 然后从物理口发出，成功完成了IPsec over GRE。

总结：需要了解数据包封装的先后次序，在那个接口放了crypto map，数据包进入接口的时候就查看是否和IPsec的感兴趣流匹配。IPsec处理完后接口相应的协议再处理，例如绑定在tunnel接口，首先IPsec对数据包进行封装，如过封装后符合从tunnel接口发出的路由，则再用GRE封装，完成IPsec over GRE。 所有的协议如IPsec 和 GRE总是处理最外层的IP包，外层以内的数据包他们不关心。

还有就是要注意发出的源地址是否和对端的set peer匹配，如果不匹配不能完成IKE阶段1或者阶段2的协商。 最后就是要注意ctypto map zzz local-address tunnel 0 的源地址为tunnel完成封装后的物理接口的地址。 最后附一个截图，是IPsce over GRE的隧道模式的截图

GRE只负责封装画红色框的IP包头，而不负责封装最里面的IP包头。同理IPsec也一样

好像说的比较混乱，下面说一下每条命令对包的封装情况：

首先GRE 定义tunnel source x.x.x.x 这个就是GRE封装在最外面的数据包的源地址，然后是定义tunnel destination y.y.y.y 这个是控制GRE封装在最外面的目的地址。如图所示 GRE封装的IP包 S x.x.x.x D y.y.y.y GRE头 原始IP包 S 1.1.1.1 D 2.2.2.2 所有通过tunnel口出去的包都会经过GRE的封装，所以可以在路由协议中宣告tunnel口的IP地址来运行路由协议。 12.0.0.0/24 is subnetted, 1 subnets

C 12.12.12.0 is directly connected, Tunnel0

如果把这个接口宣告进ospf进程则可以运行路由协议。运行后包格式如下图 GRE封装的IP包 S x.x.x.x D y.y.y.y GRE头 原始IP包 S 12.12.12.1 D 224.0.0.5

IPsec中

Crypto map 中的set peer x.x.x.x是最外面的目的地址。Crypto map zzz local-address interface接口地址为源地址来封装数据包 IPsec封装IP包 ESP或 AH S y.y.y.y（Crypto map zzz local-address interface 接口的IP地址为源） D x.x.x.x（set peer x.x.x.x） 原始IP包 S1.1.1.1 D2.2.2.2

IPsec Over GRE

如果在tunnel接口挂上crypto map 那么感兴趣流被触发后会根据transform-set进行封装，封装后的数据会再次查路由表，如果封装后的包（最外层的IP地址）下一跳为tunnel则发送到tunnel口进行GRE封装。数据再次抵达tunnel口后由于与tunnel口crypto map中的感兴趣流不匹配，因此ipsec的crypto map不会再次进行封装，而只是由tunnel口封装GRE后发出。

R1#show crypto isakmp key

Keyring Hostname/Address Preshared Key

default 0.0.0.0 [0.0.0.0 ] cisco R1#

R1#show crypto map

Crypto Map: \

Crypto Map \ Peer = 22.22.22.22

Extended IP access list a

access-list a permit ip host 1.1.1.1 host 2.2.2.2 Current peer: 22.22.22.22

Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ z, }

Interfaces using crypto map zzz: Tunnel0

R1#show ip route

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets

S 2.2.2.2 is directly connected, Tunnel0 21.0.0.0/32 is subnetted, 1 subnets

C 21.21.21.1 is directly connected, Loopback2 22.0.0.0/24 is subnetted, 1 subnets

S 22.22.22.0 is directly connected, Tunnel0 11.0.0.0/24 is subnetted, 1 subnets

C 11.11.11.0 is directly connected, Loopback1

12.0.0.0/24 is subnetted, 1 subnets

C 12.12.12.0 is directly connected, Tunnel0 14.0.0.0/24 is subnetted, 1 subnets

C 14.14.14.0 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 [1/0] via 14.14.14.4

在IPsec Over GRE情况下物理口收到流量的处理方式和从loopback口收到流量的处理方式有所不同。

从loopback接口中收到流量的方式就是我以上说的处理方式，但是从物理口接受流量的处理方式是：当一个包进入后查询路由表发现下一跳从tunnel口发出，数据被送到tunnel口，此时路由器发现tunnel口有一个crypto map，于是进行IPsec封装，封装后不再重新查询路由表，而是直接从tunnel口发出，此时tunnel口会继续进行GRE的封装，此时导致有两层封装。如图所示

虽然目的地址14.14.14.1下一跳不是tunnel口，但是依然会进行GRE的封装，因为没有再次查询路由表，而是依然在tunnel口内再次进行GRE封装。

本文来源：https://www.bwwdw.com/article/0etd.html