IPsec L2TP VPN server/ru

Многие операционные системы поддерживают L2TP/IPsec VPN "из коробки". Объединяя службы конфиденциальности и аутентификации IPsec (безопасность Интернет-протокола), сетевое туннелирование протокола туннелирования второго уровня (L2TP) и идентификацию пользователя через pppd, администраторы могут создавать VPN-сети на множестве разнородных систем. Это позволяет настроить VPN на Android, Windows, Linux, MacOS и других операционных системах без использования какого-либо коммерческого ПО.

Введение
IPsec/L2TP – повсеместно используемый VPN протокол, применяемый в Windows и других операционных системах. Все версии Windows, начиная с Windows 2000, имеют встроенную поддержку этого протокола и не требуют сторонних клиентов (например, OpenVPN), что делает его более удобным. Однако, значительно сложнее настроить серверную сторону на Linux, поскольку задействованы как минимум 3 слоя: IPsec, L2TP и PPP.


 * 1) IPsec обеспечивает конфиденциальность сетевого соединения и авторизации клиента (системы)
 * 2) С L2TP туннель настроен так, что VPN трафик прозрачно проходит через IPsec
 * 3) PPP (протокол точка-точка) контролирует авторизацию пользователей

Это руководство не охватывает установку DHCP, RADIUS, Samba или Инфраструктуры Открытых Ключей (PKI). Оно также совсем не объясняет, как настраивать Linux-клиентов, хотя этот шаг может быть довольно легко получен из руководства. Будет освещена часть конфигурации Windows-клиентов с целью устранения неполадок в настройке сервера.

Условные обозначения
В этом руководстве будут использованы следующие условные обозначения (пример настроек):


 * Домен – example.com
 * Имя сервера – vpn.example.com
 * Имя файла сертификата ЦС –
 * Сертификат сервера –
 * Ключ сервера –
 * Сертификат клиента –
 * Ключ клиента –

IPsec
Первый и самый сложный уровень для настройки – IPsec. Заметим, что IPsec – одноранговая сеть, таким образом, в её терминологии клиент называется инициатор, а сервер – ответчик.

Windows использует IKEv1. Существуют 3 реализации IPsec в Portage: ipsec-tools (racoon), LibreSwan и strongswan.

В следующих разделах объясняются различные конфигурации. Для каждого варианта документируется
 * как использовать PSK для авторизации и
 * как использовать сертификаты для авторизации

Выберете один из вариантов (PSK или сертификаты). При использовании авторизации на основе сертификата предполагается, что нужные сертификаты уже доступны.

Вариант 1: ipsec-tools (racoon)
ipsec-tools наименее функционален, но для тех, кто пришёл из *BSD, он может быть более близок. Однако, в отличие от *BSD, Linux не использует отдельный интерфейс для IPsec.

После установки ipsec-tools необходимо создать несколько файлов. Для начала создадим каталоги, в которых они будут хранится:

Настройка PSK в ipsec-tools
Сначала создадим PSK файл. Он будет содержать уникальный ключ, который будет использоваться для авторизации между компьютерами.

Каждая запись в PSK файле состоит из идентификатора и ключа. Windows идентифицирует себя посредством полного имени домена (FQDN). Ключ должен быть обозначен как строка или шестнадцатеричное число, начинающееся с 0x. В любом случае, содержимое (сам ключ) – полностью в выборе администратора:

В файле PSK файл обозначается через опцию  :

Настройка ipsec-tools с использованием сертификата
Скопируйте, и  в. Убедитесь, что недоступен для всех пользователей.

Далее, обновите конфигурацию в файле, добавив эти файлы в разделе :

Устранение неполадок с ipsec-tools
Когда возникают проблемы, этот раздел может дать несколько указаний в их решении.

Создание политик безопасности и NAT
Опция  должна заставить racoon создавать для нас нужную Политику Безопасности. Однако, в присутствие NAT (хотя бы, если сервер находится за NAT) он сделает это совсем не так, как хотелось бы. Таким образом, если трафик не проходит по туннелю, политика безопасности должна быть определена вручную.

Политика создаётся в файле :

Заметим, что хотя эта политика безопасности полагает, что мы хотим защитить "весь" L2TP трафик, проходящий к серверу и от него, если нет Ассоциации Безопасности, трафик не будет защищён и будет проходить через Интернет по обычному (неавторизованному/незашифрованному) пути, он не будет пропущен только потому, что нет Ассоциации Безопасности.

