我的家庭网络和工作场所网络相同（子网 10.0.0.x）。
当我在 Windows 7 机器上配置 VPN 连接（PPTP）时，我可以 ping 位于我工作场所的任何服务器，而无需涉及任何静态路由。
另一方面，当我在 Ubuntu 14.04 机器上配置相同的 VPN 连接时，我无法与远程网络建立任何连接，除非通过隧道为另一个网络上的特定主机创建静态路由。
我试图弄清楚 Windows 上发生了什么，发现了以下情况：
有第二个默认网关将所有流量引导至隧道，以下是输出
route print：Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.0.0.138 10.0.0.9 4255 0.0.0.0 0.0.0.0 On-link 192.168.88.102 31 10.0.0.0 255.255.255.0 On-link 10.0.0.9 4511 10.0.0.9 255.255.255.255 On-link 10.0.0.9 4511 10.0.0.255 255.255.255.255 On-link 10.0.0.9 4511 127.0.0.0 255.0.0.0 On-link 127.0.0.1 4531 127.0.0.1 255.255.255.255 On-link 127.0.0.1 4531 127.255.255.255 255.255.255.255 On-link 127.0.0.1 4531 192.168.88.102 255.255.255.255 On-link 192.168.88.102 286 x.x.x.x 255.255.255.255 10.0.0.138 10.0.0.9 4256 224.0.0.0 240.0.0.0 On-link 127.0.0.1 4531 224.0.0.0 240.0.0.0 On-link 10.0.0.9 4514 224.0.0.0 240.0.0.0 On-link 192.168.88.102 31 255.255.255.255 255.255.255.255 On-link 127.0.0.1 4531 255.255.255.255 255.255.255.255 On-link 10.0.0.9 4511 255.255.255.255 255.255.255.255 On-link 192.168.88.102 286
192.168.88.102是我的隧道 IP、
10.0.0.9是我的本地 IP、
10.0.0.138是我的路由器 IP 以及x.x.x.xVPN 服务器公共 IP。
tracert输出：
首次：
tracert -d 10.0.0.83
Tracing route to 10.0.0.83 over a maximum of 30 hops
1 10.0.0.9 reports: Destination host unreachable.
Trace complete.
第二次：
tracert -d 10.0.0.83
Tracing route to 10.0.0.83 over a maximum of 30 hops
1 42 ms 33 ms 53 ms 192.168.88.1
2 35 ms 31 ms 33 ms 10.0.0.83
Trace complete.
- 相关
arp输出：
远程地址：
arp -a | findstr 10.0.0.83
10.0.0.83 static
本地地址：
arp -a | findstr 10.0.0.14
10.0.0.14 b8-27-eb-37-38-a4 dynamic
而在 Ubuntu 上，默认路由列表是：
Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 wlan0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 192.168.88.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 x.x.x.x 10.0.0.138 255.255.255.255 UGH 0 0 0 wlan0 x.x.x.x 10.0.0.138 255.255.255.255 UGH 0 0 0 wlan0
添加另一个默认网关并没有起到作用。
这种行为该如何解释？我怎样才能在 Ubuntu 中实现这种情况？
编辑：
我正在使用 Ubuntu 的内置 VPN 客户端（NetworkManager），它根据 运行root。syslog此外，尝试在 VPN 插件的 IPv4 设置配置面板中添加静态路由，似乎成功将它们添加到路由表中，但不像 Windows 那样运行。
/var/log/syslog这是从建立连接那一刻起的Ubuntu ：
May 29 16:49:56 hostname wpa_supplicant[823]: wlan0: CTRL-EVENT-SCAN-STARTED
May 29 16:49:57 hostname wpa_supplicant[823]: nl80211: send_and_recv->nl_recvmsgs failed: -33
May 29 16:50:15 hostname NetworkManager[757]: <info> Starting VPN service 'pptp'...
May 29 16:50:15 hostname NetworkManager[757]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 5123
May 29 16:50:15 hostname NetworkManager[757]: <info> VPN service 'pptp' appeared; activating connections
May 29 16:50:15 hostname NetworkManager[757]: <info> VPN plugin state changed: starting (3)
May 29 16:50:15 hostname pppd[5127]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
May 29 16:50:15 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (Connect) reply received.
May 29 16:50:15 hostname pppd[5127]: pppd 2.4.5 started by root, uid 0
May 29 16:50:15 hostname pppd[5127]: Using interface ppp0
May 29 16:50:15 hostname pppd[5127]: Connect: ppp0 <--> /dev/pts/7
May 29 16:50:15 hostname NetworkManager[757]: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
May 29 16:50:15 hostname NetworkManager[757]: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
May 29 16:50:15 hostname NetworkManager[757]: <warn> /sys/devices/virtual/net/ppp0: couldn't determine device driver; ignoring...
May 29 16:50:15 hostname pptp[5132]: nm-pptp-service-5123 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 61002).
May 29 16:50:16 hostname pppd[5127]: CHAP authentication succeeded
May 29 16:50:16 hostname pppd[5127]: MPPE 128-bit stateless compression enabled
May 29 16:50:18 hostname pppd[5127]: local IP address 192.168.88.102
May 29 16:50:18 hostname pppd[5127]: remote IP address 192.168.88.1
May 29 16:50:18 hostname pppd[5127]: primary DNS address 10.0.0.2
May 29 16:50:18 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (IP4 Config Get) reply received from old-style plugin.
May 29 16:50:18 hostname NetworkManager[757]: <info> VPN Gateway: x.x.x.x
May 29 16:50:18 hostname NetworkManager[757]: <info> Tunnel Device: ppp0
May 29 16:50:18 hostname NetworkManager[757]: <info> IPv4 configuration:
May 29 16:50:18 hostname NetworkManager[757]: <info> Internal Address: 192.168.88.102
May 29 16:50:18 hostname NetworkManager[757]: <info> Internal Prefix: 32
May 29 16:50:18 hostname NetworkManager[757]: <info> Internal Point-to-Point Address: 192.168.88.1
May 29 16:50:18 hostname NetworkManager[757]: <info> Maximum Segment Size (MSS): 0
May 29 16:50:18 hostname NetworkManager[757]: <info> Forbid Default Route: yes
May 29 16:50:18 hostname NetworkManager[757]: <info> Internal DNS: 10.0.0.2
May 29 16:50:18 hostname NetworkManager[757]: <info> DNS Domain: '(none)'
May 29 16:50:18 hostname NetworkManager[757]: <info> No IPv6 configuration
May 29 16:50:19 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (IP Config Get) complete.
May 29 16:50:19 hostname NetworkManager[757]: <info> Policy set 'AO' (wlan0) as default for IPv4 routing and DNS.
May 29 16:50:19 hostname NetworkManager[757]: <info> Writing DNS information to /sbin/resolvconf
May 29 16:50:19 hostname dnsmasq[1565]: setting upstream servers from DBus
May 29 16:50:19 hostname dnsmasq[1565]: using nameserver 10.0.0.2#53 for domain 88.168.192.in-addr.arpa
May 29 16:50:19 hostname dnsmasq[1565]: using nameserver 10.0.0.138#53
May 29 16:50:20 hostname NetworkManager[757]: <info> VPN plugin state changed: started (4)
May 29 16:50:20 hostname dbus[691]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
May 29 16:50:20 hostname dbus[691]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
答案1
据我从您的输出中得知，两台主机都没有10.0.0.83通过 VPN 到达的路由。它们都有一个路由表，表明10.0.0.83它们通过物理网络直接连接。
Windows 输出表明第一次跟踪由于 ARP 超时而失败。直接连接的网络上没有主机真正声称拥有10.0.0.83，因此您会看到来自 Windows 计算机本身的无法访问消息。
接下来发生了一些奇怪的事情，因为下一次尝试似乎是通过 VPN 进行路由。这与 ICMP 重定向消息的情况略有相似，但不完全相同。
实际通信的数据包跟踪可能会揭示一些问题。LAN 上是否有任何东西向 Windows 计算机发送数据包，这可以解释这种行为变化吗？