//f1
interface Tunnel1
 ip address 172.16.2.1 255.255.255.0
 tunnel-protocol gre
 source 1.1.1.1//源目隧道地址是公网地址
 destination 5.5.5.5
 gre key cipher 123456
//f2
interface Tunnel1
 ip address 172.16.2.2 255.255.255.0
 tunnel-protocol gre
 source 5.5.5.5//源目隧道地址是公网地址
 destination 1.1.1.1
 gre key cipher 123456

为了提高GRE的安全性，隧道双方支持对对端设备的身份验证。建立隧道的双方事先约定好一个密钥，在传输GRE报文的时候，该密钥信息会被封装到GRE头中，接收端在收到GRE报文时会用自己的密钥和报文中的密钥进行比对。密钥一致则验证通过；密钥不一致，则表示对方身份不合法，丢弃此报文。

5.2 将tunnel接口加入安全区域dmz

firewall zone dmz
 add interface Tunnel1

5.3 配置到达对端私网的路由走tunne隧道

//f1
ip route-static 10.1.2.0 24 Tunnel 1
//f2
ip route-static 10.1.1.0 24 Tunnel 1

5.4 配置f1和f2之间公网静态路由，保证公网接口可达（很重要，否则看不到路由表中的隧道路由，官方文档中没有提及这个）

//f1
ip route-static 5.5.5.5 255.255.255.255 1.1.1.2
//f2
ip route-static 1.1.1.1 255.255.255.255 5.5.5.2
//r1
本环境中r1始终没有配置静态路由，实际组网中，只需要保证fw1和fw2的公网接口地址可达即可，本环境中因为和fw1和fw2是直连，所以不需要配置。

?6、配置安全区域


//f1f2
security-policy
 rule name 1
//配置Trust域和DMZ的域间安全策略，允许封装前的报文通过域间安全策略。
  source-zone dmz
  source-zone trust
  destination-zone dmz
  destination-zone trust
  action permit
 rule name 2
//配置Local和Untrust的域间安全策略，允许封装后的GRE报文通过域间安全策略。
  source-zone local
  source-zone untrust
  destination-zone local
  destination-zone untrust
  service gre
  action permit

从原始报文进入GRE隧道开始，到GRE报文被FW转出，这个过程报文跨越了两个域间关系（trust---dmz，local--untrust）。由此可以将GRE报文所经过的安全域看成两个部分，一个是原始报文进入GRE隧道前所经过的安全域，一个是报文经过GRE封装后经过的安全域。注意我们配置了Tunnel接口属于DMZ区域。

PC_A发出的原始报文进入Tunnel接口这个过程中，报文经过的安全域间是Trust—>DMZ；原始报文被GRE封装后，FW_A在转发这个报文时，报文经过的安全域间是Local—>Untrust。匹配安全策略1.

当FW_A发出的GRE报文到达FW_B时，FW_B会进行解封装。在此过程中，报文经过的安全域间是Untrust—>Local；GRE报文被解封装后，FW_B在转发原始报文时，报文经过的安全域间是DMZ—>Trust。匹配安全策略2.

这是单向通道，只能放行从PCA到PCB的流量，如果PCB主动发起连接，产生流量，则还需要配置反向策略。所以我们的配置是双向放行。实际网络中，可以根据需要选择是否配置双向通道。

验证和分析

1、使用pc1 ping pc2

2、检查fw1的路由表

[f1]dis ip routing-table 
2022-03-01 07:46:08.080 
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 10       Routes : 10       

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

        1.1.1.0/24  Direct  0    0           D   1.1.1.1         GigabitEthernet
1/0/1
        1.1.1.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet
1/0/1
        5.5.5.5/32  Static  60   0          RD   1.1.1.2         GigabitEthernet
1/0/1
       10.1.1.0/24  Direct  0    0           D   10.1.1.1        GigabitEthernet
1/0/0
       10.1.1.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet
1/0/0
       10.1.2.0/24  Static  60   0           D   172.16.2.1      Tunnel1
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0           D   127.0.0.1       InLoopBack0
     172.16.2.0/24  Direct  0    0           D   172.16.2.1      Tunnel1
     172.16.2.1/32  Direct  0    0           D   127.0.0.1       Tunnel1

可以看到有3条路由的接口指向了tunnel接口，一条是我们配置的静态路由，10.1.2.0/24，其下一跳是172.16.2.1，这是隧道地址，另外两条是tunnel接口所在网络的地址。需要将fw1和fw2的隧道地址配置在一个网段内。

3、在fw1上使用ping -a 172.16.2.1 172.16.2.2?

[f1]ping -a 172.16.2.1 172.16.2.2
  PING 172.16.2.2: 56  data bytes, press CTRL_C to break
    Request time out
    Request time out
    Request time out
    Request time out
    Request time out

  --- 172.16.2.2 ping statistics ---
    5 packet(s) transmitted
    0 packet(s) received
    100.00% packet loss

即使将fw1和fw2的安全策略设置为全通都是无法ping通的。

4、在r1上进行抓包，检查报文情况

可以看到gre报头在实际的ip头之上，并且在gre外又封装一层ip头，这个ip头的源目地址是fw的公网地址。

