พฤติกรรมการกำหนดเส้นทาง Ubuntu กับ Windows VPN


1

ทั้งเครือข่ายในบ้านและที่ทำงานของฉันเหมือนกัน (subnet 10.0.0.x)

เมื่อฉันกำหนดค่าการเชื่อมต่อ VPN บนเครื่อง Windows 7 (PPTP) ของฉันฉันสามารถ ping เซิร์ฟเวอร์ใด ๆ ที่อยู่ในที่ทำงานของฉันโดยไม่มีเส้นทางที่เกี่ยวข้อง

ในทางตรงกันข้ามเมื่อกำหนดค่าการเชื่อมต่อ 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 ของอูบุนตู (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'

2
ตั้งค่าสถานะสำหรับการย้ายข้อมูลไปยัง superuser ตรวจสอบว่าไคลเอนต์ Ubuntu pptp ของคุณไม่เพียง แต่ละทิ้งเส้นทางที่ถูกผลักจากต้นน้ำและมันมีสิทธิ์ในการเพิ่มเส้นทางเพิ่มเติมไปยังตารางเส้นทาง หากคุณต้องการความช่วยเหลือเฉพาะเจาะจงมากขึ้นโปรดระบุชื่อของไคลเอนต์ pptp ที่คุณกำลังใช้ (อาจเป็นผู้จัดการเครือข่ายหากคุณใช้ไคลเอ็นต์ในตัว) ตรวจสอบ ubuntu syslog ( /var/log/<files>) ของคุณเพื่อดูว่ามีข้อผิดพลาดใด ๆ ที่รายงานโดย pptp และเพิ่มผลลัพธ์ที่เหมาะสมให้กับคำถามของคุณ
Andrew Domaszek

สวัสดี Andrew ขอบคุณสำหรับคำตอบอย่างรวดเร็ว ฉันแก้ไขคำถามแล้ว การเพิ่มเส้นทางไม่ใช่ปัญหา แต่การทำให้เส้นทางเป็นเส้นทาง Windows ดูเหมือนว่าเป็นปัญหาสำหรับฉัน @AndrewDomaszek

หากนาโนเมตร PPTP ไม่เปิดเผย PPP ของตัวเลือกใช้เส้นทางที่ใช้ gsettings, GConf บรรณาธิการหรือ dconf บรรณาธิการเป็นผู้ใช้ของคุณ (หรือรากถ้าคุณกำลังนำการเชื่อมต่อขึ้นสำหรับผู้ใช้ทั้งหมด) และตั้งค่าตัวเลือกในการuse-routes yes
Andrew Domaszek

@AndrewDomaszek ฉันไม่พบสคีมาใด ๆ เลยไม่มีเอกสารชี้ไปที่use-routesตัวเลือก ดังที่ฉันกล่าวถึงในคำถาม Windows สร้างเส้นทางเริ่มต้นสองเส้นทาง เมื่อ ping a severs ระยะไกล (ซึ่งมี subnet เดียวกับของฉันเอง) ก่อนพยายามค้นหาในเครื่องและเมื่อมันล้มเหลว - คำขอไปที่อุโมงค์จะถูกส่ง (ตามที่ระบุไว้ในตารางเส้นทางโดยเกตเวย์เริ่มต้นที่สอง) นั่นไม่ใช่สิ่งที่เกิดขึ้นใน Ubuntu

คำตอบ:


0

เท่าที่ฉันสามารถบอกได้จากผลลัพธ์ของคุณไม่มีโฮสต์ใดมีเส้นทางเข้าถึง10.0.0.83ผ่าน VPN ทั้งคู่มีตารางเส้นทางที่ระบุว่า10.0.0.83เชื่อมต่อโดยตรงผ่านเครือข่ายทางกายภาพ

เอาต์พุต Windows แนะนำให้ติดตามครั้งแรกล้มเหลวเนื่องจากการหมดเวลาของ ARP ไม่มีโฮสต์บนเครือข่ายที่ต่อโดยตรงที่อ้างว่ามี10.0.0.83ดังนั้นคุณจะเห็นข้อความที่ไม่สามารถเข้าถึงได้จากเครื่อง Windows

สิ่งต่อไปที่แปลกประหลาดเกิดขึ้นเพราะความพยายามครั้งต่อไปดูเหมือนจะกำหนดเส้นทางผ่าน VPN สิ่งนี้คล้ายกับสิ่งที่คุณคาดหวังให้เห็นในกรณีที่มีข้อความเปลี่ยนเส้นทาง ICMP แต่ไม่เหมือนกันทุกประการ

ร่องรอยของการสื่อสารที่เกิดขึ้นจริงอาจถูกเปิดเผย มีสิ่งใดใน LAN ที่ส่งแพ็คเก็ตไปยังเครื่อง Windows ซึ่งสามารถอธิบายการเปลี่ยนแปลงนี้ได้หรือไม่


การถ่ายโอนข้อมูล Wireshark แสดงคำขอ ARP สำหรับ 10.0.0.83 แต่ไม่ได้รับคำตอบ หลังจากช่วงเวลาสั้น ๆ แพ็คเก็ต PPP ที่ถูกห่อหุ้มกำลังถูกส่งระหว่างที่อยู่ VPN สาธารณะและ IP ท้องถิ่น ไม่มีอะไรบ่งบอกถึงพฤติกรรมที่แปลกประหลาด ... นี่เป็นกลไกในตัวของ Windows ทั้งหมด มีวิธีเลียนแบบสิ่งนี้ใน linux หรือไม่?

@ user2980615 เกณฑ์ที่ Windows ใช้คืออะไร มันจะย้อนกลับไปสู่เส้นทางที่เฉพาะเจาะจงน้อยลงหรือไม่หากมีเส้นทางที่เฉพาะเจาะจงมากกว่าเดิม แต่ให้เวลา ARP หมด? ไม่ควรที่จะทำเช่นนั้นโดยทั่วไปเพราะอาจนำไปสู่เส้นทางการวนซ้ำได้ง่าย ฉันไม่รู้วิธีเฉพาะใด ๆ ในการทำให้ Linux ทำเช่นนั้น แต่คำแนะนำของฉันจะไม่นำพื้นที่ที่อยู่ RFC1918 กลับมาใช้ใหม่ในเครือข่ายที่ต้องสื่อสารซึ่งกันและกันแล้วใช้เส้นทางที่ชัดเจนเช่นนั้นไม่จำเป็นต้องใช้ทางเลือกสำรอง
kasperd

มันง่ายกว่าสำหรับฉันที่จะสร้างเส้นทางแบบสแตติกระหว่างฉันกับเซิร์ฟเวอร์ระยะไกลบางตัวที่อยู่ด้านบนของการเปลี่ยนเครือข่ายย่อยภายในบ้านทั้งหมดของฉัน ฉันจะหาวิธีแก้ปัญหาที่ชาญฉลาดสำหรับปัญหานี้ ...
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.