云上VPN连接实战：打通云下数据中心，IPsec隧道配置与排错

去年一个客户，公司业务上云，数据库和应用都迁到了云上。但有一些遗留系统还跑在本地机房，需要和云上应用通信。他们找了供应商，配置了VPN。隧道状态显示“UP”，但云上的应用就是访问不了本地数据库。

查了两天。安全组放行了，本地防火墙也开了，路由也配了。最后发现是MTU问题。IPsec隧道加包头后MTU变小，云上发的大包到本地被丢弃，小包能通，大包不行。应用访问数据库用的是大包，所以不通。

这是VPN排错最经典的场景：隧道显示通了，但业务就是不通。

今天聊聊云上VPN连接。不是那种“VPN很重要”的入门课，而是帮你理清楚：IPsec隧道怎么配？路由怎么设？出了问题怎么查？

01 VPN网关：云托管还是自建？

云托管VPN网关：AWS VPN、Azure VPN Gateway、阿里云VPN网关。

• 优点：不用自己维护，高可用自动配置，和云服务集成好

• 缺点：贵，配置灵活性受限

• 适合：不想自己运维、对成本不敏感

自建VPN：在EC2上跑StrongSwan、OpenSwan、WireGuard。

• 优点：便宜（只付EC2费用），配置灵活

• 缺点：自己要搭高可用，要维护

• 适合：有网络运维能力、想省钱

那家客户用的云托管VPN，配置简单，但排错时参数看不到。后来换了自建StrongSwan，日志详细，问题定位快。

02 IPsec配置：两端必须一致

IPsec隧道建不起来，90%是两端参数不一致。

必须匹配的参数：

调试建议：

• 先开IKEv1，兼容性好。v2更安全但部分设备不支持。

• 加密算法选AES256 + SHA256，足够安全。

• DH组选14或更高。

• 开启DPD（死对等检测），隧道断了能自动恢复。

那家客户隧道一直重连，查日志发现本地设备要求PFS开启，云上没开。开了就好了。

03 路由配置：静态路由还是BGP？

隧道建起来了，接下来要告诉流量怎么走。

静态路由：手动配“去本地网段，走VPN网关”。

• 优点：简单

• 缺点：本地网段变了要手动改；多条链路时无法自动切换

BGP动态路由：通过VPN隧道跑BGP，自动交换路由。

• 优点：本地网段变化自动同步；多条链路自动切换

• 缺点：配置复杂

那家客户用的静态路由。本地加了一个新网段，忘了配路由，不通。后来换成BGP，自动同步，省心。

04 网络打通：四个地方都要放行

很多人以为VPN建好了，路由配了，就能通了。错。还有四个地方要检查。

云上安全组：云上ECS的出站/入站规则，要放行对端网段。

云上网络ACL：子网级别ACL，要放行。

本地防火墙：本地防火墙的入站/出站规则，要放行VPN流量。

本地主机防火墙：本地服务器自己的防火墙（iptables、Windows防火墙），要放行。

那家客户云上安全组没放行本地网段，应用访问本地数据库被拦截。加了一条入站规则，通了。

05 常见排错：隧道UP但业务不通

隧道状态显示UP，但业务不通。按顺序排查。

第一步：ping测试

• 云上ping本地IP，通吗？

• 如果不通，检查安全组、防火墙、路由

第二步：端口测试

• telnet本地数据库端口，通吗？

• 如果不通，检查服务是否监听、防火墙是否放行

第三步：MTU问题

• 小包通，大包不通 → MTU问题

• IPsec加包头后，MTU从1500降到1400左右

• 解决：设置TCP MSS clamping，或减小云上MTU

第四步：日志分析

• 云托管VPN日志有限。自建StrongSwan可以看/var/log/charon.log

• 看IKE协商是否成功、加密算法是否匹配、DPD是否超时

那家客户就是卡在MTU。ping 1400字节通，1500字节不通。改MTU后，业务正常。

06 一个真实案例：从UP但不通到稳定运行

一个客户，本地机房和云上通过VPN连接。建好后，业务偶尔断，断几分钟又恢复。查了几天。

发现是DPD参数不一致。本地DPD间隔10秒，超时30秒；云上DPD间隔30秒，超时120秒。云上认为隧道还活着，本地已经断了。

统一参数：DPD间隔10秒，超时30秒。隧道稳定了。

网络负责人说：“以前觉得隧道建起来就行，现在知道，参数调不对，时通时断更折磨。”

写在最后

VPN连接是混合云的第一步。隧道建起来只是开始，能通业务才是目标。

那家客户的网络负责人后来总结：“参数要一致，路由要配通，安全组防火墙都要放行。MTU是隐形杀手，DPD参数要统一。日志是亲爹，多看看。”

你的云上云下，打通了吗？