IPsec задумывался как универсальный стек протоколов для VPN, после которого никаких других уже не нужно. Само существование OpenVPN, WireGuard и множества других протоколов доказывает, что достичь своей цели разработчикам IPsec не удалось.
Цена абсолютной универсальности и гибкости — чрезмерная сложность протокола, а значит, и сложность его настройки и отладки. Кроме того, первая версия IPsec разрабатывалась совсем в другое время, когда динамических адресов, NAT и мобильных подключений не существовало. Поменять архитектуру протокола было уже невозможно, поэтому он оброс расширениями и стал еще сложнее.
Казалось бы, можно просто забыть его как страшный сон и пользоваться более удобными решениями вроде того же OpenVPN. Но не все так просто — IPsec остается единственным общепризнанным стандартом и единственным протоколом, который поддерживает сетевое оборудование всех производителей.
Сервисам VPN, призванным повысить приватность, никто не диктует, что использовать, поскольку на их серверах и клиентах ОС общего назначения, на которую можно поставить что угодно. В корпоративных сетях такой свободы выбора может и не быть. А уж если ты соединяешь две сети на оборудовании разных поставщиков, то выбора может не быть вообще — только IPsec.
В общем, если ты занимаешься сетевым администрированием, избежать работы с IPsec вряд ли получится, несмотря на всю его сложность и неудобства. И если бы все ограничивалось сложностью самого протокола! Зачастую «веселья» добавляют различия реализаций, разные умолчания в них и не вполне адекватные админы на другой стороне, от которых не дождешься никакой отладочной информации. В этом случае настройка и отладка туннелей превращается в гадание по логам.
При этом логи IPsec зачастую полны специфичной терминологии и легко могут смутить новичка, еще незнакомого с протоколом в деталях. В этой статье мы рассмотрим ряд возможных ошибок настройки и их проявления в логах.
В качестве примера мы возьмем strongSwan. Эта свободная реализация IPsec (вернее, протокола IKE) весьма популярна и используется многими дистрибутивами Linux и FreeBSD для сетевых устройств: OpenWRT, pfSense, Sophos, VyOS и другими.
Основы
Протокол IPsec состоит из двух частей: протокола IKE (Internet Key Exchange) и протоколов AH и ESP (Authentication Header и Encapsulated Security Payload).
Протоколы AH и ESP отвечают за шифрование трафика и его аутентификацию с помощью встроенных в заголовок пакета подписей, они реализованы в ядре ОС или в аппаратной части маршрутизатора. Для их работы требуется согласование параметров шифрования. Набор из селекторов трафика и настроек, который указывает ядру, какой трафик и как шифровать, называется security association (SA). Во многих системах их можно настроить вручную. Например, в Linux это делается командой ip xfrm. На практике этот метод почти не используется из-за трудоемкости.
Для автоматизации обмена ключами и согласования настроек применяется протокол IKE. Его реализация — это обычно процесс в пространстве пользователя, который сам по себе никакой трафик и не шифрует, а просто создает security associations в ядре (в Linux — по протоколу netlink). Именно IKE обычно настраивают сетевые администраторы, и именно на этапе согласования параметров туннеля всплывают все ошибки и несовместимости в настройках.
Практика
Итак, давай развернем небольшой тестовый полигон, а потом разберемся непосредственно с логами.
Поднимаем туннель
Прежде всего нам понадобятся две машины с установленным strongSwan версии 5.2 или выше. Назовем их east и west. Присвоим им условные адреса 192.0.2.10 и 203.0.113.10.
Сети 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 специально зарезервированы для примеров и документации в RFC 5737. Условные публичные адреса правильнее всего брать именно из них.
Топология сети
Для простоты мы ограничимся статическим общим ключом (pre-shared key), хотя strongSwan поддерживает и ключи RSA, и сертификаты x.509.
Сначала создадим
Теперь создадим
Проверить состояния туннелей можно командой
Погасить или поднять туннель вручную можно командами вида
Включаем отладочные сообщения
По умолчанию strongSwan не показывает в логах никаких деталей происходящего. Это решение авторов в чем-то можно понять — если все работает, детальная запись диалога IKE будет просто ненужным шумом.
Если у тебя есть возможность править файлы настроек, то выбор опций там весьма широк. Применить изменения без перезапуска демона можно командой swanctl --reload-settings либо отправкой сигнала SIGHUP процессу charon.
Увы, в специализированных сетевых дистрибутивах этой возможности может и не быть — они бывают весьма чувствительны к попыткам что-то сделать в обход их интерфейса. Но не все потеряно! Если у тебя есть доступ по SSH, уровень детализации логов у работающего демона можно поменять командой
Уровни детализации бывают от -1 (не писать ничего) до 4 (выводить все, вплоть до секретных ключей). Уровень 3 включает вывод дампов пакетов, но не запись в логи секретной информации — оптимально для наших целей.
В IKE, увы, не предусмотрен механизм отправки детальных отчетов об ошибках — инициатору обычно придет просто no proposal chosen. Поэтому включать отладочные сообщения и смотреть их нужно на принимающей стороне. Если ты вынужден отлаживать неработающий туннель, переведи свой маршрутизатор в пассивный режим, в strongSwan — опцией
Несовместимые версии IKE
Нужно помнить, что существуют две версии IKE: старая IKEv1 и новая IKEv2. Вторая версия протокола решает очень много проблем первой: определение и настройка NAT traversal в большинстве случаев просто работает, в одном туннеле можно совместить несколько локальных и удаленных сетей, а полноценный механизм keepalive наконец позволил обеим сторонам видеть, что туннель все еще жив.
Однако IKEv1 и IKEv2, по сути, разные и не вполне совместимые протоколы. До версии 5.0 в strongSwan за них даже отвечали разные демоны (pluto и charon). В новых версиях вся функциональность объединена в charon, но различий между протоколами меньше не стало, и автоматический даунгрейд с IKEv2 на IKEv1 все так же невозможен.
В strongSwan версия протокола указывается опцией keyexchange. Пропишем в конфиг стороны east опцию keyexchange=ikev1, перезапустим туннель и посмотрим, что будет. На east мы получим то самое весьма расплывчатое сообщение no proposal chosen независимо от детализации логов.
На второй стороне в этом случае можно увидеть сообщение no IKE config found.
Решение: сообщить админу второй стороны свою версию IKE и попросить удостовериться в ее совпадении.
Неверный ключ
Если в твоих настройках адреса маршрутизаторов прописаны явно, сообщение будет вида MAC mismatched. Здесь MAC означает Message Authentication Code.
Несовместимые опции шифрования и PFS
PFS (Perfect Forward Secrecy) — это механизм обеспечения долговременной криптостойкости. Суть его в том, что на основе общего ключа вычисляется временный сессионный ключ. Сам по себе общий ключ никогда не используется напрямую: при установке соединения сразу генерируется временный ключ, который затем меняется по расписанию или при разрыве соединения. Таким образом, даже если злоумышленники подберут ключ, они получат только доступ к трафику текущей сессии. Когда время действия ключа истечет, им придется подбирать его заново, что непрактично.
Сессионный ключ вычисляется с помощью алгоритма Диффи — Хеллмана (DH), классического или на основе эллиптических кривых.
Подход к настройке PFS в сетевых устройствах бывает самым разным. В некоторых системах можно встретить настройку вроде PFS enable/disable, что так же бессмысленно, как опция «включить шифрование». Не бывает «просто» шифрования, бывает конкретный шифр и конкретный режим его работы, например AES-128-CBC. Не бывает и «просто» алгоритма выработки сессионных ключей.
На практике опция «включить PFS», как правило, подразумевает протокол DH group 2 (modp1024). Кстати, он уже считается устаревшим и небезопасным. Бывают и другие варианты, так что нужно уточнять в документации. Но можно это увидеть и в логах.
При высоких уровнях детализации strongSwan покажет тебе received proposals (что предлагает инициатор) и configured proposals (что настроено на твоей стороне).
Для эксперимента поменяем в конфиге west опцию esp=aes128-sha1! на esp=aes-128-sha1-modp2048!.
Мы увидим в логах следующее:
Порядок следования опций: шифр, хеш, PFS. Здесь мы видим, что шифр (AES-128) и хеш (SHA-1) совпадают, вся разница в опции MODP_2048: она есть в received proposals, но отсутствует в configured. Все опции с префиксами MODP и ECP — это названия групп для протокола DH. Соответствие номеров групп и обозначений MODP/ECP можно найти в документации к strongSwan.
Несовместимость шифра и хеша встречается реже, поскольку во всех системах их надо указывать явно — забыть их указать невозможно. Но теперь ты уже знаешь, куда смотреть. Формат опции шифра: $name_$mode_$keyLength. В нашем примере выше указан AES в режиме CBC с длиной ключа 128 бит.
Туннель «жив», а трафик не идет
Бывает и такое, и не так редко — особенно с IKEv1. По данным из вывода sudo ipsec statusall вроде все в норме, но трафик уходит и не возвращается. Дело в том, что в IKEv1 нет обязательного механизма двустороннего обмена пакетами keepalive. Таким образом, в промежутках между истечением времени жизни ключа процесс IKE никак не контролирует происходящее и реализация AH/ESP (то есть ядро ОС или аппаратный криптопроцессор) предоставлены сами себе. Пакеты будут шифроваться и отправляться, даже если на другой стороне никто не готов их принять.
Для борьбы с этим предназначены опции DPD (Dead Peer Detection). Однако значения тайм-аутов не входят в proposal и не согласуются между сторонами, так что даже при включенном DPD одна сторона может считать туннель живым куда дольше другой — в пределе до истечения IKE timeout, который может составлять много часов.
Если у тебя возникла такая проблема, не забывай уточнить у админа второй стороны значения всех таймеров DPD. Но еще лучше сразу уговаривай всех на IKEv2, где такие проблемы менее вероятны.
Заключение
Со стороны чтение логов IPsec может показаться особым искусством. Но если внимательно изучить детали работы протокола IKE, сообщения становятся куда понятнее, а отладка — быстрее.
автор Даниил Батурин
xakep.ru/author/dmbaturin
Цена абсолютной универсальности и гибкости — чрезмерная сложность протокола, а значит, и сложность его настройки и отладки. Кроме того, первая версия IPsec разрабатывалась совсем в другое время, когда динамических адресов, NAT и мобильных подключений не существовало. Поменять архитектуру протокола было уже невозможно, поэтому он оброс расширениями и стал еще сложнее.
Казалось бы, можно просто забыть его как страшный сон и пользоваться более удобными решениями вроде того же OpenVPN. Но не все так просто — IPsec остается единственным общепризнанным стандартом и единственным протоколом, который поддерживает сетевое оборудование всех производителей.
Сервисам VPN, призванным повысить приватность, никто не диктует, что использовать, поскольку на их серверах и клиентах ОС общего назначения, на которую можно поставить что угодно. В корпоративных сетях такой свободы выбора может и не быть. А уж если ты соединяешь две сети на оборудовании разных поставщиков, то выбора может не быть вообще — только IPsec.
В общем, если ты занимаешься сетевым администрированием, избежать работы с IPsec вряд ли получится, несмотря на всю его сложность и неудобства. И если бы все ограничивалось сложностью самого протокола! Зачастую «веселья» добавляют различия реализаций, разные умолчания в них и не вполне адекватные админы на другой стороне, от которых не дождешься никакой отладочной информации. В этом случае настройка и отладка туннелей превращается в гадание по логам.
При этом логи IPsec зачастую полны специфичной терминологии и легко могут смутить новичка, еще незнакомого с протоколом в деталях. В этой статье мы рассмотрим ряд возможных ошибок настройки и их проявления в логах.
В качестве примера мы возьмем strongSwan. Эта свободная реализация IPsec (вернее, протокола IKE) весьма популярна и используется многими дистрибутивами Linux и FreeBSD для сетевых устройств: OpenWRT, pfSense, Sophos, VyOS и другими.
Основы
Протокол IPsec состоит из двух частей: протокола IKE (Internet Key Exchange) и протоколов AH и ESP (Authentication Header и Encapsulated Security Payload).
Протоколы AH и ESP отвечают за шифрование трафика и его аутентификацию с помощью встроенных в заголовок пакета подписей, они реализованы в ядре ОС или в аппаратной части маршрутизатора. Для их работы требуется согласование параметров шифрования. Набор из селекторов трафика и настроек, который указывает ядру, какой трафик и как шифровать, называется security association (SA). Во многих системах их можно настроить вручную. Например, в Linux это делается командой ip xfrm. На практике этот метод почти не используется из-за трудоемкости.
Для автоматизации обмена ключами и согласования настроек применяется протокол IKE. Его реализация — это обычно процесс в пространстве пользователя, который сам по себе никакой трафик и не шифрует, а просто создает security associations в ядре (в Linux — по протоколу netlink). Именно IKE обычно настраивают сетевые администраторы, и именно на этапе согласования параметров туннеля всплывают все ошибки и несовместимости в настройках.
Практика
Итак, давай развернем небольшой тестовый полигон, а потом разберемся непосредственно с логами.
Поднимаем туннель
Прежде всего нам понадобятся две машины с установленным strongSwan версии 5.2 или выше. Назовем их east и west. Присвоим им условные адреса 192.0.2.10 и 203.0.113.10.
Сети 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 специально зарезервированы для примеров и документации в RFC 5737. Условные публичные адреса правильнее всего брать именно из них.
Топология сети
Для простоты мы ограничимся статическим общим ключом (pre-shared key), хотя strongSwan поддерживает и ключи RSA, и сертификаты x.509.
Сначала создадим
/etc/ipsec.conf и /etc/ipsec.secrets для east.
Код:
config setup
conn tunnel-west
left=192.0.2.10
right=203.0.113.10
leftsubnet=10.20.30.0/24
rightsubnet=10.40.50.0/24
leftsubnet=10.20.30.0/24
ike=aes128-sha1-modp2048!
keyexchange=ikev2
reauth=no
ikelifetime=28800s
closeaction=none
esp=aes128-sha1!
keylife=3600s
rekeymargin=540s
type=tunnel
compress=no
authby=secret
auto=start
keyingtries=%forever
Код:
192.0.2.10 203.0.113.10 : PSK "qwerty"Теперь создадим
/etc/ipsec.conf и /etc/ipsec.secrets для west.
Код:
config setup
conn tunnel-east
left=203.0.113.10
right=192.0.2.10
leftsubnet=10.40.50.0/24
rightsubnet=10.20.30.0/24
leftsubnet=10.40.50.0/24
ike=aes128-sha1-modp2048!
keyexchange=ikev2
reauth=no
ikelifetime=28800s
closeaction=none
esp=aes128-sha1!
keylife=3600s
rekeymargin=540s
type=tunnel
compress=no
authby=secret
auto=route
keyingtries=1
Код:
203.0.113.10 192.0.2.10 : PSK "qwerty"sudo ipsec statusall. Если ты нигде не ошибся, ты увидишь там что-то вроде такого:
Код:
Security Associations (1 up, 0 connecting):
tunnel-west[5]: ESTABLISHED 65 minutes ago, 192.0.2.10[192.0.2.10]...203.0.113.10[203.0.113.10]
tunnel-west[5]: IKEv2 SPIs: 625b6b882998fc83_i* edc6c365bf5aaabc_r, rekeying in 6 hours
tunnel-west[5]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048sudo ipsec up/down tunnel-west. Включаем отладочные сообщения
По умолчанию strongSwan не показывает в логах никаких деталей происходящего. Это решение авторов в чем-то можно понять — если все работает, детальная запись диалога IKE будет просто ненужным шумом.
Если у тебя есть возможность править файлы настроек, то выбор опций там весьма широк. Применить изменения без перезапуска демона можно командой swanctl --reload-settings либо отправкой сигнала SIGHUP процессу charon.
Увы, в специализированных сетевых дистрибутивах этой возможности может и не быть — они бывают весьма чувствительны к попыткам что-то сделать в обход их интерфейса. Но не все потеряно! Если у тебя есть доступ по SSH, уровень детализации логов у работающего демона можно поменять командой
sudo ipsec stroke loglevel ike 3.Уровни детализации бывают от -1 (не писать ничего) до 4 (выводить все, вплоть до секретных ключей). Уровень 3 включает вывод дампов пакетов, но не запись в логи секретной информации — оптимально для наших целей.
В IKE, увы, не предусмотрен механизм отправки детальных отчетов об ошибках — инициатору обычно придет просто no proposal chosen. Поэтому включать отладочные сообщения и смотреть их нужно на принимающей стороне. Если ты вынужден отлаживать неработающий туннель, переведи свой маршрутизатор в пассивный режим, в strongSwan — опцией
auto=route.Несовместимые версии IKE
Нужно помнить, что существуют две версии IKE: старая IKEv1 и новая IKEv2. Вторая версия протокола решает очень много проблем первой: определение и настройка NAT traversal в большинстве случаев просто работает, в одном туннеле можно совместить несколько локальных и удаленных сетей, а полноценный механизм keepalive наконец позволил обеим сторонам видеть, что туннель все еще жив.
Однако IKEv1 и IKEv2, по сути, разные и не вполне совместимые протоколы. До версии 5.0 в strongSwan за них даже отвечали разные демоны (pluto и charon). В новых версиях вся функциональность объединена в charon, но различий между протоколами меньше не стало, и автоматический даунгрейд с IKEv2 на IKEv1 все так же невозможен.
В strongSwan версия протокола указывается опцией keyexchange. Пропишем в конфиг стороны east опцию keyexchange=ikev1, перезапустим туннель и посмотрим, что будет. На east мы получим то самое весьма расплывчатое сообщение no proposal chosen независимо от детализации логов.
Код:
rtr-east charon[13411]: 06[NET] sending packet: from 192.0.2.10[500] to 203.0.113.10[500] (336 bytes)
rtr-east charon[13411]: 08[NET] received packet: from 203.0.113.10[500] to 192.0.2.10[500] (36 bytes)
rtr-east charon[13411]: 08[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
rtr-east charon[13411]: 08[IKE] received NO_PROPOSAL_CHOSEN notify error
rtr-east charon[13411]: 08[IKE] IKE_SA tunnel-west[2] state change: CONNECTING => DESTROYING
Код:
rtr-west charon[14183]: 14[IKE] no IKE config found for 203.0.113.10...192.0.2.10, sending NO_PROPOSAL_CHOSENНеверный ключ
Если в твоих настройках адреса маршрутизаторов прописаны явно, сообщение будет вида MAC mismatched. Здесь MAC означает Message Authentication Code.
Код:
rtr-east charon[13411]: 16[IKE] tried 1 shared key for '192.0.2.10' - '203.0.113.10', but MAC mismatchedНесовместимые опции шифрования и PFS
PFS (Perfect Forward Secrecy) — это механизм обеспечения долговременной криптостойкости. Суть его в том, что на основе общего ключа вычисляется временный сессионный ключ. Сам по себе общий ключ никогда не используется напрямую: при установке соединения сразу генерируется временный ключ, который затем меняется по расписанию или при разрыве соединения. Таким образом, даже если злоумышленники подберут ключ, они получат только доступ к трафику текущей сессии. Когда время действия ключа истечет, им придется подбирать его заново, что непрактично.
Сессионный ключ вычисляется с помощью алгоритма Диффи — Хеллмана (DH), классического или на основе эллиптических кривых.
Подход к настройке PFS в сетевых устройствах бывает самым разным. В некоторых системах можно встретить настройку вроде PFS enable/disable, что так же бессмысленно, как опция «включить шифрование». Не бывает «просто» шифрования, бывает конкретный шифр и конкретный режим его работы, например AES-128-CBC. Не бывает и «просто» алгоритма выработки сессионных ключей.
На практике опция «включить PFS», как правило, подразумевает протокол DH group 2 (modp1024). Кстати, он уже считается устаревшим и небезопасным. Бывают и другие варианты, так что нужно уточнять в документации. Но можно это увидеть и в логах.
При высоких уровнях детализации strongSwan покажет тебе received proposals (что предлагает инициатор) и configured proposals (что настроено на твоей стороне).
Для эксперимента поменяем в конфиге west опцию esp=aes128-sha1! на esp=aes-128-sha1-modp2048!.
Мы увидим в логах следующее:
Код:
rtr-west charon[14183]: 08[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
rtr-west charon[14183]: 08[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
rtr-west charon[14183]: 08[IKE] no acceptable proposal foundНесовместимость шифра и хеша встречается реже, поскольку во всех системах их надо указывать явно — забыть их указать невозможно. Но теперь ты уже знаешь, куда смотреть. Формат опции шифра: $name_$mode_$keyLength. В нашем примере выше указан AES в режиме CBC с длиной ключа 128 бит.
Туннель «жив», а трафик не идет
Бывает и такое, и не так редко — особенно с IKEv1. По данным из вывода sudo ipsec statusall вроде все в норме, но трафик уходит и не возвращается. Дело в том, что в IKEv1 нет обязательного механизма двустороннего обмена пакетами keepalive. Таким образом, в промежутках между истечением времени жизни ключа процесс IKE никак не контролирует происходящее и реализация AH/ESP (то есть ядро ОС или аппаратный криптопроцессор) предоставлены сами себе. Пакеты будут шифроваться и отправляться, даже если на другой стороне никто не готов их принять.
Для борьбы с этим предназначены опции DPD (Dead Peer Detection). Однако значения тайм-аутов не входят в proposal и не согласуются между сторонами, так что даже при включенном DPD одна сторона может считать туннель живым куда дольше другой — в пределе до истечения IKE timeout, который может составлять много часов.
Если у тебя возникла такая проблема, не забывай уточнить у админа второй стороны значения всех таймеров DPD. Но еще лучше сразу уговаривай всех на IKEv2, где такие проблемы менее вероятны.
Заключение
Со стороны чтение логов IPsec может показаться особым искусством. Но если внимательно изучить детали работы протокола IKE, сообщения становятся куда понятнее, а отладка — быстрее.
автор Даниил Батурин
xakep.ru/author/dmbaturin