VPN скрізь і всюди: IPsec без L2TP з strongSwan

image
досить сильний лебідь

Якщо ви коли-небудь шукали 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) — протокол, що забезпечує аутентифікацію відправника і цілісність даних
  • Encapsulating Security Payload (ESP) — все те ж саме, що в AH, але з шифруванням
  • Security Association (SA) — протокол для налаштування AH або ESP
  • Internet Key Exchange (IKE і IKEv2) — протокол обміну параметрами, налаштуваннями та узгодження SA
AH і ESP використовують свої протоколи (не TCP/UDP, а протоколи), але в сучасному світі, де NAT стоїть за NAT у NAT з NAT'ом, слід використовувати щось більш звичне, тому зараз повсюдно використовується інкапсуляція AH і ESP-пакетів UDP.

Сам 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Сам IPsec (AH/ESP, SA) працює в ядрі, тому нам потрібен IKE-демон для передачі налаштувань підключаються клієнтам. Їх досить багато, але повноцінних і активних на даний момент всього два: strongSwan і libreswan. Другим я не користувався, нічого сказати про нього не можу, зате перший — прекрасний і дивний, до того ж, це єдиний демон, у якого є своя userspace-реалізація IPsec, тому його можна використовувати в контейнерах OpenVZ зі старим, як динозаври, ядром 2.6.32 з поламаною підтримкою маршрутизації IPsec.Трохи про IPsec в OpenVZOpenVZ є підтримка IPsec, і вона цілком придатна для запуску L2TP+IPsec, але там щось явно не так з маршрутизацією на не-локальні інтерфейси. Ймовірно, це можна полагодити додаванням пари правил на хостовую машину, але це досить проблематично, якщо у вас немає доступу до неї, як буває в переважній більшості випадків. Тому для OpenVZ необхідно використовувати userspace IPsec, який можна зібрати параметр --enable-kernel-libipsec

Згадки про ба:
lists.strongswan.org/pipermail/users/2014-February/005822.html
bugzilla.redhat.com/show_bug.cgi?id=1081804
forum.openvz.org/index.php?t=tree&goto=39937
lowendtalk.com/discussion/33226/need-someone to test-ipsec-on-their-boxes
Нам потрібно strongSwan версії мінімум 5.0.0. Я рекомендую використовувати версію не нижче 5.2.0, оскільки саме в цій версії з'явилася утиліта «swanctl», яка помітно зручніше старої «ipsec». Утиліта знадобиться, за великим рахунком, тільки для виведення якоїсь інформації або статистики, вона не обов'язкова для налаштування і можна обійтися тільки ipsec, але в статті буде використовуватися тільки вона.
Прихований текстЖиття з swanctl:
image

Життя без swanctl:
image
Нам можуть знадобитися деякі модулі, яких може не бути в стандартній поставці:
  • 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 (доменом, простіше кажучи) вашого сервера!
$ git clone https://github.com/ValdikSS/easy-rsa-ipsec.git
$ easy cd-rsa-ipsec/easyrsa3
$ ./easyrsa init-pki

init-pki complete; you may now create a CA or requests.

$ ./easyrsa build-ca nopass
Generating a 2048 bit RSA private key
...
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:IPsec CA
...

$ ./easyrsa build-server-full uk1.pvpn.pw nopass
Generating a 2048 bit RSA private key
...
Write out database with 1 new entries
Data Base Updated

$ ./easyrsa build-client-full client1 nopass 
Generating a 2048 bit RSA private key
...
Write out database with 1 new entries
Data Base Updated

$ ./easyrsa export-p12 client1 nopass
Successful export of p12 file. Your exported file is at the following
location...

Згенеровані ключі. Я додавав параметр
nopass
на кожному кроці, щоб ключі не були захищені паролем (його можна встановити в будь-який час).

Тепер нам необхідно скопіювати їх в потрібні директорії всередині
/etc/ipsec.d/
, щоб strongSwan знайшов їх:
# cp pki/ca.crt /etc/ipsec.d/cacerts/
# cp pki/issued/uk1.pvpn.pw.crt /etc/ipsec.d/certs/
# cp pki/private/uk1.pvpn.pw.key /etc/ipsec.d/private/

