เป็นไปได้หรือไม่ที่ L2TP VPN จะทำการกำหนดค่าเส้นทางอัตโนมัติสำหรับลูกค้าในระหว่างการเชื่อมต่อ?


13

เราได้ติดตั้งเซิร์ฟเวอร์ L2TP VPN ด้วยบทช่วยสอนนี้ทุกอย่างทำงานได้อย่างมีเสน่ห์

ปัญหาเดียวคือ

  1. เราไม่ต้องการให้ลูกค้ากำหนดเส้นทางการรับส่งข้อมูลทั้งหมดโดยใช้ VPN นี้เฉพาะซับเน็ตเฉพาะเช่น 10.0.0.0/20

  2. สำหรับ Mac เราต้องตั้งค่าเส้นทางด้วยตนเองโดยใช้คำสั่ง แต่สำหรับอุปกรณ์มือถือดูเหมือนว่าไม่มีวิธีทำเช่นนั้นหรือ

ดังนั้นจึงเป็นไปได้ที่จะกำหนดค่าสำหรับไคลเอ็นต์โดยอัตโนมัติสำหรับ subnet "10.0.0.0/20"


คุณได้ลองปิดการใช้งาน 'ส่งการรับส่งข้อมูลทั้งหมดผ่าน VPN' หรือตัวเลือกที่คล้ายกันในไคลเอ็นต์หรือไม่
Bert

คำตอบ:


33

ตกลงคำถามนี้ถูกถามซ้ำแล้วซ้ำอีกผ่านทางอินเทอร์เน็ตและส่วนใหญ่มีคำตอบที่ไม่ถูกต้อง (กึ่ง -) ที่คุณไม่สามารถทำสิ่งที่อธิบายไว้ในโพสต์ต้นฉบับ ให้ฉันอธิบายทันทีและทั้งหมด :)

คำตอบสั้น ๆ คือ L2TP (และ PPTP สำหรับเรื่องนั้น) ไม่มีสิ่งอำนวยความสะดวกในการทำเส้นทางพุชภายในโปรโตคอล แต่สามารถทำได้นอกโปรโตคอล

เนื่องจาก L2TP เป็นสิ่งประดิษฐ์ของ Microsoft แหล่งข้อมูลที่ดีที่สุดคือเอกสารทางเทคนิคของพวกเขา (และพวกเขาค่อนข้างดีในเรื่องนี้) รายละเอียดทางเทคนิคของสิ่งที่ฉันกำลังจะอธิบายลงมาด้านล่างสามารถพบได้ที่VPN ที่อยู่และการกำหนดเส้นทาง คำหลักสำหรับการตั้งค่าทุกอย่างถูกต้อง (หากคุณกำลังทำการค้นคว้าด้วยตนเอง) คือ: DHCPINFORM และ "เส้นทางแบบคงที่ไม่มีคลาส"

ก่อนอื่นมันทำงานอย่างไร:

  1. ไคลเอ็นต์เชื่อมต่อกับเซิร์ฟเวอร์ VPN
  2. หลังจากการพิสูจน์ตัวตนสำเร็จอุโมงค์ที่ปลอดภัยถูกสร้างขึ้น
  3. ไคลเอ็นต์ใช้ข้อความ DHCPINFORM หลังจากการเชื่อมต่อเพื่อร้องขอตัวเลือกเส้นทางคง Classless DHCP ตัวเลือก DHCP นี้ประกอบด้วยชุดเส้นทางที่ถูกเพิ่มไปยังตารางเส้นทางโดยอัตโนมัติของไคลเอนต์ที่ร้องขอ ( ฉันซบเซาคัดลอกและวางสายนี้โดยตรงจากเอกสารของ Microsoft :))
  4. เซิร์ฟเวอร์ VPN ตอบกลับข้อความนั้นพร้อมชุดเส้นทางที่เหมาะสม