GRE报文头中的flags字段的Key标识位置1，表示启用了身份验证功能，为0表示未启用身份验证功能，FW中GRE缺省未开启此功能。

5、检查tunnel隧道

<f1>dis interface Tunnel 1
2022-03-03 04:00:48.000 
Tunnel1 current state : UP
Line protocol current state : UP
Last line protocol up time : 2022-03-03 03:51:09
Description:Huawei, USG6000V1-ENSP Series, Tunnel1 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 172.16.2.1/24
Encapsulation is TUNNEL, loopback not set
Tunnel source 1.1.1.1 (GigabitEthernet1/0/1), destination 5.5.5.5
Tunnel protocol/transport GRE/IP, key enabled
keepalive disabled
Checksumming of packets disabled
Current system time: 2022-03-03 04:00:48
    300 seconds input rate 0 bits/sec, 0 packets/sec
    300 seconds output rate 0 bits/sec, 0 packets/sec
    13 seconds input rate 0 bits/sec, 0 packets/sec
    13 seconds output rate 0 bits/sec, 0 packets/sec
    7 packets input,  616 bytes
    0 input error
    10 packets output,  792 bytes
    1 output error
    Input:
      Unicast: 7 packets, Multicast: 0 packets
    Output:
      Unicast: 10 packets, Multicast: 0 packets
    Input bandwidth utilization  : --
    Output bandwidth utilization : --

6、检查fw的session table

[f1]dis fire session table
2022-03-01 08:23:05.790 
 Current Total Sessions : 19
 icmp  VPN: public --> public  10.1.1.100:17719 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:20279 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:20535 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:18999 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:18743 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:18231 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:17975 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:18487 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:17463 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:16183 --> 10.1.2.100:2048
 gre  VPN: public --> public  5.5.5.5:0 --> 1.1.1.1:0
 icmp  VPN: public --> public  10.1.1.100:16695 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:21047 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:17207 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:19767 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:19511 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:20791 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:19255 --> 10.1.2.100:2048
 icmp  VPN: public --> public  10.1.1.100:16951 --> 10.1.2.100:2048

总结一下gre的转发流程

PC_A通过GRE隧道访问PC_B时，FW_A和FW_B上的报文转发过程如下：

PC_A访问PC_B的原始报文进入FW_A后，首先匹配路由表。
根据路由查找结果，FW_A将报文送到Tunnel接口进行GRE封装，增加GRE头，外层加新IP头。
```
10.1.2.0/24 ?Static ?60 ? 0 ? ? ? ? ? D ? 172.16.2.1 ? ? ?Tunnel1
```
FW_A根据GRE封装后报文的新IP头的目的地址（5.5.5.5），再次查找路由表。
```
 5.5.5.5/32  Static  60   0          RD   1.1.1.2         GigabitEthernet1/0/1
```
FW_A根据路由查找结果经R1中转将报文发送至FW_B.
FW_B收到报文后，首先判断这个报文是不是GRE报文。
如何判断？抓包可以看到封装后的GRE报文会有个新的IP头，这个新的IP头中有个Protocol字段，字段中标识了内层协议类型，如果这个Protocol字段值是47，就表示这个报文是GRE报文。如果是GRE报文，FW_B则将该报文送到Tunnel接口解封装，去掉新的IP头、GRE头，恢复为原始报文；如果不是，则报文按照普通报文进行处理。
FW_B根据原始报文的目的地址再次查找路由表，然后根据路由匹配结果将报文发送至PC_B。

进阶：隧道保活机制

缺省情况下，未启用GRE的Keepalive功能。
GRE的Keepalive功能是单向的，对端是否支持或启用Keepalive功能不影响本端的Keepalive功能。但建议在GRE隧道两端都启用Keepalive功能。
period表示本端发送keeplive报文的时间间隔。默认5s。如果本端发送retry-times次keeplive报文后，对端仍没有回应，则认为对端不可达。
启用GRE的Keepalive功能后，GRE隧道的本端会周期性的向对端发送keepalive报文，以检测GRE隧道的状态。如果GRE隧道对端不可达，本端的Tunnel接口状态会被置为Down。这就避免了因对端不可达而造成的数据黑洞。

我们给fw2的tunnel1配置了keepalive，从而周期性发gre keepalive报文。可以看到一个bug，wireshark显示源目地址是1.1.1.1----5.5.5.5，打开一看发现还是5.5.5.5---1.1.1.1。通过报文分析我们知道gre 保活报文实际上还是gre报文的一种，他在上层的ip头部的protocol封装还是47，在gre报文头中，falgs字段的key标识置位仍有效，即对保活报文还是可以认证的。

接着往下看

包裹的ip报文（第二层ip）的源目地址还是隧道绑定的公网地址，这是和普通gre报文不一样的地方，实际上也很好理解，即我们做保活本来也是对于隧道的保活，并没有什么私网地址的概念在里面。这一层ip头中仍然在protocol字段标了47，表示下层是gre报文。在下层的gre报文中，protocol type字段标注0x0000.表示这是一个保活字段，而对于正常的gre报文，他的该字段会写0x0800，这表示下层是ip字段，实际上在mac层，也有类似的字段type，如果下层是ip层，一样也是0x0800.

看看fw1给fw2的保活响应回包。