Настройка IPSec L2TP VPN-сервера под Ubuntu для работы с Windows-клиентами (перевод)

Перевод статьи «Setting Up an IPSec L2TP VPN server on Ubuntu for Windows clients»

У меня на работе развернута windows-сеть (Windows-сервер и windows-рабочие станции). Выход в интернет осуществляется через Ubuntu-сервер, на котором выставлен внешний ip-адрес. Мне захотелось дать возможность определённым пользователям соединяться с офисной сетью через VPN в то время, когда они находятся вне офиса. Причем, организовать это так, чтобы клиентам не требовалось никакого дополнительного программного обеспечения на их мобильных компьютерах, кроме тех средств, которые стандартно присутствуют на рабочей станции под windows. Наш Windows-сервер имел лишь 1 сетевой интерфейс с приватным ip-адресом, поэтому простое решение с помощью RRAS мне не подходило.

Решая поставленную задачу я прочитал множество онлайновой документации и различных «how-to». Ссылки на некоторые из них я привел в конце этой статьи. Как оказалось, более всего мне пригодилась информация с сайта Jacco de Leeuw.

Я внёс ряд корректировок, чтобы адаптировать найденные в интернете инструкции для использования в конкретных условиях моей офисной сети. Тут я публикую пошаговое руководство, которое родилось в процессе решения задачи настройки VPN-сервера, работающего с родными VPN-клиентами в Windows.

VPN был поднят на пограничном сервере с установленной Ubunto Server 8.04. На этой машине присутствовало 2 сетевых интерфейса, один с внешним ip-адресом и смотрящий в интернет, второй с внутренним ip-адресом и смотрящий в офисную сеть. Кроме устанавливаемого VPN, данный сервер уже использовался в качестве офисного прокси-сервера. Предполагается, что приведённые в этой статье команды выполняются с привилегиями root'а, а так же, что Вы достаточно квалифицированны, чтобы знать как их получить и для каких действий эти привилегии требуются.

Стандартные VPN-клиенты в Windows могут использовать как PPTP так и IPSec L2TP. В этом руководстве мы осветим вопрос использования IPSec L2TP. Сначала мы настроим VPN с использованием шифрования по заранее известному серверу и клиентам ключу (PSK — Pre-shared Key). Убедившись, что для такого простого случая схема работает, перейдём к использованию сертификатов и службы Windows Server Certificate Authority (CA), присутствующей по-умолчанию на windows-сервере. Кроме этого, Мне хотелось настроить аутентификацию пользователей на основе их паролей в Windows-домене, при условии что они являются членами определённой группы.

Замечание: В этом руководстве внешний адрес ubuntu-сервера, к которому будут соединяться vpn-клиенты — 12.34.56.78. Шлюзом по-умолчанию для доступа в интернет у этого сервера принят ip 12.34.56.1, на интерфейсе, смотрящем во внутреннюю офисную сеть, используется ip 192.168.1.1. При осуществлении настроек изменяйте эти адреса на те, которые приняты в вашей сетевой среде.

1) Установка и настройка Openswan

Этот пакет позволяет создавать IPSec SA соединения между Windows-клиентом и VPN-сервером.

• 1.1
  Настройте apt на universe-репозиторий.
  # nano /etc/apt/sources.list
  Раскоментируйте строки, соответствующие репозитарию main universe и security universe.
  прим. переводчика: Строки должны выглядеть примерно так:
  deb http://ru.archive.ubuntu.com/ubuntu/ hardy universe
deb http://ru.archive.ubuntu.com/ubuntu/ hardy-security universe
  
• 1.2
  Обновите ифнормцию о пакетах и установите openswan.
  # apt-get update
# atp-get install openswan
  При установке НЕ включайте оппортунистическое шифрование (OE).
  При установке НЕ создавайте RSA пар публичных/приватных ключей.
  
• 1.3
  # cp /etc/ipsec.d/examples/l2tp-psk.conf /etc/ipsec.d/l2tp-psk.conf
  # nano /etc/ipsec.d/l2tp-psk.conf
  Установите
  left=12.34.56.78 [поставить внешний ip-адрес машины, с которой удалённые пользователи будут устанавливать vpn-соединение]
  leftnexthop=12.34.56.1 [поставить ip-адрес основного шлюза, на который смотрит маршрут по-умолчанию на конфигурируемом vpn-сервере]
  
