Установка и настройка L2TP VPN-сервера на Ubuntu Server
L2TP сервер удобен тем, что позволяет использовать встроенные средства Windows для подключения. В данной инструкции рассмотрим процесс его установки и настройки на Ubuntu 16.04 и 18.04. В итоге мы получим:
- VPN-сервер, использующий туннельный протокол L2TP.
- Защита соединения посредством общего ключа + аутентификация пользователя.
- Доступ к локальной сети.
Мы выполним следующие настройки:
Настройка IPSEC
Для управления IPSec используется пакет strongswan — установим его командой:
apt-get install strongswan
Открываем конфигурационный файл для настройки ipsec:
Для config setup добавим:
config setup
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
protostack=netkey
* где virtual_private для нас является наиболее важным параметром и определяет приватные сети. В данном примере просто перечислены сети, зарезервированные под локальные — мы можем указать и другие.
. а также вставляем ниже:
conn l2tpvpn
type=transport
authby=secret
pfs=no
rekey=no
keyingtries=2
left=%any
leftprotoport=udp/l2tp
leftid=@l2tpvpnserver
right=%any
rightprotoport=udp/%any
auto=add
- type — тип соединения. Возможны варианты tunnel ( хост-хост, хост-подсеть или подсеть-подсеть); transport (хост-хост); passthrough (без обработки IPsec).
- authby — способы аутентификации двух узлов. Возможны варианты secret (по паролю) или rsasig (цифровые подписи RSA).
- pfs — расшифровывается как Perfect Forward Secrecy. Позволяет активировать совершенную секретность в канале ключей соединения.
- rekey — перепроверить соединение, когда оно истекает.
- keyingtries — число попыток, чтобы «договориться» о соединении или его замене.
- left — IP-адрес левого участника (сервера). %any означает, что адрес может быть любой.
- leftprotoport — определяет протокол и порт, на котором будет работать левая сторона (сервер). В данном примере указан UDP и порт 1701.
- leftid — идентификация левого участника соединения.
- right — IP-адрес правого участника (клиента). %any означает, что адрес может быть любой.
- rightprotoport — определяет протокол и порт, на котором будет работать правая сторона (клиент). В данном примере указан UDP и любой порт.
- auto — операция, которая должна запуститься автоматически при старте IPsec.
Создаем секретный ключ — для этого открываем на редактирование файл:
%any %any : PSK «my_key_password»
* в данном примере мы устанавливаем общий пароль my_key_password для соединений с любого IP.
Разрешаем автозапуск strongswan и перезапускаем службу:
systemctl enable strongswan
systemctl restart strongswan
Устанавливаем сервер L2TP:
apt-get install xl2tpd
Открываем файл настройки сервера:
[global]
port = 1701
access control = no
ipsec saref = yes
force userspace = yes
auth file = /etc/ppp/chap-secrets
[lns default]
ip range = 176.16.10.10-176.16.10.200
local ip = 176.16.10.1
name = l2tpserver
pppoptfile = /etc/ppp/options.xl2tpd
flow bit = yes
exclusive = no
hidden bit = no
length bit = yes
require authentication = yes
require chap = yes
refuse pap = yes
- port — порт UDP, на котором работает VPN. По умолчанию, 1701.
- access control — принимать или нет запросы только от клиентов с определенными IP, перечисленными в настройках клиентов.
- ipsec saref — указывает использовать или нет ipsec Security Association, позволяющий отслеживать несколько клиентов с одинаковыми IP-адресами.
- force userspace — повышает производительность за счет декапсуляции пакетов L2TP.
- auth file — путь к файлу аутентификации.
- ip range — диапазон адресов, которые назначаются подключенным клиентам.
- local ip — IP-адрес сервера в сети VPN.
- name — имя сервера для процесса согласования.
- pppoptfile — путь к файлу с настройкой pppd.
- flow bit — позволяет добавлять в пакеты порядковые номера.
- exclusive — если поставить в yes, сервер разрешит только одно соединение с клиентом.
- hidden bit — скрывать или нет AVP.
- length bit — использовать ли бит длины, указывающий полезную нагрузку.
- require authentication — требовать ли аутентификацию.
- require chap — требовать ли аутентификацию PPP по протоколу CHAP.
- refuse pap — требовать ли аутентификацию PPP по протоколу PAP.
Разрешаем автозапуск vpn-сервера и перезапускаем его:
systemctl enable xl2tpd
systemctl restart xl2tpd
Открываем на редактирование конфигурационный файл:
Источник
VPN везде и всюду: IPsec без L2TP со strongSwan
достаточно сильный лебедь
Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.
Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.
Небольшое введение в мир IPsec
Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.
В современном IPsec используются:
- Authentication Header (AH) — протокол, обеспечивающий аутентификацию отправителя и целостность данных. Подписывает не только данные пакета, но и все заголовки, кроме изменяемых полей (ToS, TTL, чексумма).
- Encapsulating Security Payload (ESP) — протокол, обеспечивающий аутентификацию, целостность и конфиденциальность
- Security Association (SA) — параметр с настройками шифрования канала
- Internet Key Exchange (IKE и IKEv2) — протокол обмена параметрами, настройками и согласования SA
AH и ESP — транспортные протоколы, инкапсулируемые прямо в IP, имеющие собственные значение для поля Protocol в IP-заголовке. В современном мире, где NAT стоит за NAT у NAT с NAT’ом, следует использовать что-то более привычное, поэтому сейчас повсеместно используется инкапсуляция ESP-пакетов в UDP. AH не поддерживает работу через NAT.
Сам IPsec поддерживает работу в двух режимах:
- Транспортный режим. Подписывает заголовки и данные (если AH) или подписывает и шифрует данные (если ESP) пакета. Не скрывает IP-адрес получателя пакета, если он маршрутизируется. Этот режим используется для связки L2TP+IPsec.
- Туннельный режим. Подписывает (если AH) и еще шифрует (если ESP) весь пакет.
Протокол IKE позволяет проводить аутентификацию клиента с использованием X.509-сертификатов, Pre-Shared Key и Extensible Authentication Protocol (EAP). Поддерживается двухэтапная аутентификация.
Все современные десктопные ОС (Windows Vista/7/8/8.1, OS X, Linux), мобильные устройства (Android, iOS, Windows Phone, Blackberry) и некоторые роутеры поддерживают VPN с использованием IPsec ESP в туннельном режиме и его настройкой через протокол Internet Key Exchange (IKE) версии 1 или 2, а значит IPsec мы именно так и будем настраивать.
Кстати, писать правильно IPsec, но Cisco IPSec.
IPsec в Linux
В OpenVZ есть поддержка IPsec, и она вполне себе годна для запуска L2TP+IPsec, но там что-то явно не так с маршрутизацией на не-локальные интерфейсы. Вероятно, это можно починить добавлением пары правил на хостовую машину, но это довольно проблематично, если у вас нет доступа к ней, как бывает во подавляющем большинстве случаев. Поэтому для OpenVZ необходимо использовать userspace IPsec, который можно собрать параметром —enable-kernel-libipsec
Жизнь со swanctl: 
Жизнь без swanctl: 
Нам могут потребоваться некоторые модули, которых может не быть в стандартной поставке:
- xauth-noauth — поддельный аутентификатор, позволяет вводить любой логин и пароль. Нужен для iPhone и iPad при аутентификации только по ключам, т.к. там нет возможности отключить аутентификацию по логину и паролю.
- vici — интерфейс для swanctl.
- libipsec — для userspace IPsec (для OpenVZ и, возможно, других контейнеров).
Если вас не смущает необходимость вводить логин и пароль на iPhone, вам не нужен swanctl и вы не собираетесь запускать это все в OpenVZ-контейнере, то и пересобирать ничего не нужно.
К большому сожалению, мейнтейнеры strongSwan в Debian не запаковали ничего из этого (на февраль 2015), поэтому я сделал патчик, который вы можете использовать.
Переходим к настройке
Будем настраивать подключение через IKEv2 (Windows, Linux, Blackberry), IKEv1+XAUTH (iOS, OS X, Android) и IKEv2+EAP-TLS (Windows Phone). Используем ключи, никаких PSK!
Разработчики strongSwan предлагают нам использовать команду «ipsec pki» для генерации ключей, но она настолько же неудобная, насколько и обычный openssl, поэтому я адаптировал Easy-RSA v3 из OpenVPN для генерации как OpenVPN, так и IPsec-совместимых ключей. С ним вы можете использовать одну связку ключей для двух протоколов!
github.com/ValdikSS/easy-rsa-ipsec
Easy-RSA чрезвычайно простой, поддерживать PKI-инфраструктуру с ним одно удовольствие!
Итак, инициализируем PKI и создаем CA, серверный и клиентский ключи. Важно, чтобы название серверного ключа совпадало с FQDN (доменом, проще говоря) вашего сервера!
Ключи сгенерированы. Я добавлял параметр nopass на каждом шагу, чтобы ключи не были защищены паролем (его можно установить позже в любое время).
Теперь нам необходимо скопировать их в нужные директории внутри /etc/ipsec.d/ , чтобы strongSwan нашел их:
Переходим к настройке strongSwan!
Первым делом, указываем наш приватный ключ в /etc/ipsec.secrets
Редактируем конфигурационный файл /etc/ipsec.conf
Как видите, конфигурационный файл состоит из нескольких секций. В секции config setup два закомментированных параметра: strictcrlpolicy = yes будет требовать неистекший лист отзывов для проведения аутентификации клиента, а uniqueids = no позволяет подключаться нескольким клиентам с одним сертификатом одновременно.
Далее идут секции с описаниями подключений. Секция с названием %default описывает подключение по умолчанию, от которого будут наследоваться другие подключения. Здесь устанавливаются следующие параметры:
- dpdaction=clear включает механизм Dead Peer Detection (DPD) и указывает, что нужно забывать о клиенте, если он не отзывался дольше таймаута
- dpddelay=35s — задержка до включения DPD
- dpdtimeout=300s — таймаут для DPD
- fragmentation=yes — включение внутренней фрагментации пакетов. Позволяет использовать IPsec с провайдерами, у которых сломана IP-фрагментация пакетов (привет, мобильный МТС!)
- rekey=no — выключение инициации смены ключей со стороны сервера. Windows это не любит.
- ike — перечень ciphersuites для использования с IKE (т.е. во время установки шифрованного соединения для передачи конфигурационных параметров, в том числе и ключей для установки SA)
- esp — перечень ciphersuites для шифрования трафика
- left и right — случаем все интерфейсы и принимаем всех клиентов
- leftid — указываем наш FQDN. Нужно для сломанного IKEv2 в OS X El Capitan
- leftauth/rightauth=pubkey — используем аутентификацию по ключам
- leftsubnet — подсети, которые мы отправляем клиенту для маршрутизации (весь IPv4 и IPv6-интернет). Уберите IPv6, если не используете его.
- rightsourceip — пул IP-адресов, из которого выдаем адрес клиенту. Уберите IPv6, если не используете его.
- rightdns — IP-адреса DNS-серверов
Давайте разберемся с ciphersuites в ike и esp. Здесь перечислены методы шифрования в порядке убывания приоритета, и их так много из-за того, что некоторые из них могут быть недоступны на каких-то устройствах, например, мобильных. Первым делом идут так называемые AEAD-алгоритмы, т.е. такие шифры, которые не требуют отдельного алгоритма для аутентификации, с убывающей группой Диффи-Хеллмана для реализации Perfect Forward Secrecy (PFS). Это самые быстрые шифры, которые доступны в IPsec. Хоть это и AEAD-режим, в ike должны быть алгоритмы хеширования для процесса хендшейка. Затем идет привычный AES-CBC с группами Диффи-Хеллмана. Клиентам, которые не поддерживают PFS, мы не позволим подключиться.
Если у вас нет модуля xauth-noauth для соединения ikev1-fakexauth , то вы можете заменить его просто на xauth и создать пользователя в /etc/ipsec.secrets , например, с логином и паролем client1:
Теперь у нас есть три подключения: ikev2-pubkey для IKEv2, ikev1-fakexauth для IKEv1 с фейковой проверкой логина и пароля и ikev2-eap-tls — IKEv2+EAP-TLS для Windows Phone. Перезапускаем strongSwan.
Если все верно, вы увидите следующий вывод команды swanctl -L
Проблемы MTU
Из-за особенностей и ошибок в реализации разных IPsec-клиентов, MTU внутри туннеля нельзя угадать заранее, а на Android вообще устанавливается MTU 1500, из-за чего большие пакеты не передаются и вообще ничего не работает. Чтобы нивелировать этот недостаток, достаточно изменять параметр TCP MSS в момент установки TCP-соединения на стороне сервера. Будем использовать значение 1360 для IPv4 и 1340 для IPv6, чтобы размер пакета не превышал 1400 байт внутри туннеля:
На этом настройка сервера закончена. Не забудьте настроить NAT, если вам он нужен!
Настройка клиентов
Алгоритм настройки клиентов в общих чертах заключается в импорте сертификатов из файла *.p12, создании нового подключения с типом IPsec PKI, IPsec XAUTH RSA или IKEv2 (в зависимости от устройства), указания клиентского сертификата и адреса сервера.
Внимание! Нужно вводить именно тот адрес сервера, который вы вводили при создании серверного ключа. Подключиться по другому домену или просто по IP-адресу, если сертификат был сгенерирован на домен, не получится!
Windows
OS X и iOS
Android
Вы можете использовать как IPsec-клиент Android и подключаться по протоколу IKE, так и клиент strongSwan и использовать IKEv2. Клиент strongSwan работает стабильнее и надежно переподключает в случае потери соединения.
Импортируйте сертификат либо через файловый менеджер, либо используя пункт «Установка с SD-карты» в разделе «Безопасность». Перейдите в настройки VPN, создайте новое подключение с типом «IPSec Xauth RSA», в поле «Адрес сервера» впишите, собственно, адрес сервера, в поле «Сертификат пользователя IPSec» и «Сертификат ЦС IPSec» укажите сертификат «client1». Нажмите на соединение, введите любые логин и пароль и попробуйте подключиться.
Источник