Вариант 2: LibreSwan
LibreSwan – ответвление от Openswan (который сам является ответвлением от FreeS/WAN). LibreSwan действительно раздвоился с сохранением настоящих разработчиков Openswan, однако после того, как они покинули Xelerance, спор о названии "Openswan" перерос в судебный иск, после которого было принято имя LibreSwan.

Желательно иметь каждую настройку VPN в своём собственном файле, что может быть сделано раскомментированием последней строки в :

Обход NAT установлен по умолчанию в файле конфигурации LibreSwan, таким образом никаких особых этапов настройки не требуется.

Настройка PSK в LibreSwan
Должен быть создан общий ключ. Он может быть задан строкой в кавычках или шестнадцатеричным числом. В следующем примере  должен быть заменён на IP-адрес сервера. Можно использовать доменное имя, но оно не рекомендовано разработчиками LibreSwan. Опция  позволяет любым клиентам использовать этот PSK.

Затем создайте :

Настройка LibreSwan с использованием сертификата
LibreSwan требует, чтобы Network Security Services (NSS) были правильно сконфигурированы и использованы для управления сертификатами. Чтобы было проще выполнить настройку, необходимо создать пакет PKCS#12, содержащий секретный ключ сервера, его сертификат и сертификат ЦС.

Затем пакет может быть импортирован в базу данных NSS:

Конфигурационные файлы LibreSwan будут ссылаться на псевдоним импортированных объектов. Используйте и, чтобы его узнать.

В приведённом примере  использован как псевдоним, полученный с помощью команды.

Здесь  – псевдоним, полученный с помощью команды.

Вариант 3: strongSwan
strongSwan – это ответвление от FreeS/WAN (хотя большая часть кода была заменена).

Что касается strongSwan 5.0, обход NAT является автоматическим, ничего настраивать не требуется.

strongSwan не создаёт файл, поэтому его нужно создать:

Настройка PSK в strongSwan
Должен быть создан общий ключ. Он может быть задан строкой в кавычках или шестнадцатеричным числом. В следующем примере  должен быть заменён на IP-адрес сервера. Опция  означает, что любой клиент может авторизоваться, используя этот PSK.

Далее отредактируйте как показано ниже:

Когда и left, и right заданы как , strongSwan подразумевает, что локальный компьютер – left.

Настройка strongSwan с использованием сертификата
Сертификаты и ключи должны быть скопированы в нужную папку:

Далее, укажите strongSwan использовать открытые ключи для авторизации:

Наконец, обновите файл как показано ниже:

Как и раньше, когда и left, и right равны , strongSwan подразумевает, что локальный компьютер – left.

Сквозной проход IPsec / повреждённый NAT
В предыдущих версиях strongSwan сквозной проход IPsec не казался рабочим. Он возвращал "cannot respond to IPsec SA request because no connection is known" или (со сложным редактирование конфигурационного файла) ошибку INVALID_HASH_INFORMATION. Такого не может быть со strongSwan версии 5.0 и выше.

Устранение неполадок со стандартным IPsec
С IPsec нелегко иметь дело. Этот раздел даёт несколько указаний на общие проблемы и ошибки.

Сервер за NAT
Когда сервер находится за NAT (преобразование сетевых адресов), что обычно бывает в случае, если сервер размещается за домашним роутером, некоторые специальные указания могут помочь обеспечить стабильное и рабочее соединение IPsec.

Открытие портов
Необходимо открыть 2 порта:
 * UDP port 500 (for ISAKMP)
 * UDP port 4500 (for NAT Traversal)

Убедитесь, что отправили это VPN серверу.

Также следующие Протоколы Интернета (не порты) нуждаются в разрешении:
 * 50 (ESP)
 * 51 (AH)

Может потребоваться настроить их на стороне роутера, если у него есть особые параметры для протоколов (впрочем, у большинства их нет).

Сквозной проход IPsec / повреждённый NAT
Многие роутеры имеют опцию "IPsec pass-through", которая может обозначать одно из двух:


 * 1) Искажать пакеты IPsec способом, не совместимым с обходом NAT IPsec
 * 2) Позволять всем IPsec пакетам без изменений проходить через роутер.