• 1.4
  # nano /etc/ipsec.conf
  Добавить строку: include /etc/ipsec.d/l2tp-psk.conf .
  Для правильной работы клиентов под Windows Vista нужно определить, с каких пулов приватных ip-адресов можно соединяться, а с каких нет. Т.к. в моём случае внутренняя сеть компании имеет адресацию 192.168.1.0/24, я отношу её к не разрешённым:
  virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
  
• 1.5
  # nano /etc/ipsec.secrets
  Добавить строку: 12.34.56.78 %any: "yourSharedPSK!"
  
• 1.6
  # /etc/init.d/ipsec restart
  

К этому моменту vpn-сервер должен запуститься и ждать соединений на портах udp/500 и udp/4500. Проверить это можно с помощью команды
# netstat -antu

2) Проверка работы IPSec

Давайте проверим, правильно ли функционирует часть системы, ответственная за IPSec.

• 2.1
  В настройках фаервола в цепочке INPUT нужно открыть доступ к портам udp/500 и udp/4500 внешнего ip-адреса VPN-сервера. Я так же разрешил пропускать пакеты, относящиеся к протоколу 50 (ESP). Как конкретно это делается, зависит от организации настроек вашего фаервола. Мои правила в таблице FILTER выглядят так:
  -A INPUT -p 50 -j ACCEPT
-A INPUT -p udp -d 12.34.56.78 --dport 500 -j ACCEPT
-A INPUT -p udp -d 12.34.56.78 --dport 4500 -j ACCEPT
  
• 2.2
  Настроем VPN-клиент на Windows XP для быстрого тестирования.
  Control Panel > Network Connections > File > New connection...
  Выбираем "Connect to the network at my workplace",
  выбираем "Virtual Private Network connection",
  имя компании: "Your Company",
  выбираем "Do not dial the initial connection",
  имя или ip-адрес узла: 12.34.56.78,
  После создания соединения левый щелчёк на его значке, Properties > Security > IPSec Settings > Check "Use pre-shared key for authentication",
  Pre-shared key: yourSharedPSK!,
  Далее Properties > Network > Type of VPN: L2TP IPSec VPN.
  Если не хотите чтобы маршрут по-умолчанию смотрел в создаваемый тоннель, отметьте
  Properties > Networking > TCP/IP > Properties > Advanced... > General > уберите галочку "Use default gateway on remote network".
  
• 2.3
  Контролируем вывод в лог-файл /var/log/auth.log
# tail -f /var/log/auth.log
  И пытаемся инициировать созданное соединение с Windows-машины (логин и пароль произвольные).
  

В конец концов соединение установить не удастся, но в лог-файле вы должны увидеть зафиксированную попытку подключения к VPN-серверу с состоянием
STATE_QUICK_R2: IPsec SA established
Эта строчка в логе говорит, что серверная часть IPSec правильно работает с шифрованием общим ключём (PSK).

3) Установка демона xl2tpd

IPSec — это всего лишь система шифрования, которую windows-клиенты используют при соединении по L2TP протоколу. Чтобы сервер мог обслуживать L2TP соединения, нам нужен работающий L2TP-демон.

• 3.1
  Устанавливаем демон xl2tpd. Этот пакет в данный момент находится в репозитарии universe.
  # apt-get install xl2tpd
  
• 3.2
  Редактируем файл /etc/xl2tpd/xl2tpd.conf, чтобы он содержал, как минимум, следующее:
  [global]
ipsec saref = yes
listen-addr = 12.34.56.78

[lns default]
ip range = 192.168.1.10-192.168.1.20
local ip = 192.168.1.1
;require chap = yes
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
  Параметр ip range, должен определять диапазон ip-адресов вашей внутренней сети которые могут быть назначены присоединившимся vpn-клиентам. Тут мы отключаем как CHAP так и PAP-аутентификацию, это нормально т.к. в дальнейшем мы активизируем возможность аутентификации по MS-CHAP v2.
  
• 3.4
  Редактируем /etc/ppp/chap-secrets.
  # nano /etc/ppp/chap-secrets
  Приводим его к следующему виду:
  #client server secret IP addresses
username l2tpd "password" 192.168.1.1/24
l2tpd username "password" 192.168.1.1/24
  
  Обратите внимание, что имя l2tpd должно совпадать с тем, что вы определили в предыдущем файле в поле name. Вы можете использовать эти данные для тестирования CHAP-аутентификации, правда для этого предыдущем файле /etc/xl2tpd/xl2tpd.conf нужно заменить строку refuse chap = yes на require chap = yes.
  
