IPSec隧道上GRE配置后无法ping通远端主机求助

让我梳理下你的配置和问题，发现几个潜在的关键点，咱们一步步排查：

1. 冗余的IP地址配置（虽不致命但易引发混淆） #

你的/etc/network/interfaces里已经通过address和netmask字段设置了tun0的IP，但后续又重复执行up ip addr add 10.244.251.210/30 dev tun0——这属于重复操作，建议删掉这条冗余命令，简化后的配置如下：

auto tun0
iface tun0 inet static
    address 10.244.251.210
    netmask 255.255.255.252
    pre-up ip tunnel add tun0 mode gre local 10.0.0.1 remote 10.0.0.2 ttl 255
    up ip link set tun0 multicast on
    up ip link set tun0 up

2. IPSec策略未覆盖GRE协议流量（核心嫌疑） #

GRE使用IP协议号47，而你目前仅验证了ICMP的IPSec连通性——如果strongswan配置没有明确允许GRE协议的流量被加密保护，那么GRE包会以明文形式传输，要么被中间网络拦截，要么被远端IPSec设备直接丢弃。

验证方法： #

执行以下命令查看当前IPSec策略：

ip xfrm policy

检查是否存在针对src 10.0.0.1/32 dst 10.0.0.2/32 proto 47（双向，in和out方向）的策略条目。

修复方法： #

修改strongswan配置文件（通常是/etc/ipsec.conf），在对应的conn段落中添加GRE协议允许规则：

conn gre-over-ipsec
    left=10.0.0.1
    right=10.0.0.2
    # 明确允许GRE协议（IP proto 47）
    leftprotoport=47/0
    rightprotoport=47/0
    # 保留你原有的其他配置（ike、esp、authby等）
    auto=start

修改后重启strongswan服务：systemctl restart strongswan

3. 远端GRE配置不对称 #

务必确认远端设备的GRE配置和你的完全对称：

• 远端GRE接口的local地址必须是10.0.0.2，remote地址是10.0.0.1
• 远端IP配置为10.244.251.209/30
• 接口已UP且开启了multicast：ip link set tun0 multicast on

如果远端的GRE隧道配置有误（比如remote地址写错），即使你的配置正确，也无法建立连通。

4. MTU分片问题 #

GRE本身会增加24字节头部，再加上IPSec ESP的额外开销（通常20-30字节），默认的GRE MTU（8977）可能导致数据包超过路径MTU，引发分片丢包。

修复方法： #

调整GRE接口的MTU为更小的值（比如8950），避免分片：
在/etc/network/interfaces中添加mtu 8950：

auto tun0
iface tun0 inet static
    address 10.244.251.210
    netmask 255.255.255.252
    mtu 8950
    pre-up ip tunnel add tun0 mode gre local 10.0.0.1 remote 10.0.0.2 ttl 255
    up ip link set tun0 multicast on
    up ip link set tun0 up

然后重启接口：ifdown tun0 && ifup tun0

可以用禁止分片的ping命令测试：

ping -M do -s 8900 10.244.251.209

如果能ping通，说明MTU调整有效。

5. 抓包确认流量走向 #

如果以上步骤都没解决问题，建议抓包排查：

• 在本地执行：tcpdump -i eth0 host 10.0.0.2 and proto gre，然后ping远端GRE地址，观察是否有GRE数据包发送出去。
• 在远端执行同样的抓包命令，确认是否收到GRE包。

如果本地有发送但远端没收到：检查两端的安全组/防火墙是否真的允许GRE协议（IP proto 47）的双向流量；如果远端收到但没回复：检查远端的IPSec策略和GRE配置是否正确。

内容的提问来源于stack exchange，提问作者ajonat