Ubuntu против поведения Windows VPN-маршрутизации

Question

Мои домашние и рабочие сети одинаковы (подсеть 10.0.0.x).

Когда я настраиваю VPN-соединение на моем компьютере с Windows 7 (PPTP), я могу пропинговать любой сервер, который находится на моем рабочем месте, без каких-либо статических маршрутов.

С другой стороны, при настройке того же VPN-соединения на моем компьютере с Ubuntu 14.04 я не могу установить соединение с удаленной сетью, если для туннеля создается статический маршрут для конкретного хоста в другой сети через туннель.

Я пытался выяснить, что происходит в 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 - мой маршрутизатор, а x.x.x.x - публичный IP-адрес VPN-сервера.

вывод 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?

РЕДАКТИРОВАТЬ:

Я использую встроенный VPN-клиент Ubuntu (NetworkManager), который работает под root согласно syslog . Кроме того, попытался добавить статические маршруты на панели настройки параметров IPv4 плагина VPN, который, казалось, успешно добавлял их в таблицу маршрутизации, но не действовал, как Windows.

Вот Ubuntu /var/log/syslog с момента установления соединения:

     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'

score 0 · Answer 1 · 2011-03-09T19:38:42

Насколько я могу судить по вашему выводу, ни у одного хоста нет маршрута для достижения 10.0.0.83 через VPN. У них обоих есть таблица маршрутизации, указывающая, что 10.0.0.83 напрямую подключен через физическую сеть.

Выходные данные Windows предполагают, что первая трассировка завершается ошибкой из-за тайм-аута ARP. Ни один хост в сети с прямым подключением на самом деле не заявляет о наличии 10.0.0.83 , поэтому вы видите недоступное сообщение от самой машины Windows.

Затем происходит нечто странное, потому что следующей попыткой является маршрутизация через VPN. Это немного похоже на то, что вы ожидаете увидеть в случае сообщения перенаправления ICMP, но не совсем то же самое.

Трассировка пакета реальной связи может быть показательной. Что-нибудь в локальной сети отправляет пакет на компьютер с Windows, что может объяснить это изменение в поведении?

Сейчас выбран русский

Ubuntu против поведения Windows VPN-маршрутизации

1 ответ1

Всё ещё ищете ответ? Посмотрите другие вопросы с метками ubuntu windows vpn routing pptp.

Ubuntu против поведения Windows VPN-маршрутизации

1 ответ1

Всё ещё ищете ответ? Посмотрите другие вопросы с метками ubuntu windows vpn routing pptp.

Похожие