• 3.5
  Настало время добавить дополнительные правила к настройкам вашего фаервола. Некоторые источники, на которые я ссылаюсь в конце данного руководства, настоятельно рекомендуют проявить тут бдительность, потому что если вы откроете порт xl2tpd демона всему миру, то любой человек получит возможность совершать попытки аутентификации без использования IPSec. Самый простой вариант — просто разрешить входящие соединения на порт udp/1701, но будет гораздо благоразумнее требовать, чтобы эти соединения были с задействованным IPSec. Моё правило фаервола выглядит так:
  -A INPUT -m policy --dir in --pol ipsec -p udp --dport 1701 -j ACCEPT
  Оно пропускает L2TP-трафик ТОЛЬКО если он инкапсулирован в пакеты IPSec. Самое удачное описание того, как IPSec (NETKEY) работает с фаерволом iptables, я нашел в этом посте Nigel Metheringham.
  
• 3.6
  Я обнаружил, что при установке xl2tpd присутствует маленький баг. xl2tpd ожидает, что файл l2tp-control должен находиться в /var/run/xl2tpd/, однако такой директории при установке не создаётся. Поэтому мне пришлось добавить несколько строк в /etc/init.d/xl2tpd после секции с включением установок по умолчанию:
  if !([ -f /var/run/xl2tpd/l2tp-control ]); then
mkdir -p /var/run/xl2tpd
touch /var/run/xl2tpd/l2tp-control
fi
  
• 3.7
  И последнее, что нам может понадобиться изменить в настройках фаервола для использования xl2tpd (если мы хотим точнее разграничить доступ). Когда L2TP-соединение установилось, оно создаёт на VPN-сервере соответствующий ppp# интерфейс. Нам нужно разрешить или скорректировать маршрутизацию данных через такие интерфейсы.
  -A FORWARD -i ppp+ -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
  

Примечание переводчика: Если в Вашей инфраструктуре отсутствует windows-домен или же целью является создание VPN-сервера, для нескольких человек, то возможно, CHAP-аутентификация и IPSec на основе PSK — это всё что вам нужно. В этом случае можно прекратить дальнейшее чтение и приступить к развертыванию и настройке VPN-сервера, используя вышеизложенный материал. Если всё же задача требует использования сертификатов и настройки авторизации удалённых VPN-клиентов в имеющемся Windows-домене, то дальнейшая информация, скорее всего, окажется для вас полезной.

4) Добавление Ubuntu-сервера в домен Active Directory

Я хотел, чтобы аутентификация происходила централизовано на основе данных Windows AD, а НЕ через файл /etc/ppp/chap-secrets.

• 4.1
  # apt-get install smbclient
# apt-get install winbind
  
• 4.2
  Проверяем, что в /etc/resolv.conf прописан ваш DNS-сервер, в котором присутствуют записи об AD-инфраструктуре. Если вы не сделали этого ранее, добавьте A и PTR запись для машины VPN-сервера.
  
• 4.3
  # apt-get install krb5-user (включает krb5-config)
  Kerberos-сервера вашего реалма: windowsserver.example.local
  Административные сервера вашего реалма: windowsserver.example.local
  
• 4.4
  Редактируем /etc/samba/smb.conf (если не нужно специальных настроек, остальное можно оставить по-умолчанию)
  workgroup = EXAMPLE
interfaces = eth0 lo
bind interfaces only = true
security = ADS
realm = EXAMPLE.LOCAL
password server = windowsserver.example.local
idmap uid = 10000-20000
idmap gid = 10000-20000
  
• 4.5
  Редактируем /etc/krb5.conf (Думаю, записи в этом файле чувствительны к регистру. Тут привожу только строки, значения которых я изменил.)
  default-realm = EXAMPLE.LOCAL
[REALMS]
EXAMPLE.LOCAL = {
kdc = windowsserver.example.local
admin_server = windowsserver.example.local
}
  
• 4.6
  Выполнить
  # /etc/init.d/winbind restart
  Замечание: перед выполнение следующих команд убедитесь, что показания часов на Windows-сервере и VPN-сервере отличаются менее чем на 5 минут.
  
• 4.7
  Выполнить
  # net ads join -U Administrator
  Эта команда добавляет сервер с Ubuntu в домен Windows. Чтобы добавление в домен было успешным, мне пришлось убедиться, что в /etc/hosts присутствует доменное имя машины в формате FQDN.
  
• 4.8
  # net ads testjoin
  Эта команда позволяет проверить правильность добавления VPN-сервера в домен.
  

5) Настраиваем xl2tpd/ppp для аутентификации клиентов в windows-домене

