OpenVPN客户端到站点（Client-to-Site）VPN配置问题：不路由所有流量时无法访问AWS VPC
嗨，我来帮你解决这个问题！核心问题其实出在路由配置的双向连通性上——当你关闭redirect-gateway后，客户端不知道该把VPC网段的流量发去VPN，同时VPC里的机器也不知道怎么把回包发给VPN客户端。下面是一步步的具体修复方案：
1. 修正OpenVPN服务器配置（server.conf）
你现在的服务器配置里只加了route 172.31.0.0 255.255.0.0，这条是让服务器自己知道VPC网段的存在，但没有把这条路由推送给客户端。客户端连接后根本不知道要把VPC的流量走VPN隧道，自然访问不通。
修改server.conf，添加推送路由的配置：
# 保留原来的route规则（让服务器能转发VPC网段的流量） route 172.31.0.0 255.255.0.0 # 新增：把VPC网段的路由推送给所有客户端 push "route 172.31.0.0 255.255.0.0" # 确保redirect-gateway是注释状态，和你现在的配置一致 #push "redirect-gateway def1"
2. 确认客户端配置（client.conf）
你的客户端配置基本没问题，只要确保以下几点：
redirect-gateway def1保持注释状态- 如果担心服务器不小心推送网关重定向，可以保留
pull-filter ignore redirect-gateway（这个不会破坏路由推送，只会忽略网关重定向的指令） - 其他配置保持原样即可
3. 完善iptables转发规则
现在的iptables规则只允许VPN客户端的流量向外转发，但缺少反向的回包放行规则（VPC机器回给客户端的流量）。另外，MASQUERADE规则可以更精确，只针对VPC网段的流量做地址转换，符合你不想全流量走VPN的需求。
执行以下命令更新iptables：
# 放行VPC到VPN客户端的回包流量 /sbin/iptables -A FORWARD -d 10.9.80.0/20 -j ACCEPT # （可选但推荐）替换原来的MASQUERADE规则，只针对VPC网段做地址转换 # 先删除旧规则 /sbin/iptables -t nat -D POSTROUTING -s 10.9.80.0/20 -o ens5 -j MASQUERADE # 添加新规则 /sbin/iptables -t nat -A POSTROUTING -s 10.9.80.0/20 -d 172.31.0.0/16 -o ens5 -j MASQUERADE
最后别忘了保存iptables规则，避免重启后丢失：
- Debian/Ubuntu系统：
netfilter-persistent save - RHEL/CentOS系统：
iptables-save > /etc/sysconfig/iptables
4. 关键！配置AWS VPC路由表
这是最容易被忽略的一步：VPC里的所有机器需要知道，来自VPN客户端网段（10.9.80.0/20）的流量要回发给OpenVPN服务器的内网IP，而不是默认的互联网网关。
登录AWS控制台，按以下步骤操作：
- 找到你的VPC对应的主路由表（或者OpenVPN服务器所在子网的专属路由表）
- 添加一条新的路由条目：
- 目标网段：
10.9.80.0/20 - 下一跳类型：选择「实例」，然后选中你的OpenVPN服务器EC2实例
- 目标网段：
- 保存路由表
5. 测试验证
完成以上配置后，按顺序操作：
- 重启OpenVPN服务器：
systemctl restart openvpn@server - 客户端断开并重新连接VPN
- 在客户端查看路由表：
- Linux/macOS：执行
route -n，应该能看到172.31.0.0/16的路由指向VPN隧道的网关（通常是10.9.80.1） - Windows：执行
route print，找到目标为172.31.0.0的条目，确认其下一跳是VPN适配器的IP
- Linux/macOS：执行
- 测试访问VPC内的机器，比如ping或者SSH，应该能正常连通了
为什么之前的配置不行？
当你开启redirect-gateway时，客户端的默认网关被替换成了VPN服务器，所有流量都走VPN，包括VPC的流量——这时候VPC的回包会通过VPN服务器返回给客户端，所以能连通。但关闭网关重定向后，客户端没有针对VPC网段的专属路由，会用自己的默认公网网关去访问VPC，而VPC里的机器不知道怎么把回包发给VPN客户端网段，导致双向通信中断。
备注：内容来源于stack exchange，提问作者Life5ign