ก็มีข้อแม้:

  • มีRFC-3442อธิบาย "DHCP Classless Static Routes" และระบุว่ารหัสสำหรับตัวเลือกนี้คือ 121 Microsoft ตัดสินใจที่จะคิดค้นวงล้อใหม่ (เช่นเคย) และใช้รหัส 249 สำหรับตัวเลือกนี้ ดังนั้นเพื่อสนับสนุนลูกค้าในวงกว้างเราจำเป็นต้องตอบกลับด้วยรหัสทั้งสอง

ฉันจะอธิบายการกำหนดค่าทั่วไปโดยใช้กล่อง Linux เป็นเซิร์ฟเวอร์ VPN (คุณสามารถกำหนดค่าเซิร์ฟเวอร์ MS โดยใช้ลิงก์ไปยังเอกสารประกอบของ Microsoft)

ในการกำหนดค่าเส้นทางบนไคลเอนต์เราจะต้องใช้ส่วนผสมต่อไปนี้:

  • L2TP / IPSEC (หรือ PPTP) = ตัวอย่างเช่น accel-ppp เป็นโอเพ่นซอร์สเซิร์ฟเวอร์ L2TP / PPTP ที่ดี
  • เซิร์ฟเวอร์ DHCP = มีจำนวนมาก แต่ฉันจะอธิบายการกำหนดค่าของ dnsmasq

ต่อไปนี้เป็นดัมพ์ของการกำหนดค่า accel-ppp ที่ใช้งานได้ ฉันกำลังจัดหาให้อย่างครบถ้วนไม่เช่นนั้นจะเป็นการยากที่จะอธิบายว่าอะไรจะเกิดขึ้น หากคุณใช้งาน VPN อยู่แล้วคุณสามารถข้ามไฟล์กำหนดค่านี้และตั้งสมาธิกับการกำหนดค่า DHCP ตามที่อธิบายไว้ด้านล่าง

[root@vpn ~]# cat /opt/accel-ppp/config/accel-ppp.conf
[modules]
log_syslog
pptp
l2tp
auth_mschap_v2
ippool
sigchld
chap-secrets
logwtmp

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=1
min-mtu=1280
mtu=1400
mru=1400
check-ip=1
single-session=replace
mppe=require
ipv4=require
ipv6=deny
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=0:0:0:2
ipv6-accept-peer-intf-id=1

[lcp]
lcp-echo-interval=30
lcp-echo-failure=3

[auth]
#any-login=0
#noauth=0

[pptp]
echo-interval=30
echo-failure=3
verbose=1

[l2tp]
host-name=access-vpn
verbose=1

[dns]
dns1=192.168.70.251
dns2=192.168.70.252

[client-ip-range]
disable

[ip-pool]
gw-ip-address=192.168.99.254
192.168.99.1-253

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
log-debug=/var/log/accel-ppp/debug.log
copy=1
level=3

[chap-secrets]
gw-ip-address=192.168.99.254
chap-secrets=/etc/ppp/chap-secrets

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001

[root@vpn ~]# 
===

ณ จุดนี้ลูกค้าของเราสามารถเชื่อมต่อผ่าน L2TP (หรือ PPTP) และสื่อสารกับเซิร์ฟเวอร์ VPN ดังนั้นส่วนที่ขาดหายไปเพียงอย่างเดียวคือเซิร์ฟเวอร์ DHCP ที่กำลังฟังในอุโมงค์ที่สร้างขึ้นและตอบกลับด้วยข้อมูลที่จำเป็น ด้านล่างนี้เป็นข้อความที่ตัดตอนมาจากไฟล์การกำหนดค่า dnsmasq (ฉันให้ตัวเลือกที่เกี่ยวข้องกับ DHCP เท่านั้น):

[root@vpn ~]# grep -E '^dhcp' /etc/dnsmasq.conf 
dhcp-range=192.168.99.254,static
dhcp-option=option:router
dhcp-option=121,192.168.70.0/24,192.168.99.254,192.168.75.0/24,192.168.99.254,10.0.0.0/24,192.168.99.254
dhcp-option=249,192.168.70.0/24,192.168.99.254,192.168.75.0/24,192.168.99.254,10.0.0.0/24,192.168.99.254
dhcp-option=vendor:MSFT,2,1i
[root@vpn ~]#