Редактируем /etc/ppp/options.xl2tpd, добавляем:
require-mschap-v2
# We can enable MPPE for additional encryption, but all this should be coming over IPSec
#anyway
# require-mppe-128
ms-dns 192.168.1.3
ms-dns 192.168.1.4
# The following lines let the authentication occur against the Windows domain, and require
# the user to be a member of the 'VPN Users' group on the 'EXAMPLE' domain.
plugin winbind.so
ntlm_auth-helper '/usr/bin/ntlm_auth --helper-protocol=ntlm-server-1 --require-membership-of="EXAMPLE\\VPN Users"'

После этого VPN-сервер может сверять аутентификационные данные в домене Windows вместо использования файла /etc/ppp/chap-secrets.

6) Использование сертификатов вместо PSK-ключа

Предполагается, что у вас уже есть настроенный сервис сертификатов на windows-сервере. Я сильно не буду вдаваться в подробности, этого вопроса.

6.1) Создание сертификата для VPN-сервера

• 6.1.1
  # openssl req -new -out vpn.example.com.pem
Enter PEM pass phrase:
Country: US
State: State
Locality: City Name
Organization: Your Company Name
OU:
CN: vpn.example.com
E-mail:
Challenge password:
Optional company name:

# mv vpn.example.com.pem /etc/ssl/private
# chmod 640 /etc/ssl/private/vpn.example.com.pem
  
• 6.1.2
  Загрузите созданный сертификат в службу сертификатов на windows-сервере.
  На сервере правый щелчёк мышью, All Tasks > Submit new request... и укажите путь к файлу vpn.example.com.pem, который был создан на предыдущем шаге. Выберите Pending Requests. Правый щелчек на Requests, All Tasks > Issue. В Issued Certificates откройте сертификат. Details tab > Copy to File... Выберите DER encoded binary X.509 (.cer). Точно так же экспортируйте сертификат для CA-машины (но не файл ключа!), для этого можно использовать mmc (Microsoft Management Console). Скопируйте оба сертификата на ваш VPN-сервер.
  
• 6.1.3
  # openssl x509 -inform DER -in windowsserver.example.local.cer -outform PEM -out windowsserver.example.local.pem
  Эта команда преобразует DER-шифрованный файл в .PEM файл.
  
• 6.1.4
  # cp windowsserver.example.local.pem /etc/ipsec.d/cacerts
  Для проверки IPSec'у должен быть известен публичный ключь CA-машины.
  
• 6.1.5
  # openssl x509 -inform DER -in vpn.example.com.cer -outform PEM -out vpn.example.com.pem
# cp vpn.example.com.pem /etc/ipsec.d/certs
  Подключаем сгенерированный для VPN-сервера сертификат и делаем возможным для openswan'а (IPSec) использовать его.
  

6.2) Настраиваем openswan на использование сертификатов вместо PSK-ключей

• 6.2.1
  # cp /etc/ipsec.d/examples/l2tp-cert.conf /etc/ipsec.d/l2tp-cert.conf
  
• 6.2.2
  Редактируем /etc/ipsec.conf.
  Заменяем l2tp-psk.conf на l2tp-cert.conf.
  Для правильной работы клиентов под Windows Vista нужно определить, с каких пулов приватных ip-адресов можно соединяться, а с каких нет. Т.к. в моём случае внутренняя сеть компании имеет адресацию 192.168.1.0/24, я отношу её к не разрешённым:
  virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
  
• 6.2.3
  Редактируем /etc/ipsec.d/l2tp-cert.conf. Похоже, что Vista требует установку параметра leftid.
  left=12.34.56.78
leftnexthop=12.34.56.1
leftid=@vpn.example.com
leftcert=/etc/ipsec.d/certs/vpn.example.com.pem
  
• 6.2.4
  # openssl req -new -keyout vpn.example.com.pem
  PEM passphrase: passphraseToAccessFile
  Эта команда заставляет openssl вывести наш приватный ключь в файл.
  
• 6.2.5
  # mv vpn.example.com.pem /etc/ipsec.d/private/vpn.example.com.pem
  Переносим этот приватный ключь в место, где IPSec (openswan) может получить к нему доступ.
  
• 6.2.6
  Отредактировать /etc/ipsec.secrets, добавить туда приватный ключ, ассоциированный с нашим сетрификатом. Закоментируйте ранее вставленную нами строчку строчку с PSK-ключём и добавьте следующее (включая двоеточее):
  :RSA vpn.example.com.pem "passphraseToAccessFile"
  
• 6.2.7
  # /etc/init.d/ipsec restart
  