Если IPsec pass-through значит (1), отключите эту опцию. Если он значит (2), то включите её.

К несчастью, существуют роутеры, отбрасывающие IPsec трафик, даже если порты разрешены, и поддерживающие только опцию (1). Для тех, у кого такой роутер, есть 3 варианта:


 * 1) Обновить прошивку, если доступна более новая, правильно работающая версия.
 * 2) Открыть отчёт об ошибке/неисправности с моделью роутера, если он не устарел
 * 3) Найти другой роутер. По описаниям, роутеры Linksys и D-link работают правильно.

Это руководство изначально было написано с таким роутером (Zyxel P-330W), и единственным доступным вариантом был (3).

Клиенты Windows Vista/Server 2008
Эти операционные системы автоматически не поддерживают IPsec/L2TP сервера за NAT. См. KB926179 для изменений в реестре, заставляющих их поддерживать его.

Ограничения Pre-Shared keys (PSK)
В протоколе IPsec нет поддержки согласования PSK. Единственная информация, доступная для выбора, какой ключ использовать, зависит от начального и конечного IP-адреса. Так как в обычной ситуации ответчик не будет заранее знать IP-адрес инициатора, каждый должен использовать тот же PSK. Поэтому, сертификаты (PKI) рекомендуются больше, чем PSK, даже только для единственного соединения. Однако, производство сертификатов и создание PKI – довольно сложный процесс и выходит за рамки этого руководства.

L2TP
Второй уровень, протокол туннелирования второго уровня (L2TP), настраивается намного проще. Как и IPsec, L2TP – одноранговый протокол. Клиентская сторона называется L2TP Access Concentrator или LAC, а серверная – L2TP Network Server или LNS.

При использовании iptables, примените следующие правила, чтобы заблокировать все соединения L2TP вне ipsec:

Если брандмауэром является, тогда заставьте его принимать входящие и исходящие соединения, использующие протокол ESP, чтобы разрешить авторизацию IPsec, и заблокируйте все соединения L2TP вне IPsec. Это может быть сделано с помощью следующего файла:

Использование xl2tpd
В отличие от других серверов L2TP, может поддерживать пул IP-адресов без серверов DHCP или RADIUS. Это является нарушением расслоения, но для небольшой установки очень удобно:

Для использования сервера RADIUS или DHCP, оставьте отключенными опции  и. Если соединение нестабильно, попробуйте добавить  в раздел. Чтобы не использовать PPP аутентификацию, замените  на.

Создайте файл опций:

Использование rp-l2tp
Настраивать rp-l2tp просто:

Укажите IP сервера в lns-pppd-opts. Также не забудьте настроить pppd для использования пула IP-адресов или при помощи DHCP, или через RADIUS.

PPP
Заключительный уровень для настройки – Протокол точка-точка (PPP). Пакет для установки –.

Авторизация
PPP используется для выполнения авторизации. В отличие от аутентификации на основе сертификата или PSK, PPP более предназначен для аутентификации (и авторизации) доступа к VPN конечного пользователя.

Без авторизации
Самый простой путь настройки pppd – вообще не использовать авторизацию. В этом случае, убедитесь что указан "noauth". Это может оказаться полезным с целью тестирования, но в противном случае не рекомендуется, особенно с использованием PSK. Для некоторых установок PKI, такая конфигурация может быть благоразумной, например,
 * все клиентские компьютеры полностью доверены и находятся под контролем, или
 * все пользователи доверены и ключи есть только на компьютерах рядом с самими пользователями, имеющими доступ, и нигде более, или
 * все соединения являются автоматическими (этот метод используется для подключения нескольких мест)

Авторизация через chap.secrets
Для небольших пользователей (обычно тех, кто хочет подключаться к своей домашней сети в другом месте), авторизация может быть произведена через файл :

Авторизация через Samba
Если компьютер является частью домена Microsoft или леса Active Directory, а клиенты используют winbind, то авторизацию может выполнять Samba. Добавьте  к опциям ppp. Настройка Samba и pppd находится за пределами этого руководства.

Авторизация через RADIUS
Если на компьютере запущен сервер RADIUS, то pppd может использовать его. Убедитесь, что собран с USE-флагом. Затем добавьте  к опциям PPP. Настройка RADIUS и pppd находится за пределами этого руководства.

