Возможно ли для L2TP VPN выполнить автоматическую настройку маршрута для клиента во время подключения?

13

В этом уроке мы настроили L2TP VPN-сервер , все работает как очаровательный.

Единственная проблема

  1. Мы не хотим, чтобы клиент маршрутизировал весь трафик, используя эту VPN, только определенную подсеть, например, 10.0.0.0/20.

  2. На Mac нам нужно установить маршрут вручную с помощью команды, но для мобильных устройств, кажется, нет способа сделать это?

Итак, можно ли для клиента автоматически настроить подсеть "10.0.0.0/20"?

linux vpn linux-networking ipsec l2tp Говард
источник
Вы пытались отключить на клиенте параметр «отправлять весь трафик через VPN» или аналогичный?
Берт

Ответы:

33

Хорошо, этот вопрос задают снова и снова через Интернет, и в большинстве случаев есть (полу) неправильный ответ, что вы не можете сделать то, что было описано в оригинальном посте. Позвольте мне уточнить это раз и навсегда :)

Краткий ответ - L2TP (и, в этом отношении, PPTP) не имеют средств для выполнения маршрутизации в протоколе, но это может быть достигнуто вне протокола.

Поскольку L2TP - это изобретение Microsoft, лучшим источником информации является их техническая документация (кстати, они довольно хороши). Техническое описание того, что я собираюсь объяснить ниже, можно найти по адресу VPN Addressing and Routing . Ключевые слова для правильной настройки (если вы собираетесь провести собственное исследование): 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) позволяет инкапсулировать кадры Ethernet, чтобы это было возможно там, но я уверен, что пробег может варьироваться в зависимости от того, насколько хорошо это поддерживается на мобильных устройствах.
Мэтью Ифе
Мэтью, я не знаю, как правильно ответить на ваш вопрос, так как вы смешали так много вещей в одном предложении :) Ну, давайте начнем со следующего: предоставленная конфигурация работает на сотнях воинов, которыми я руководлю. Итак, это рабочий пример. Вы можете использовать Google для DHCP через PPP и прочитать много технической документации о том, как это реализовано Cisco, Juniper и т. Д. Если вы не хотите углубляться в это, просто представьте, что L2TP инкапсулирует PPP через UDP, PPP - это точка. протокол «точка-точка», где вы можете использовать IP, DHCP - это протокол поверх IP, так что нам здесь хорошо :)
galaxy,
1
Кроме того, довольно странно получать такого рода комментарии, когда я включил ссылку на техническую документацию Microsoft для L2TP, где они описывают, как правильно настроить все, используя DHCPINFORM. Я могу понять, когда люди не хотят читать ответ (хотя он включает конфигурационные файлы из работающей системы), поскольку это чье-то исследование, но высказывание «Я не думаю, что DHCP поддерживается через PPP», когда есть техническая спецификация от создатель протокола, в котором говорится, что именно так он и был разработан, выглядит довольно странно.
галактика
Хорошо, чтобы прояснить мою мысль «DHCP не поддерживается через PPP», я имею в виду, что назначение IP-адреса происходит по протоколу управления соединением PPP (точка-точка не имеет понятия «широковещательный» адрес). Так что я думаю, вы не поняли, к чему я клонил. Теперь я понимаю, что вы имеете в виду, что DHCPINFORM происходит внутри туннеля после установления соединения и не имеет ничего общего с начальным соединением. Теперь я согласен, что эта схема работает, при условии, что клиент отправит сообщение DHCPINFORM после установки соединения.
Мэтью Ифе
Мэтью, спасибо :). Да, мы не используем DHCP для назначения адресов, это делается IPCP (а не LCP, как вы сказали, но это не имеет значения), однако в технической документации Microsoft говорится, что действительный клиент должен отправить сообщение DHCPINFORM с опцией 249, чтобы получить Конфигурация маршрута, и это именно то, что я описал в своем ответе. Ну, кто-то уже проголосовал за мой ответ, хотя это рабочий, действительный ответ :)
galaxy
1

Я не думаю, что вы можете протолкнуть маршрут к клиенту в L2TP / IPSEC VPN. Вам придется выполнить настройку непосредственно на клиенте.

С каким мобильным клиентом у вас проблемы? Проще предоставить некоторую информацию, если мы знаем операционную систему и используемое вами программное обеспечение.

pehrs
источник