6.3) Настраиваем windows-клиенты для работы с сертификатами

Прежде всего, нам нужно создать сертификат для windows-машины. На Windows XP Pro, присоединенной к домену, это предельно простая процедура. Я думаю, что вы даже сможете самостоятельно установить сертификаты на машины. Это выглядит примерно так:
Start > Run > mmc > File > Add/Remove Snap-in... > Add... > Certificates > Select Computer account > Local computer > Close > OK
Highlight Certificates > Personal, Right-click > All Tasks > Request New Certificate...
Тем не менее, к несчастью, мне пришлось иметь дело с несколькими машинами под Windows XP Home, и там пришлось идти другим путём. Пришлось скачивать Windows Server 2003 SP1 Administration Tools Pack (Adminpak) KB304718. Оттуда можно взять файлы certreq.exe, certutil.exe, certcli.dll, и certadm.dll, и скопировать на другие машины, где нужно проводить настройку.

• 6.3.1
  Создайте файл req.inf:
  [NewRequest]
Subject="CN=foo.example.com,C=US"
KeyLength=2048
MachineKeySet=TRUE
Silent=TRUE
  
• 6.3.2
  Запустите в командной строке
  > certreq.exe -new req.inf Request.pem
  Скопируйте файл Request.pem на CА(windows-сервер), подпишите его там, и создайте сертификат. Проверьте его параметры (кому, кем и когда выдан) и сохраните его в файл. Переместите сертификат обратно на машину, где создавался .pem-файл. Так же переместите на эту машину сертификат CA-машины (windows-сервера) (именно сертификат, а не приватный ключ). Нужно установить оба сертификата в хранилище сертификатов локального компьютера. Для этого в командной строке выполните примерно следующее:
  certutil.exe -encode Issued.cer Issued.pem
certutil.exe -addstore "root" windowsserver.example.local.cer
certreq.exe -accept Issued.pem
  Это помещает Windows CA в папку Trusted Root (доверенных корневых сертификатов) и принимает к использованию сертификат, который мы запрашивали и подписывали на CA ранее.
  Вы должны выполнять эти команды с администраторскими правами. Они же работают и на Windows Vista. Но возможно, что утилиты certutil.exe и т.п. отличаются версиями на Windows XP и Vista.

После выполнения этих операций на windows-рабочей станции, у неё должна появиться возможность соединяться с VPN-сервером без использования PSK-ключа.

7) Всё готово!

VPN будет работать, даже если клиенты пытаются соединиться, находясь за NAT-маршрутизатором. Но только с оговоркой, что внутренняя адресация в подсети за NAT-ом, откуда они соединяются, должна отличаться от адресации во внутренней сети вашей компании. Скажем, если во внутренней сети вашей компании используется адресация 192.168.1.0/24, а пользователь пытается соединиться с компьютера из удалённой сети, включающей этот диапазон ip-адресов, то у него ничего не получится. Потому, что его Windows-машина не будет знать как маршрутизировать пакеты. Например, пакет для 192.168.1.100 должен ли направляться через тоннель в удалённую сеть компании или же машине в локальной сети клиента?
Ещё одно замечание. Я думаю, что два удалённых клиента не смогут одновременно соединиться с VPN-сервером, если они оказались за одним и тем же NAT'ом.
Очевидно, что я тут представил очень короткое практическое руководство по настройке VPN и IPSec и не углублялся в детали, и в теорию, как всё это на самом деле работает. Для получения дополнительной информации, вам следует самостоятельно изучить источники, на которые я ссылаюсь в конце статьи. И если вы знаете лучший способ, как поднять корпоративный VPN, сообщите мне о нём. Мой e-mail находится в самом конце статьи.

Надеюсь, что у вас всё заработает!

Некоторые ссылки на первоисточники

www.jacco2.dds.nl/networking/openswan-l2tp.html
support.real-time.com/open-source/ipsec/index.html
koeppe-net.de/l2tp-howto.txt
www.members.optushome.com.au/~wskwok/poptop_ads_howto_1.htm
www.isaserver.org/img/upl/vpnkitbeta2/xpvpnclient.htm
www.jacco2.dds.nl/networking/certutil.html
lists.openswan.org/pipermail/users/2005-August/006101.html

Я надеюсь, кому-нибудь мой труд окажется полезным. Если в тексте вы найдёте ошибки, сообщите мне, и я их исправлю.
В. Гайлспи (W. Gillespie), (wgillespie, es2eng.com)

Последнее обновление 2009-07-17.