Чи можливо для L2TP VPN робити автоматичну конфігурацію маршруту для клієнта під час підключення?


13

Ми налаштували сервер VPN L2TP за допомогою цього підручника , все працює як шарм.

Єдине питання

  1. Ми не хочемо, щоб клієнт здійснював маршрутизацію всього трафіку за допомогою цієї VPN, лише певної підмережі, наприклад 10.0.0.0/20

  2. На Mac нам потрібно встановити маршрут вручну за допомогою команди, але для мобільних пристроїв, здається, немає способу це зробити?

Отже, чи можна настроїти клієнта автоматично для підмережі "10.0.0.0/20"?


Чи намагалися ви відключити на клієнті функцію "надіслати увесь трафік через VPN" або подібну опцію?
Берт

Відповіді:


33

Гаразд, це запитання задається знову і знову через Інтернет, і більшість випадків є (напів-) неправильна відповідь, що ви не можете виконати те, що було описано в початковому дописі. Дозвольте мені уточнити раз і назавжди :)

Коротка відповідь полягає в тому, що L2TP (і PPTP для цього питання) не мають можливості робити штовхання маршруту всередині протоколу, але це може бути досягнуто поза протоколом.

Оскільки L2TP є винаходом Microsoft, найкращим джерелом інформації є їх технічна документація (і вони, до речі, непогані). Технічний опис того, що я збираюсь пояснити нижче, можна знайти у розділі Адресація та маршрутизація VPN . Ключові слова для налаштування все правильно (якщо ви збираєтеся робити власне дослідження): DHCPINFORM та "безкласні статичні маршрути".

Перш за все, як це працює:

  1. клієнт підключається до VPN-сервера
  2. після успішної аутентифікації встановлюється захищений тунель
  3. після з'єднання клієнт використовує повідомлення DHCPINFORM, щоб запитувати параметр DHCP Classless Static Routes. Цей параметр DHCP містить набір маршрутів, які автоматично додаються до таблиці маршрутизації клієнта, що запитує ( я рабсько копіюю та вставляю цей рядок безпосередньо з документації Microsoft :))
  4. сервер VPN відповідає на це повідомлення відповідним набором маршрутів

Ну, є застереження:

  • є RFC-3442, що описує "DHCP безкласові статичні маршрути", і там зазначено, що код для цього варіанту - 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

PS Я майже забув істотну частину, необхідну для успішного використання вищевказаної конфігурації. Ну, це було описано в документах Microsoft, про які я згадував, але хто читав документацію? :) Добре, клієнти повинні бути налаштовані без "Використовувати шлюз за замовчуванням" на підключенні VPN (у Windows це властивості з'єднання -> Мережа -> Інтернет-протокол версії 4 (TCP / IPv4) -> Властивості -> Додатково -> Налаштування IP ). Для деяких клієнтів також є опція "Відключити додавання маршруту на основі класу" - вона повинна бути скасована, оскільки явно відключає функціонал, який ми намагаємося реалізувати.


Наскільки я розумію, класичний L2TP інкапсулює пакети PPP через UDP. Я можу помилитися, але я не думаю, що DHCP підтримується через PPP, зокрема надсилаючи додаткові маршрути. L2TP версія 3 (все ще досить нова в Linux Linux kernel) дозволяє вам інкапсулювати Ethernet-кадри, щоб це було можливо, але я впевнений, що пробіг може відрізнятись від того, наскільки добре це підтримується на мобільних пристроях.
Метью Іфе

Метью, я не знаю, як правильно вирішити своє питання, оскільки ти змішав стільки речей в одне речення :) Ну, почнемо з наступного: надана конфігурація працює над сотнями дорожніх воїнів, якими я керую. Отже, це робочий приклад. Ви можете Google за DHCP над PPP і прочитати багато технічної документації щодо того, як це реалізовано Cisco, Juniper тощо. Якщо ви не хочете занурюватися в нього, просто уявіть, що L2TP інкапсулює PPP через UDP, PPP - це пункт протокол до точки, де ви можете використовувати IP, DHCP - це протокол через IP, тому ми тут хороші :)
галактика

1
Крім того, досить дивно отримувати подібні коментарі, коли я включив посилання на технічну документацію Microsoft для L2TP, де вони описують, як правильно налаштувати речі за допомогою DHCPINFORM. Я можу зрозуміти, коли люди не хочуть читати відповідь (хоча вона включає конфігураційні файли з робочої системи), оскільки це чиєсь дослідження, але кажу: "Я не думаю, що DHCP підтримується через PPP", коли є технічна специфікація від творець протоколу, де він стверджує, що це так, як він був розроблений, начебто дивно.
галактика

Ну щоб уточнити мою точку "DHCP не підтримується через PPP", я маю на увазі, що присвоєння IP-адреси відбувається над протоколом управління зв'язком PPP (точка-точка не має поняття "широкомовної" адреси). Тож я думаю, ти неправильно зрозумів, до чого я потрапляв. Я бачу, що ви маєте на увазі, що DHCPINFORM виникає всередині тунелю після встановлення з'єднання і не має нічого спільного з початковим з'єднанням. Я згоден зараз, що ця схема працює, якщо клієнт надішле повідомлення DHCPINFORM після налаштування з'єднання.
Меттью Іфе

Метью, дякую :). Так, ми не використовуємо DHCP для присвоєння адреси, це робиться IPCP (а не LCP, як ви сказали, але це не має значення), однак у технічній документації Microsoft зазначено, що дійсний клієнт повинен надіслати повідомлення DHCPINFORM з Варіантом 249, щоб отримати конфігурація маршруту, і саме це я описав у своїй відповіді. Ну, хтось уже проголосував мою відповідь, хоча це працює, дійсна відповідь :)
галактика

1

Я не думаю, що ви можете просунути маршрут до клієнта в L2TP / IPSEC VPN. Вам доведеться виконати конфігурацію безпосередньо на клієнті.

З яким мобільним клієнтом у вас виникають проблеми? Простіше надати деякий вклад, якщо ми знаємо операційну систему та програмне забезпечення, яке ви використовуєте.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.