服务器重启后Strongswan IPSec隧道失效，是否可用AWS VPC peering解决？

首先直接给结论：是的，AWS VPC Peering 完全可以解决你当前遇到的问题，但在直接替换之前，咱们先拆解下问题本质，再对比两种方案的优劣，帮你做最合适的选择。

先搞清楚你的Strongswan隧道为啥重启后失效 #

大概率是以下几个常见问题导致的，先排查下说不定不用换方案：

• Strongswan服务未设置开机自启：重启实例后服务没有自动启动，手动执行systemctl start strongswan试试，要是能通，记得加systemctl enable strongswan设置开机启动
• 隧道端点IP配置失效：如果你的Strongswan用了实例的临时公网IP（不是弹性EIP），重启实例后公网IP会变，隧道配置里的对等端IP就不对了，得换成弹性EIP或者确认是否可以用AWS内部私有IP（跨区域场景优先用EIP）
• 安全组/网络ACL规则丢失：重启实例可能换了ENI，或者之前的安全组没放行IPSec必需的UDP 500和4500端口，检查两边实例的安全组和所在子网的NACL，确保双向放行这两个端口，以及私有子网的CIDR流量
• 路由表条目丢失：重启后实例的静态路由（指向Strongswan隧道的路由）没了，得把路由配置写到/etc/sysconfig/network-scripts/route-*或者用ip route add命令永久添加

为什么VPC Peering能解决这个问题？ #

VPC Peering是AWS原生的跨VPC网络互通方案，和你自己搭的Strongswan隧道比，优势太明显了：

• 完全托管，零维护：AWS负责维护底层的网络连接，你不用管IPSec隧道的建立、保活、证书更新这些杂事，哪怕实例重启、VPC资源变更，只要peering关系是活跃的，连接就一直能用
• 配置更简单：只需要在两边VPC的路由表里添加一条条目，目标是对方VPC的CIDR，下一跳是peering连接的ID就行，不用折腾Strongswan的复杂配置
• 性能更稳定：走AWS内部的骨干网络，延迟比公网上的IPSec隧道低很多，而且带宽更有保障
• 兼容性更好：和AWS的其他服务（比如EC2、RDS）无缝集成，不用额外配置就能让跨区域的私有资源互通

用VPC Peering的注意事项 #

虽然好用，但有几个坑得提前避开：

• VPC CIDR不能重叠：如果两个区域的VPC私有IP段（比如都是10.0.0.0/16），那没法建立peering关系，得调整其中一个VPC的CIDR或者改用Transit Gateway
• 跨区域带宽限制：跨区域peering的带宽没有明确的硬限制，但大流量场景（比如TB级数据同步）可能会遇到瓶颈，这种情况可以考虑AWS Direct Connect或者Transit Gateway
• 安全策略还是要配：peering只是打通了网络，两边的安全组还是要放行对方VPC的CIDR流量，NACL也要允许双向的对应端口，不然还是ping不通
• 不能通过peering访问跨区域的AWS公共服务：比如你想通过peering访问另一个区域的S3，得用VPC Endpoint或者其他方式，peering只能用于VPC之间的私有资源互通

最后给你的建议 #

如果你的需求只是简单的跨区域VPC私有网络互通，直接换成VPC Peering是最省心的选择，再也不用操心Strongswan的启停和配置问题；要是你因为合规或者其他原因必须保留IPSec隧道（比如需要加密特定流量，或者要连接非AWS的环境），那先按照上面的排查步骤修复Strongswan的问题，也能恢复正常。

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