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:

If the local firewall is then get  to accept incoming & outgoing connections using the ESP protocol to allow IPsec authentication, and to block all L2TP connections outside the IPsec layer. This can be accomplished by using the following file:

Using xl2tpd
Unlike other L2TP servers, can maintain an IP address pool without a DHCP or RADIUS server. This is a layering violation, but for a small setup it is extremely convenient:

To use a RADIUS or DHCP server, leave off the  and   parts. If the connection is unstable, try adding  to the   section. To not use PPP authentication, change  to.

Create the options file as well:

Using rp-l2tp
Configuring rp-l2tp is simple:

Specify the server IP as well in lns-pppd-opts. Also don't forget to setup pppd to use an IP address pool, either via DHCP or RADIUS.

PPP
The final layer to configure is the Point-to-Point Protocol (PPP) layer. The package to install here is.

Авторизация
PPP is used to perform authentication. Unlike the certificate based or PSK authentication, the PPP layer is more for authenticating (and authorizing) the end users' access to the VPN.

Без авторизации
The easiest way to setup pppd is to not use any authentication at all. In that case, make sure "noauth" is specified. This is useful for testing purposes, but otherwise not recommended - especially when using PSK. For certain PKI setups, such a configuration may be sensible - for example,
 * all the client machines are fully trusted and under control, or
 * all the users are trusted and the keys are on machines no one else, besides the users' themselves, have access to, or
 * all connections are unattended (using this method to connected multiple sites)

Авторизация через chap.secrets
For small users (typically, those wanting to connect their home network from elsewhere), authentication can be done through the file:

Авторизация через Samba
When the machine is part of (or hosting) an MS Domain or AD forest, and the clients are using winbind, then Samba can do the authentication. Add  to the ppp options. Setting up Samba and pppd to do this is beyond the scope of this document.

Авторизация через RADIUS
When a RADIUS server is running on the same machine, pppd can use RADIUS. Ensure the  USE flag is set on. Then add  to the PPP options. Setting up RADIUS and pppd to do this is beyond the scope of this document.

Авторизация через EAP-TLS
If individual users have certificates (which is not the same as the machine certificate above), then setup pppd to authenticate via EAP-TLS. It is recommended that the users authenticate via smartcards or RSA secureID. Ensure the  USE flag is set on. RADIUS needs to be setup (see above). The  option might need to be included in the PPP options file as well. Setting up pppd to do this is beyond the scope of this document.

Windows: Correctly installing the certificate (for PKI users)
The certificate should be packaged in a PKCS12 package. This can be done through openssl or gnutls:

Once a file is created, import it into Windows. However, the method is not obvious. Do not double-click the key and follow the instructions, that won't work. That imports the key into a personal certificate store, but in Windows, it is the local computer that needs to do the authentication, so the certificate needs to be added to the local computer's key store. To do that, use the Microsoft Management Console (mmc). Administrator privileges are needed for this to work.

Expand the Certificates. Choose any folder (doesn't matter which), right-click, choose "All Tasks", then "Import". Only now follow the wizard, but on the last step, make sure to choose "Automatically select the certificate store based on the type of certificate".

Error 766: A certificate could not be found
If this error occurs, then this means the certificate was not imported correctly. Make sure to import it though MMC, and not by double-clicking the file.

Error 810: VPN connection not complete
When using ipsec-tools (racoon) the following message might occur in the system log:

This means the certificate was not imported correctly, or the p12 bundle is missing in the CA certificate. Make sure to import the key through MMC, and make sure to select "Automatically select the certificate store based on the type of certificate" at the end of the import process.

XP SP2 and above: Error 809: Server not responding (Server behind NAT)
Windows XP SP2 and Vista |will not, by default, connect to server behind a NAT. A registry hack is required. Separate fixes are required for Windows XP and Windows Vista.

Vista: Error 835 Could not authenticate
This one occurs only when using PKI. It means the subjectAltName does not match the server that the client is connecting to. This often occurs when using dynamic DNS - the certificate has the internal name rather than the external name. Either add the external name to the certificate, or disable "Verify the Name and Usage attributes of the server's certificate" in the connection definition, under Security -> Networking -> IPsec.

Error 741: The local computer does not support required encryption type
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