Установка и настройка 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
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
Открываем на редактирование конфигурационный файл:
Information Security Squad
stay tune stay secure
Настройка IPSec VPN-сервера с L2TP и Cisco IPsec на Ubuntu / CentOS / Debian
Вы пытались настроить свой собственный VPN-сервер IPsec всего за несколько минут, используя IPsec / L2TP и Cisco IPsec для CentOS, Ubuntu и Debian Linux?
Я покажу вам самый простой способ запустить и запустить ваш VPN-сервер за считанные минуты, все, что вам нужно сделать, это предоставить свои собственные учетные данные VPN и позволить скриптам справляться с остальными.
IPsec VPN гарантирует, что весь сетевой трафик зашифрован, чтобы предотвратить перехват между вами и VPN-сервером.
Это очень рекомендуемая настройка, особенно для парней, использующих незащищенные сети для доступа к Интернету, например, в аэропортах, например, в кафе, гостиничных номерах e.y.c.
Настройка среды
Эта настройка поддерживается в следующих операционных системах:
- Ubuntu 18.04 (Bionic), 16.04 (Xenial) или 14.04 (Trusty)
- Debian 9 (Stretch) или 8 (Jessie)
- CentOS 7 (x86_64)
- CentOS 6 (x86_64)
Рекомендуется использовать только что установленный сервер с обновлениями.
Обновление Ubuntu / Debian
Обновление CentOS 7 / CentOS 6
Это обеспечит обновление всех пакетов на вашем Сервере.
Настройка IPSec VPN-сервера с L2TP и Cisco IPsec на Ubuntu / CentOS / Debian
Мы будем использовать скрипт, облегчающий развертывание IPSec VPN-сервера с L2TP и Cisco IPsec в дистрибутивах Ubuntu / CentOS / Debian Linux.
Этот скрипт был написан Лин Сонгом.
Настройка IPsec VPN-сервера на Ubuntu 18.04 / Ubuntu 16.04 / Debian
Перед запуском скрипта необходимо обновить системные пакеты.
Это полностью автоматизированная настройка сервера IPsec VPN, без ввода пользователем чего-либо.
Настройка IPsec VPN-сервера на CentOS 7 / CentOS 6
Для сервера CentOS запустите следующую команду
Ваши данные входа в систему VPN будут генерироваться случайным образом и отображаться на экране по завершении.
Если вы хотите определить свои собственные учетные данные VPN, отредактируйте vpnsetup.sh перед выполнением.
Задайте значения внутри одинарных кавычек
Включить службу ipsec для запуска при загрузке системы
Это включает оптимизацию sysctl.conf для повышения производительности.
Управление пользователями VPN
По умолчанию создается учетная запись пользователя для входа в систему VPN.
Если вы хотите добавить, отредактировать или удалить пользователей, прочитайте руководство пользователя IPSec VPN.
IPsec PSK (pre-shared key) сохраняется в ./etc/ipsec.secrets
Все пользователи VPN используют один и тот же IPsec PSK.
Вы можете установить новый, изменив строку:
Для IPsec / L2TP пользователи VPN указаны в /etc/ppp/chap-secrets. Формат этого файла:
Для IPsec / XAuth («Cisco IPsec») пользователи VPN указаны в /etc/ipsec.d/passwd. Формат этого файла:
Пароли в этом файле соленые и хешированные.
Этот этап может быть осуществлен с использованием, например, утилита openssl:
Наконец, перезапустите службы, если вы перешли на новый PSK.
Для добавления, редактирования или удаления пользователей VPN перезапуск обычно не требуется.
Подключение компьютера к VPN
Последним шагом является подключение вашего компьютера или устройства к использованию VPN.
Для этого обратитесь к следующим руководствам:
Непростой IPSec с Linux
Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях стартапах нет опыта организации таких схем, а из оборудования есть только VDS с Linuxом на борту. Более того, к моему удивлению, в рунете практически нет материалов с описанием инструментов траблшутинга под Linux. Попробуем устранить этот пробел и описать практическую часть настроек.
Общая схема сервиса представлена ниже. Как правило, в крупных организациях все уже стандартизировано, поставлено на поток, всякие возможные шифрования и прочие сетевые штуки делаются на отдельном оборудовании (циски-джуниперы и иже с ними), и, что важнее, отдельными людьми (возможно каждый синий квадратик на схеме ниже обслуживают разные люди). У вас же одна виртуалка, с которой будет и запускаться сервис, и организовываться IPSec.
Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере 10.0.255.1 10.0.1.1 ), а сам сервис — между другими ( 192.168.255.1 192.168.1.1 ). Такие схемы еще называются IPSec Network-Network.
Простой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком. Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:
- Организовать транспорт (как будет происходить межсетевое взаимодействие).
- Настроить сервис (запустить приложения непосредственно на серверах).
Итак, менеджер СуперСервис решил организовать подключение к какой-то крупной организации для решения бизнес-задачи. Он обратился к МегаТелеком, на что ему выслали технические условия по подключению. Одно из этих условий — организация IPSec. Это условие пришло в виде таблички excel, пример которой я представил ниже. На картинке я желтым выделил технически значимые параметры. Формат может отличаться, но суть остается той же.
Изначально он приходит не заполненный с вашей стороны, его надо заполнить и отправить на согласование партнеру. После согласования можно садиться и пробовать настраивать вашу Linux-машинку.
Концепция IPSec
Далее я приведу немного теории для людей, совсем не знакомых с технологией. Все, что я дальше опишу, относится к чистому Ethernet и IPv4. Я не буду вдаваться в алгоритмы шифрования, обмена ключами, вместо этого сосредоточусь на сетевой части.
IPSec — набор техник и протоколов по организации защищенного соединения.
В отличии от прочих технологий туннелирования (GRE, PPP, L2TP, даже MPLS-TE) для IPSec не создается явных туннельных интерфейсов, через которые можно маршрутизировать трафик. Вместо этого в IPSec предусмотрена концепция так называемых Security Assotiations (SA). SA и есть туннель от одного сетевого устройства к другому. Но не стоит забывать, что SA — не сетевой интерфейс в нормальном понимании этого слова, классическая маршрутизация здесь не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Мы явно прописываем что-то типа аксес-листа (ACL) для пропуска трафика через определенную SA. Все эти вещи определены в так называемом фреймворке ISAKMP.
ISAKMP — описание процедур IPSec, в литературе называют его фреймворком. В нем описываются термины SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), необходимость установки вспомогательных туннелей… ISAKMP построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.
IKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.
Благодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.
Перед шифрованием трафика стороны должны договориться о параметрах (и ключах) этого шифрования. Для этого между обоими сторонами поднимается вспомогательный туннель (его еще называют ISAKMP туннель), который действует все время. Туннель этот двунаправленный, представляет из себя соединение по UDP (по умолчанию на порту 500). Для организации этого вспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.
Собственно организация IPSecа делится на две фазы:
- Создание вспомогательного туннеля ISAKMP
- Создание туннеля пользовательских данных
Как я писал, в концепции IPSec (а уже правильнее говорить, в концепции ISAKMP) туннели называются SA.
Первая фаза (организация ISAKMP SA) может осуществляться в двух режимах:
- main — стороны поочередно обмениваются параметрами согласования. Считается более безопасным, используется для постоянных каналов (наш случай).
- aggressive — инициатор в одном сообщении отправляет все необходимые параметры согласования, используется при подключении удаленного пользователя для временной сессии (чтобы быстрее).
Надо понимать, что основные SA-туннели однонаправленные. Для двусторонней передачи данных по IPSec каналу должно быть два туннеля: источник (src) → получатель (dst) и наоборот.
Во всех способах шифрования в оригинальный IP-пакет добавляются дополнительные заголовки, происходит инкапсуляция. Существует два способа этой инкапсуляции — AH (Authentication Header) и ESP (Encapsulation Security Payload). AH только аутентифицирует пакет (подписывает цифровой подписью отправителя), ESP и аутентифицирует (подписывает), и шифрует. На сегодняшний день AH уже практически не используется, все упаковывают в ESP.
Шифровать и аутентифицировать исходный IP-пакет можно без учета IP-заголовка (транспортный режим) или вместе с ним (туннельный режим). Транспортный используется тогда, когда планируется организовать свои туннели по другим технологиям (не IPSec/ESP). Например, GRE, l2tp, ppp. Для целей подключения какого-то сервиса ко внутренней инфраструктуре большой организации практически не используется. Я использовал такой сценарий для объединения нескольких офисов в один VPN через IPSec-и. Нам же более интересен туннельный режим. Как видно из картинки, здесь добавляется один дополнительный IP-заголовок.
Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.
Обратите внимание, что заголовок ESP встает до транспортных TCP/UDP. Помните, в заголовке IP-пакета есть поле Protocol? На основе этого поля сетевое оборудование (да и конечные хосты) корректно обрабатывают IP-пакеты. Так вот для ESP свой номер — 50. Полный список протоколов для этого поля можно посмотреть на вики, бывает весьма полезно.
Отсутствие заголовка транспортного уровня (TCP/UDP/ICMP уже зашифрованы!) накладывает ограничение на технологии типа NAT. Вспомните, NAT с трансляцией портов (overload, PAT, MASQARADE, у него много имен) работает на основе портов транспортных протоколов. А в зашифрованном туннеле IPSec их нет! Для преодоления этой проблемы есть такая технология, как IPSec NAT-Traversal (NAT-T). В ходе первой фазы стороны согласовывают возможность использовать NAT-T. Если обе стороны поддерживают NAT-T (да еще и на одинаковых UDP-портах), тогда в итоговых туннелях для трафика добавляется заголовок UDP, с которым пакеты уже пройдут через маршрутизаторы с трансляцией сетевых адресов.
Сам по себе туннель не поднимется, нужно направить туда трафик. Как я писал выше, здесь не работают правила маршрутизации, надо писать политики Security Policy (SP).
Политики состоят из адреса источника, адреса назначения, направления (in, out, fwd) и параметров пользовательских туннелей (здесь как раз описываются ESP это будет или AH, туннельный вариант или транспортный). Это больше похоже на организацию правил для NATа. NATу тоже недостаточно записей таблицы маршрутизации. И там тоже указываются правила откуда, куда и как, а не куда и через что. И также неверным движением руки можно завалить всю связь на удаленном сервере.
Все манипуляции с IPSec добавляют заголовки служебной информации. Минимум они съедят еще 40 байт от исходного пакета. Таким образом, например, при стандартном MTU для PPPoE в 1380 байт соединений реальное MTU будет /etc/racoon.conf ), запускается обычным init-скриптом ( /etc/init.d/racoon ).
Как всегда, подробности в man 5 racoon.conf
Дальше займемся утилитой setkey. Она тоже запускается как демон ( /etc/init.d/setkey ), но по факту она выполняет скрипт /etc/ipsec-tools.conf . Как я и говорил, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них. Это что-то вроде crypto-map на ASA. Самый простой вариант для нас — добавить просто SP. Тогда SA построится автоматически исходя из параметров второй фазы, указанной в настройках racoon.
Но есть возможность вообще не использовать параметры второй фазы из racoon, а задать SA через эту утилиту. Подробности и синтаксис можно посмотреть в man 8 setkey . А я же приведу приведу пример простейшей конфигурации.
На текущий момент утилиту setkey дублирует модуль iproute2.
В рамках него есть две команды управления записями SA и SP.
- ip xfrm state
- ip xfrm policy
Помимо управления этой же утилитой можно смотреть состояние организованных SA и применяемых к трафику SP. Подробнее в man 8 ip-xfrm .
Взгляните еще раз на изначальную табличку. Там указаны разные IP-адреса для IPSec и сервиса. По внутреннему IP-адресу идет фильтрация внутри инфраструктуры Мегателеком. Но у нас всего лишь одна виртуальная машина. На ней должен как-то появиться внутренний IP-адрес, и пакеты в туннель должны уходить именно с него. Есть несколько вариантов добиться этого сценария:
- Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
- Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
- Трансляция адресов (NAT/MASQARADE).
С моей точки зрения здесь подходит первый вариант.
Мы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса
root@localhost:
# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
и настроить маршрут до сервера Мегателеком с этого IP-адреса.
root@localhost:
# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Но если так сделать, ничего не заведется. Дело в том, что при добавлении маршрута в таком виде Linux-станция будет пытаться определить MAC-адрес получателя, делать она это будет через ARP… Компьютер будет слать запросы ARP Who has IP 192.168.255.1 . Так как 192.168.255.1 нет в той же сети, где и 192.168.1.1 (маска /32!), ответа на ARP не будет. Зато при попытке соединения будет возвращаться с локального IP-адреса будет возвращаться No route to host . Чтобы это победить, нам надо задать статическую ARP-запись:
root@localhost:
# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Такой вот лайфхак. Кстати, такие манипуляции могут привести не совсем к коректной работе IP-стека Linux. В одном из случаев команды ip route не приводили к нужному результату, пришлось перезагружать сетевой стек.
Проверка работоспособности
Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до назначения.
root@localhost:
# ping -I 192.168.1.1 192.168.255.1
С небольшой задержкой должны быть ответы с обратной стороны (если конечно ICMP нигде не закрыт на участке).
Мы можем увидеть, поднялся ли ISAKMP-туннель
Также мы можем посмотреть туннели с пользовательскими данными
Бывает полезно в tcpdump посмотреть логику установления соединения. Здесь можно также увидеть фазы установления соединения и уже передаваемый шифрованный в ESP трафик. Конечно есть техники его расшифровки, но обычно такого вывода уже достаточно.
# tcpdump -i eth1 host 10.0.255.1
При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:
# tcpdump -i eth1 -w ipsec.pcap esp &
Запускаем ping, telnet, netcat…
# killall tcpdump
root@localhost:
Также в логах можно увидеть успешный статус установления соединения. В нем видно успешное установление обоих фаз IPSec.
Вот и все. Остается добавить все необходимые манипуляции в автозагрузку, и можно начинать интеграцию приложений.
P. S.: Просьба обо всех ошибках или неточностях в статье сообщать личным сообщением. Когда я подправлю статью, комментарии будут смотреться глупо.