L2TP VPN có thể thực hiện cấu hình tuyến đường tự động cho máy khách trong khi kết nối không?


13

Chúng tôi đã thiết lập máy chủ L2TP VPN với hướng dẫn này , mọi thứ hoạt động như một nét quyến rũ.

Vấn đề duy nhất là

  1. Chúng tôi không muốn khách hàng định tuyến tất cả lưu lượng truy cập bằng VPN này, chỉ một mạng con cụ thể, ví dụ: 10.0.0.0/20

  2. Trên Mac, chúng ta cần đặt tuyến theo cách thủ công bằng cách sử dụng lệnh, nhưng đối với thiết bị di động, dường như không có cách nào để làm như vậy?

Vì vậy, có thể tự động cấu hình cho máy khách cho mạng con "10.0.0.0/20" không?


Bạn đã thử vô hiệu hóa 'gửi tất cả lưu lượng truy cập qua VPN' hoặc tùy chọn tương tự trên máy khách chưa?
Bert

Câu trả lời:


33

OK, câu hỏi này được hỏi đi hỏi lại qua Internet và hầu hết thời gian có một câu trả lời (bán) không chính xác mà bạn không thể làm những gì được mô tả trong bài viết gốc. Hãy để tôi làm rõ nó một lần và mãi mãi :)

Câu trả lời ngắn gọn là L2TP (và PPTP cho vấn đề đó) không có phương tiện để thực hiện đẩy tuyến trong giao thức, nhưng nó có thể đạt được bên ngoài giao thức.

Vì L2TP là một phát minh của Microsoft, nên nguồn thông tin tốt nhất là tài liệu kỹ thuật của họ (và nhân tiện họ cũng khá giỏi về nó). Mô tả kỹ thuật về những gì tôi sẽ giải thích bên dưới có thể được tìm thấy tại Địa chỉ và định tuyến VPN . Các từ khóa để thiết lập mọi thứ đúng cách (nếu bạn sẽ thực hiện nghiên cứu của riêng mình) là: DHCPINFORM và "các tuyến tĩnh không có lớp".

Trước hết, cách thức hoạt động:

  1. một máy khách kết nối với máy chủ VPN
  2. Sau khi xác thực thành công, một đường hầm an toàn được thiết lập
  3. khách hàng sử dụng thông báo DHCPINFORM sau khi kết nối để yêu cầu tùy chọn DHCP Classless static Routes. Tùy chọn DHCP này chứa một tập hợp các tuyến đường được tự động thêm vào bảng định tuyến của máy khách yêu cầu ( Tôi thường xuyên sao chép và dán dòng này trực tiếp từ tài liệu của Microsoft :))
  4. máy chủ VPN trả lời tin nhắn đó với bộ tuyến thích hợp

Vâng, có một cảnh báo:

  • RFC-3442 mô tả "Các tuyến tĩnh không có lớp DHCP" và ở đó tuyên bố rằng mã cho tùy chọn này là 121. Microsoft đã quyết định phát minh lại bánh xe (như mọi khi) và sử dụng mã 249 cho tùy chọn này. Do đó, để hỗ trợ nhiều khách hàng hơn, chúng tôi cần phản hồi lại bằng cả hai mã

Tôi sẽ mô tả một cấu hình điển hình sử dụng hộp Linux là máy chủ VPN (bạn có thể định cấu hình máy chủ MS bằng liên kết đến tài liệu của Microsoft).

Để cấu hình các tuyến đường trên máy khách, chúng ta sẽ cần các thành phần sau:

  • L2TP / IPSEC (hoặc PPTP) = ví dụ, accel-ppp là một máy chủ L2TP / PPTP mã nguồn mở đẹp
  • Máy chủ DHCP = có rất nhiều, nhưng tôi sẽ mô tả cấu hình của dnsmasq

Sau đây là kết xuất của cấu hình accel-ppp đang hoạt động. Tôi đang cung cấp nó toàn bộ, nếu không sẽ khó để giải thích những gì đi đâu. Nếu bạn đã có VPN hoạt động, bạn có thể bỏ qua tệp cấu hình này và tập trung vào cấu hình DHCP được mô tả bên dưới.

[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 ~]# 
===

Tại thời điểm này, khách hàng của chúng tôi có thể kết nối qua L2TP (hoặc PPTP) và liên lạc với máy chủ VPN. Vì vậy, phần còn thiếu duy nhất là một máy chủ DHCP đang lắng nghe các đường hầm được tạo và phản hồi lại với các thông tin cần thiết. Dưới đây là một đoạn trích từ tệp cấu hình dnsmasq (Tôi chỉ cung cấp các tùy chọn liên quan đến 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 ~]#

Trong đoạn trích trên, chúng tôi đang đẩy các tuyến 192.168,70.0 / 24, 192.168.75.0/24 và 10.0.0.0/24 qua 192.168.99.254 (máy chủ VPN).

Cuối cùng, nếu bạn đánh hơi lưu lượng mạng (ví dụ: trên máy chủ VPN), bạn sẽ thấy một cái gì đó giống như sau cho phản hồi trên thông báo 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