Авторизация через EAP-TLS
Если у пользователя есть сертификаты (не такие, как сертификаты компьютера, о которых говорилось раньше), тогда настройте pppd для авторизации через EAP-TLS. Рекомендуется, чтобы пользователи авторизовались с помощью смарт-карт или RSA secureID. Убедитесь, что собран с USE-флагом. Требуется, чтобы был настроен RADIUS (см. выше). Может потребоваться включить  в файл опций PPP. Настройка pppd выходит за пределы этого руководства.

Windows: Правильная установка сертификата (для пользователей PKI)
Сертификат должен быть запакован в пакет PKCS12. Это может быть сделано посредством openssl или gnutls:

Когда создан файл, импортируйте его в Windows. Однако, способ не очевиден. Не надо дважды щёлкать по ключу и следовать инструкциям, это не будет работать. Ключ будет импортирован в личное хранилище сертификатов, но в Windows в авторизации нуждается локальный компьютер, таким образом сертификат должен быть добавлен в хранилище ключей локального компьютера. Для этого используйте Консоль управления Microsoft (MMC). Для работы требуются привилегии администратора.

Разверните Сертификаты. Выберете любую папку (без разницы какую), щёлкните правой кнопкой мыши, выберете "Все задачи", затем "Импорт...". Только сейчас следуйте указаниям мастера, но на последнем шаге убедитесь, что выбрано "Автоматически выбрать хранилище на основе типа сертификата".

Ошибка 766: Сертификат не может быть найден
Если происходит такая ошибка, значит сертификат не был правильно импортирован. Убедитесь, что импортировали его через MMC, а не двойным щелчком файла.

Ошибка 810: VPN соединение не завершено
При использовании ipsec-tools (racoon) в системном логе может появится следующее сообщение:

Это значит, что сертификат был неправильно импортирован, или пакет p12 отсутствует в сертификате ЦС. Убедитесь, что импортировали ключ через MMC и выбрали "Автоматически выбрать хранилище на основе типа сертификата" в конце процесса импорта.

XP SP2 и выше: Ошибка 809: Сервер не отвечает (Сервер за NAT)
Windows XP SP2 и Vista |по умолчанию не будут подключаться к серверу за NAT. Требуется взлом реестра. Отдельные исправления требуются для Windows XP и Windows Vista.

Vista: Ошибка 835 Невозможно авторизоваться
Эта ошибка появляется только при использовании PKI. Она значит, что subjectAltName не соответствует серверу, к которому подключается клиент. Такое часто случается при использовании динамического DNS, – сертификат имеет внутреннее имя, а не внешнее. Добавьте к сертификату внешнее имя или отключите опцию "Проверить атрибуты имени и использования у сертификата сервера" в настройках соединения: Безопасность -> Дополнительные параметры -> L2TP.

Ошибка 741: Локальный компьютер не поддерживает требуемый тип шифрования
Windows will try to negotiate MPPE, a (weak) encryption. When then this error occurs.
 * the system is not using PPP authentication, or
 * the system does not have a pppd with MPPE support, or
 * MPPE is supported but not compiled into the kernel (or a module)

If PPP authentication is used, it is recommended to fix the pppd or kernel (which are minimal configuration changes) even though there's no point to have double encryption. If the system does not use PPP authentication, or the double encryption is definitely not wanted, then disable it by unchecking "Require data encryption" on the Security tab.

Mac OS X
Mac OS X clients appear to be picky on the proposals they will negotiate with. In particular:
 * dh_group must be.
 * my_identifier must be an address, not a fully qualified domain name (address is the default, so just leave that line out from ).

Mac OS X won't connect if subjectAltName does not match the server the client is connecting to. Unlike Vista this check cannot be disabled.

Also, Mac OS X won't connect if the server certificate contains any "Extended Key Usage" (EKU) fields (except for the deprecated ikeIntermediate one). In particular, when using certificates from the OpenVPN utility, it adds the "TLS WWW Server" or "TLS WWW Client" EKU, so such certificates will not work. However, such certificates can still be used on the Mac OS X client, as it doesn't care what is on the client certificate - only the server.

Ссылки

 * |Using a Linux L2TP/IPsec VPN server from Jacco de Leeuw