我想通过 VPN 重定向所有流量，但它根本不起作用。
服务器：RT-N16 [TomatoUSB v1.28.0000 MIPSR2-112 K26 USB AIO]
客户：Ubuntu 14.04.1
服务器配置：
# 自动生成的配置 守护进程 服务器 10.8.0.0 255.255.255.0 原始 TCP 服务器 端口9999 开发tun21 密码 AES-256-CBC 比较号 保持活动 15 60 动词3 推送“路由 192.168.1.0 255.255.255.0” 推送“dhcp-选项 DNS 192.168.1.1” 推“重定向网关 def1” ca.crt DH-PEM 证书服务器.crt 密钥服务器.key 状态版本 2 状态 状态 # 自定义配置（这些部分似乎是主要修复）： 客户对客户 推“comp-lzo” 推“重定向网关”
服务器：（iptables -L -t nat -n只是 POSTROUTING 输出链）
链 POSTROUTING（策略接受） 目标 prot 选择源目的地 伪装全部 -- 0.0.0.0/0 0.0.0.0/0 SNAT 全部 -- 192.168.1.0/24 192.168.1.0/24 到:192.168.1.1
服务器日志：
2 月 4 日 21:19:38 r daemon.notice openvpn[1072]：与 [AF_INET]192.168.1.4:58170 建立 TCP 连接 2 月 4 日 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 TLS: 来自 [AF_INET]192.168.1.4:58170 的初始数据包，sid=00fe6a02 33820233 2 月 4 日 21:19:39 r daemon.notice openvpn[1072]：192.168.1.4:58170 验证正常：XXXXXXXXXXXXXXXXXX 2 月 4 日 21:19:39 r daemon.notice openvpn[1072]：192.168.1.4:58170 验证正常：XXXXXXXXXXXXXXXXXX 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 数据通道加密：使用 256 位密钥初始化的密码“AES-256-CBC” 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 数据通道加密：使用 160 位消息哈希“SHA1”进行 HMAC 身份验证 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 数据通道解密：使用 256 位密钥初始化密码“AES-256-CBC” 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 数据通道解密：使用 160 位消息哈希“SHA1”进行 HMAC 身份验证 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 控制通道：TLSv1，密码 TLSv1/SSLv3 DHE-RSA-AES256-SHA，2048 位 RSA 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 [client] 使用 [AF_INET]192.168.1.4:58170 启动对等连接 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]：client/192.168.1.4:58170 MULTI_sva：池返回 IPv4=10.8.0.6，IPv6=（未启用） 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]：client/192.168.1.4:58170 MULTI：学习：10.8.0.6 -> client/192.168.1.4:58170 2 月 4 日 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: client/192.168.1.4:58170: 10.8.0.6 的主虚拟 IP 2 月 4 日 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 PUSH: 收到控制消息: 'PUSH_REQUEST' 2 月 4 日 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 send_push_reply(): safe_cap=940 2 月 4 日 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,redirect-网关 def1，路由 10.8.0.1，拓扑 net30，ping 15，ping-restart 60，ifconfig 10.8.0.6 10.8.0.5'（状态 = 1）
客户端配置：
客户 远程 192.168.1.1 9999 ca.crt 证书客户端.crt 关键客户端.key 密码 AES-256-CBC 开发屯 原始 TCP 诺宾德 auth-nocache 脚本安全 2 持久键 坚持-tun 用户无人 组无组
客户端：（netstat -nr启用 VPN）：
内核IP路由表 目标网关 Genmask 标志 MSS 窗口 irtt Iface 0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0 10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0 10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0 192.168.1.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 192.168.1.1 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
客户端日志：
2015 年 2 月 4 日星期三 21:32:24 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] 建于 2014 年 12 月 1 日 2015 年 2 月 4 日星期三 21:32:24 警告：尚未启用服务器证书验证方法。请参阅 http://openvpn.net/howto.html#mitm 了解更多信息。 2015 年 2 月 4 日星期三 21:32:24 注意：UID/GID 降级将因 --client、--pull 或 --up-delay 延迟 2015 年 2 月 4 日星期三 21:32:24 尝试与 [AF_INET]192.168.1.1:9999 [nonblock] 建立 TCP 连接 2015 年 2 月 4 日星期三 21:32:25 与 [AF_INET]192.168.1.1:9999 建立 TCP 连接 2015 年 2 月 4 日星期三 21:32:25 TCPv4_CLIENT 本地链接：[undef] 2015 年 2 月 4 日星期三 21:32:25 TCPv4_CLIENT 链接远程：[AF_INET]192.168.1.1:9999 2015 年 2 月 4 日星期三 21:32:26 [zais.dnsd.me] 使用 [AF_INET]192.168.1.1:9999 启动对等连接 2015 年 2 月 4 日星期三 21:32:29 TUN/TAP 设备 tun0 打开 2015 年 2 月 4 日星期三 21:32:29 do_ifconfig，tt->ipv6=0，tt->did_ifconfig_ipv6_setup=0 2015 年 2 月 4 日星期三 21:32:29 /sbin/ip link set dev tun0 up mtu 1500 2015 年 2 月 4 日星期三 21:32:29 /sbin/ip addr add dev tun0 本地 10.8.0.6 对等 10.8.0.5 2015 年 2 月 4 日星期三 21:32:29 GID 设置为 nogroup 2015 年 2 月 4 日星期三 21:32:29 UID 设置为无人 2015 年 2 月 4 日星期三 21:32:29 初始化序列已完成 2015 年 2 月 4 日星期三 21:32:43 写入 TUN/TAP：参数无效（代码=22） 2015 年 2 月 4 日星期三 21:32:58 写入 TUN/TAP：参数无效（代码=22） 2015 年 2 月 4 日星期三 21:33:13 写入 TUN/TAP：参数无效（代码=22） 2015 年 2 月 4 日星期三 21:33:28 写入 TUN/TAP：参数无效（代码=22）
更新：感谢帮助。 VPN 现在正在工作（不确定方式，但连接后我需要等待大约 5 分钟才能真正进入工作状态，可能是我的路由器的限制，比如没有足够的 CPU/MEM）
答案1
由于某种原因，您的客户端无法在隧道打开时删除当前的默认路由，从而导致路由表中存在两条默认路由。
您要做的就是在隧道出现之前为当前路由指定一个较低的度量（较高的数字）。您可以使用route -n 命令查看指标：
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.3.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0
9.15.64.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 9.15.64.1 0.0.0.0 UG 0 0 0 eth0
例如，给您的 wlan 接口度量为 20，让隧道路由的度量为 0。您的流量将全部沿着隧道路由发送。
为了配置接口上的指标，只需打开 /etc/sysconfig/network-scripts 目录中的 wlan 接口文件并添加一个名为 METRIC=20 的参数。
应该可以做到这一点。确保事后使用route -n 命令对其进行验证。
更新：
现在您已经有了正确的默认路由，是时候使用 tcpdump 和 ping 进行故障排除了。例如，尝试以下命令并对远程网络执行一些 ping 操作。
# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:59:13.591764 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 4, length 64
09:59:13.681290 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 4, length 64
09:59:14.592829 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 5, length 64
09:59:14.680878 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 5, length 64
我的猜测是您会看到回显请求，但看不到回显回复。这意味着远程端点不会将数据包路由回。您还需要在服务器配置文件中修复那里的路由。
更新2
从您的 tcpdump 可以清楚地看出，您的客户端正在通过隧道路由数据包，因此您的问题出在远程端，因为它没有将数据包路由回来。
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:19:28.964361 IP 10.8.0.6.57394 > 192.168.1.1.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964382 IP 10.8.0.6.57394 > 8.8.8.8.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964398 IP 10.8.0.6.57394 > 8.8.4.4.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
您必须检查每一跳以查看路由表的情况。从 192.168.1.1 开始。它是否知道将发送到 10.8.0.6 的数据包路由到哪里？