![VPN 启动时互联网无法工作](https://linux22.com/image/47369/VPN%20%E5%90%AF%E5%8A%A8%E6%97%B6%E4%BA%92%E8%81%94%E7%BD%91%E6%97%A0%E6%B3%95%E5%B7%A5%E4%BD%9C.png)
我想通过 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 的数据包路由到哪里?