PS Tôi gần như đã quên một phần thiết yếu cần thiết để sử dụng thành công cấu hình trên. Vâng, nó đã được mô tả trong các tài liệu Microsoft mà tôi đã đề cập, nhưng ai đọc tài liệu này? :) OK, khách hàng nên được định cấu hình mà không cần 'Sử dụng cổng mặc định' trên kết nối VPN (trên Windows, thuộc tính của kết nối -> Mạng -> Giao thức Internet Phiên bản 4 (TCP / IPv4) -> Thuộc tính -> Nâng cao -> Cài đặt IP ). Trên một số khách hàng cũng có một tùy chọn gọi là 'Vô hiệu hóa bổ sung tuyến đường dựa trên lớp' - nó phải được bỏ đặt vì nó vô hiệu hóa rõ ràng chức năng mà chúng tôi đang cố gắng thực hiện.


Theo hiểu biết của tôi, L2TP cổ điển gói gọn các gói PPP qua UDP. Tôi có thể sai nhưng tôi không nghĩ DHCP được hỗ trợ qua PPP, đặc biệt là gửi thêm các tuyến. L2TP phiên bản 3 (vẫn còn khá mới trong vùng hạt nhân linux) cho phép bạn đóng gói các khung ethernet để có thể ở đó, nhưng tôi khá chắc chắn rằng số dặm có thể thay đổi tùy theo mức độ được hỗ trợ trên các thiết bị di động.
Matthew Ife

Matthew, tôi thực sự không biết làm thế nào để giải quyết câu hỏi của bạn một cách chính xác vì bạn đã trộn quá nhiều thứ vào một câu :) Chà, hãy bắt đầu với những điều sau: cấu hình được cung cấp đang hoạt động trên hàng trăm chiến binh đường phố mà tôi đang giám sát. Vì vậy, nó là một ví dụ hoạt động. Bạn có thể Google cho DHCP qua PPP và đọc rất nhiều tài liệu kỹ thuật về cách thức triển khai của Cisco, Juniper, v.v. Nếu bạn không muốn đi sâu vào nó, chỉ cần tưởng tượng rằng L2TP đóng gói PPP qua UDP, PPP là một điểm giao thức điểm mà bạn có thể sử dụng IP, DHCP là giao thức qua IP, vì vậy chúng tôi rất tốt ở đây :)
galaxy

1
Ngoài ra, thật lạ khi nhận được loại bình luận này khi tôi đưa một liên kết đến tài liệu kỹ thuật của Microsoft cho L2TP nơi họ mô tả cách thiết lập mọi thứ đúng cách bằng DHCPINFORM. Tôi có thể hiểu khi mọi người không muốn đọc câu trả lời (mặc dù nó bao gồm các tệp cấu hình từ hệ thống đang hoạt động) vì đó là nghiên cứu của ai đó, nhưng nói rằng "Tôi không nghĩ DHCP được hỗ trợ qua PPP" khi có thông số kỹ thuật từ người tạo ra giao thức trong đó tuyên bố rằng đây là cách nó được thiết kế là lạ.
thiên hà

Để làm rõ quan điểm của tôi "DHCP không được hỗ trợ qua PPP", ý tôi là việc gán địa chỉ IP xảy ra qua giao thức kiểm soát liên kết PPP (điểm đến điểm không có khái niệm về địa chỉ 'quảng bá'). Vì vậy, tôi nghĩ rằng bạn đã hiểu sai những gì tôi đang nhận được. Bây giờ tôi hiểu ý của bạn là DHCPINFORM xảy ra bên trong đường hầm sau khi thiết lập kết nối và không liên quan gì đến kết nối ban đầu. Bây giờ tôi đồng ý rằng chương trình này hoạt động, cung cấp cho khách hàng sẽ gửi tin nhắn DHCPINFORM sau khi kết nối được thiết lập.
Matthew Ife

Mathew, cảm ơn :). Có, chúng tôi không sử dụng DHCP để gán địa chỉ, được thực hiện bởi IPCP (chứ không phải LCP như bạn đã nói, nhưng điều này không liên quan), tuy nhiên, tài liệu kỹ thuật của Microsoft tuyên bố rằng một khách hàng hợp lệ nên gửi tin nhắn DHCPINFORM với Tùy chọn 249 để nhận cấu hình tuyến đường, và đây chính xác là những gì tôi mô tả trong câu trả lời của mình. Chà, ai đó đã bỏ phiếu cho câu trả lời của tôi mặc dù đó là một câu trả lời hợp lệ :)
galaxy

1

Tôi không nghĩ rằng bạn có thể đẩy tuyến đến máy khách trong L2TP / IPSEC VPN. Bạn sẽ phải thực hiện cấu hình trực tiếp trên máy khách.

Bạn đang gặp rắc rối với khách hàng di động nào? Việc cung cấp một số đầu vào sẽ dễ dàng hơn nếu chúng tôi biết hệ điều hành và phần mềm bạn đang sử dụng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.