ในข้อความที่ตัดตอนมาข้างต้นเรากำลังผลักดันเส้นทาง 192.168.70.0/24, 192.168.75.0/24 และ 10.0.0.0/24 ผ่าน 192.168.99.254 (เซิร์ฟเวอร์ VPN)

ท้ายที่สุดถ้าคุณสูดอากาศของเครือข่าย (เช่นบนเซิร์ฟเวอร์ VPN) คุณจะเห็นสิ่งต่อไปนี้สำหรับการตอบสนองต่อข้อความ DHCPINFORM:

19:54:46.716113 IP (tos 0x0, ttl 64, id 10142, offset 0, flags [none], proto UDP (17), length 333)
    192.168.99.254.67 > 192.168.99.153.68: BOOTP/DHCP, Reply, length 305, htype 8, hlen 6, xid 0xa27cfc5f, secs 1536, Flags [none]
      Client-IP 192.168.99.153
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.99.254
        Domain-Name Option 15, length 18: "vpn.server.tld"
        Classless-Static-Route-Microsoft Option 249, length 24: (192.168.70.0/24:192.168.99.254),(192.168.75.0/24:192.168.99.254),(10.0.0.0/24:192.168.99.254)
        Vendor-Option Option 43, length 7: 2.4.0.0.0.1.255

ป.ล. ฉันเกือบลืมส่วนสำคัญที่จำเป็นสำหรับการใช้การกำหนดค่าข้างต้นสำเร็จ มีการอธิบายไว้ในเอกสารของ Microsoft ที่ฉันอ้างถึง แต่ใครอ่านเอกสารบ้าง :) ตกลงลูกค้าควรได้รับการกำหนดค่าโดยไม่มี 'ใช้เกตเวย์เริ่มต้น' ในการเชื่อมต่อ VPN (ใน Windows มันอยู่ในคุณสมบัติของการเชื่อมต่อ -> เครือข่าย -> อินเทอร์เน็ตโปรโตคอลรุ่น 4 (TCP / IPv4) -> คุณสมบัติ -> ขั้นสูง -> การตั้งค่า IP ) สำหรับลูกค้าบางรายยังมีตัวเลือกที่เรียกว่า 'ปิดใช้งานการเพิ่มเส้นทางตามคลาส' - ต้องไม่ถูกกำหนดเนื่องจากจะปิดใช้งานฟังก์ชันการทำงานที่เราพยายามนำมาใช้อย่างชัดเจน


ฉันเข้าใจว่า L2TP แบบคลาสสิกห่อหุ้มแพ็กเก็ต PPP ผ่าน UDP ฉันอาจจะผิด แต่ฉันไม่คิดว่า DHCP รองรับ PPP โดยเฉพาะการส่งเส้นทางพิเศษ L2TP เวอร์ชัน 3 (ยังค่อนข้างใหม่ในเคอร์เนล linux) ช่วยให้คุณใส่เฟรมอีเธอร์เน็ตดังนั้นจึงอาจเป็นไปได้ที่นั่น แต่ฉันค่อนข้างมั่นใจว่าระยะทางอาจแตกต่างกันไปตามอุปกรณ์มือถือที่รองรับ
Matthew Ife