Переходимо до налаштування strongSwan!
Першим ділом, вказуємо наш приватний ключ
/etc/ipsec.secrets
# This file holds shared secrets or RSA private keys for authentication.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.

# this file is managed with debconf and will contain the automatically created private key
include /var/lib/strongswan/ipsec.secrets.inc

: RSA uk1.pvpn.pw.key

Редагуємо конфігураційний файл
/etc/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
# strictcrlpolicy=yes
# uniqueids = no

include /var/lib/strongswan/ipsec.conf.inc

conn %default
dpdaction=clear
dpddelay=35s
dpdtimeout=200s

fragmentation=yes

ike=aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-aesxcbc-sha256-sha1-modp4096-modp2048-modp1024,aes256-aes128-sha256-sha1-modp4096-modp2048-modp1024!

esp=aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp4096-modp2048-modp1024,aes128-aes256-sha1-sha256-modp4096-modp2048-modp1024!

# left - local (server side
left=%any
leftauth=pubkey
leftcert=uk1.pvpn.pw.crt
leftsendcert=always
leftsubnet=0.0.0.0/0,2000::/3

# right - remote (client) side
right=%any
rightauth=pubkey
rightsourceip=192.168.103.0/24,2002:25f7:7489:3::/112
rightdns=192.168.101.1,2002:25f7:7489:1::1

conn ikev2-pubkey
keyexchange=ikev2
auto=add

conn ikev1-fakexauth
keyexchange=ikev1
rightauth2=xauth-noauth
auto=add

conn ikev2-eap-tls
also="ikev2-pubkey"
rightauth=eap-tls