Matthew, ฉันไม่รู้วิธีตอบคำถามของคุณอย่างถูกต้องเนื่องจากคุณทำหลายสิ่งหลายอย่างให้กลายเป็นประโยคเดียว :) เรามาเริ่มด้วยสิ่งต่อไปนี้กันดีกว่า: การตั้งค่าที่ให้มานั้นใช้กับนักรบถนนหลายร้อยคน ดังนั้นมันจึงเป็นตัวอย่างการทำงาน คุณสามารถ Google สำหรับ DHCP ผ่าน PPP และอ่านเอกสารทางเทคนิคมากมายเกี่ยวกับวิธีการใช้งานโดย Cisco, Juniper และอื่น ๆ หากคุณไม่ต้องการดำดิ่งลงไปลองจินตนาการว่า L2TP นั้นห่อหุ้ม PPP ผ่าน UDP แล้ว PPP เป็นจุด โปรโตคอลแบบจุดต่อจุดที่คุณสามารถใช้ IP, DHCP เป็นโปรโตคอลผ่าน IP ดังนั้นเราจึงทำได้ดีที่นี่ :)
galaxy

1
นอกจากนี้มันค่อนข้างแปลกที่จะได้รับความคิดเห็นเช่นนี้เมื่อฉันรวมลิงก์ไปยังเอกสารทางเทคนิคของ Microsoft สำหรับ L2TP ซึ่งพวกเขาอธิบายวิธีตั้งค่าอย่างถูกต้องโดยใช้ DHCPINFORM ฉันสามารถเข้าใจได้เมื่อผู้คนไม่ต้องการอ่านคำตอบ (แม้ว่าจะมีไฟล์ config จากระบบการทำงาน) เนื่องจากมีงานวิจัยของใครบางคน แต่พูดว่า "ฉันไม่คิดว่า DHCP รองรับ PPP" เมื่อมีข้อกำหนดทางเทคนิคจาก ผู้สร้างโพรโทคอลที่ระบุว่านี่คือวิธีที่มันถูกออกแบบมานั้นแปลก
กาแล็

ดีที่จะอธิบายประเด็นของฉัน "DHCP ไม่ได้รับการสนับสนุนผ่าน PPP" ฉันหมายถึงว่าการกำหนดที่อยู่ IP เกิดขึ้นผ่านโปรโตคอลควบคุมการเชื่อมโยง PPP (ชี้ไปที่จุดไม่มีความคิดของที่อยู่ 'ออกอากาศ') ดังนั้นฉันคิดว่าคุณเข้าใจผิดในสิ่งที่ได้รับ ฉันเห็นตอนนี้สิ่งที่คุณหมายถึงคือ DHCPINFORM เกิดขึ้นภายในอุโมงค์หลังจากสร้างการเชื่อมต่อและไม่มีอะไรเกี่ยวข้องกับการเชื่อมต่อเริ่มต้น ฉันเห็นด้วยในขณะนี้ว่ารูปแบบนี้ใช้งานได้โดยให้ลูกค้าจะส่งข้อความ DHCPINFORM หลังจากการเชื่อมต่อถูกตั้งค่า
Matthew Ife

แม็ตธิวขอบคุณ :) ใช่เราไม่ได้ใช้ DHCP สำหรับการกำหนดที่อยู่ทำได้โดย IPCP (และไม่ใช่ LCP ตามที่คุณพูด แต่นี่ไม่เกี่ยวข้อง) อย่างไรก็ตามเอกสารทางเทคนิคของ Microsoft ระบุว่าไคลเอ็นต์ที่ถูกต้องควรส่งข้อความ DHCPINFORM พร้อมตัวเลือก 249 เพื่อรับ การกำหนดค่าเส้นทางและนี่คือสิ่งที่ฉันอธิบายในคำตอบของฉัน ดีใครสักคนแล้วลงมติคำตอบของฉันลงแม้ว่าจะทำงานคำตอบที่ถูกต้อง :)
กาแลคซี

1

ฉันไม่คิดว่าคุณสามารถผลักดันเส้นทางไปยังลูกค้าใน L2TP / IPSEC VPN คุณจะต้องทำการกำหนดค่าโดยตรงบนไคลเอนต์

ลูกค้ามือถือตัวใดที่คุณกำลังประสบปัญหา การป้อนข้อมูลบางอย่างง่ายขึ้นถ้าเรารู้ระบบปฏิบัติการและซอฟต์แวร์ที่คุณใช้อยู่

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