Як бачите, конфігураційний файл складається з декількох секцій. В секції
config setup
два закомментированных параметри:
strictcrlpolicy = yes
вимагатиме неистекший лист відгуків для проведення аутентифікації клієнта, а
uniqueids = no
дозволяє підключатися кільком клієнтам з одним сертифікатом одночасно.
Далі йдуть секції з описами підключень. Секція з назвою
%default
описує за замовчуванням підключення, від якого будуть успадковуватись інші підключення. Тут встановлюються наступні параметри:
  • dpdaction=clear
    містить механізм Dead Peer Detection (DPD) і вказує, що потрібно забувати про клієнта, якщо він не відгукувався довше таймауту
  • dpddelay=35s
    — затримка до включення DPD
  • dpdtimeout=200s
    — таймаут для DPD
  • fragmentation=yes
    — включення внутрішньої фрагментації пакетів. Дозволяє використовувати IPsec з провайдерами, у яких зламана IP-фрагментація пакетів (привіт, мобільний МТС!)
  • ike
    — перелік ciphersuites для використання з IKE (т. е. під час установки шифрованого з'єднання для передачі конфігураційних параметрів, в тому числі і ключів для установки SA)
  • esp
    — перелік ciphersuites для шифрування трафіку
  • left
    та
    right
    — випадком всі інтерфейси і приймаємо всіх клієнтів
  • leftauth/rightauth=pubkey
    — використовуємо аутентифікацію по ключам
  • leftsubnet
    — підмережі, які ми відправляємо клієнту для маршрутизації (весь IPv4 і IPv6-інтернет)
  • rightsourceip
    — пул IP-адрес, з якого видаємо адресу клієнта
  • 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:
client1 : XAUTH "client1"

Тепер у нас є три підключення:
ikev2-pubkey
для IKEv2,
ikev1-fakexauth
для IKEv1 з фейкової перевіркою логіна і пароля та
ikev2-eap-tls
— IKEv2+EAP-TLS для Windows Phone. Перезапускаємо strongSwan.

Якщо все вірно, ви побачите наступний висновок команди swanctl-L
$ swanctl-L
ikev2-pubkey: IKEv2
local: %any
remote: %any
local public key authentication:
id: CN=uk1.pvpn.pw
certs: CN=uk1.pvpn.pw
remote public key authentication:
ikev2-pubkey: TUNNEL
local: 0.0.0.0/0 2000::/3
remote: dynamic
ikev1-fakexauth: IKEv1
local: %any
remote: %any
local public key authentication:
id: CN=uk1.pvpn.pw
certs: CN=uk1.pvpn.pw
remote public key authentication:
remote XAuth authentication:
ikev1-fakexauth: TUNNEL
local: 0.0.0.0/0 2000::/3
remote: dynamic
ikev2-eap-tls: IKEv2
local: %any
remote: %any
local public key authentication:
id: CN=uk1.pvpn.pw
certs: CN=uk1.pvpn.pw
remote EAP authentication:
ikev2-eap-tls: TUNNEL
local: 0.0.0.0/0 2000::/3
remote: dynamic

Проблеми MTU

З-за особливостей і помилок у реалізації різних IPsec-клієнтів, MTU всередині тунелю не можна вгадати наперед, а на Android взагалі встановлюється MTU 1500, з-за чого великі пакети не передаються і взагалі нічого не працює. Щоб нівелювати цей недолік, досить змінювати параметр TCP MSS в момент встановлення TCP-з'єднання на стороні сервера. Будемо використовувати значення 1360 для IPv4 і 1340 для IPv6, щоб розмір пакета не перевищував 1400 всередині тунелю:
# iptables-t mangle-I FORWARD-p tcp-m policy --pol ipsec --dir in --syn-m tcpmss --mss 1361:1536-j TCPMSS --set-mss 1360
# iptables-t mangle-I FORWARD-p tcp-m policy --pol ipsec --dir out --syn-m tcpmss --mss 1361:1536-j TCPMSS --set-mss 1360
# ip6tables-t mangle-I FORWARD-p tcp-m policy --pol ipsec --dir in --syn-m tcpmss --mss 1341:1536-j TCPMSS --set-mss 1340
# ip6tables-t mangle-I FORWARD-p tcp-m policy --pol ipsec --dir out --syn-m tcpmss --mss 1341:1536-j TCPMSS --set-mss 1340

На цьому налаштування сервера закінчена.

Налаштування клієнтівАлгоритм налаштування клієнтів в загальних рисах полягає в імпорті сертифікатів з файлу *.p12, створення нового підключення з типом IPsec PKI, IPsec XAUTH RSA або IKEv2 (в залежності від пристрою), вказівки клієнтського сертифіката та адреси сервера.
Увага! Потрібно ввести адресу сервера, який ви вводили при створенні серверного ключа. З'єднатися з іншого домену або просто по IP-адресою, якщо сертифікат був згенерований на домен, не вийде!

Windows

Windows 7, 8, 8.1 (IKEv2)
Установка сертифікатів
Створення з'єднання
З'єднання

Windows Vista (IKE)
IKE на Windows Vista

OS X і iOS

Налаштування підключення на iOS і OS X

Android

Ви можете використовувати як IPsec клієнт Android і підключатися по протоколу IKE, так і клієнт strongSwan і використовувати IKEv2. Клієнт strongSwan працює стабільніше і надійно переподключает у разі втрати з'єднання.

Імпортуйте сертифікат або через файловий менеджер, або використовуючи пункт «Установка з SD-карти» в розділі «Безпека». Перейдіть в налаштування VPN, створити нове підключення з типом «IPSec Xauth RSA», в полі «Адреса сервера» введіть, власне, адресу сервера у поле «Сертифікат користувача IPSec» та «Сертифікат ЦС IPSec» вкажіть сертифікат «client1». Натисніть на з'єднання, введіть логін і пароль і спробуйте підключитися.

ВисновокIPsec, на мою думку, є чудовою альтернативою OpenVPN, який люблять багато адміністратори. Чому більшість VPN-провайдерів все ще використовують L2TP+IPsec для мене залишається загадкою, т. к. strongSwan надає всю необхідну функціональність для такого роду серивисов (повна підтримка Radius, море плагінів). Я використовую strongSwan на своєму сервісі вже близько півроку в режимі закритого тестування і він залишив про себе виключно позитивні враження.
IPsec, як я вже казав, дуже гнучкий і підтримує безліч аутентификаторов, тому ви можете робити навіть такі божевільні речі, як аутентифікація на SIM-карті в мобільному пристрої і зберігання публічних ключів в IPSECKEY-записи домену, захищеної DNSSEC.
Якщо ви боїтеся використовувати IPsec через документів NSA, які опубліковував Едвард Сноуден, будь ласка, прочитайте статтю don't stop using IPsec just yet, щоб розвіяти сумніви.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.