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 просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.
Все современные десктопные ОС (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
Жизнь со swanctl: 
Жизнь без swanctl: 
Переходим к настройке
Будем настраивать подключение через 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 на каждом шагу, чтобы ключи не были защищены паролем (его можно установить позже в любое время).
Переходим к настройке strongSwan!
Первым делом, указываем наш приватный ключ в /etc/ipsec.secrets
Редактируем конфигурационный файл /etc/ipsec.conf
Теперь у нас есть три подключения: ikev2-pubkey для IKEv2, ikev1-fakexauth для IKEv1 с фейковой проверкой логина и пароля и ikev2-eap-tls — IKEv2+EAP-TLS для Windows Phone. Перезапускаем strongSwan.
Проблемы 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». Нажмите на соединение, введите любые логин и пароль и попробуйте подключиться.
Настройте L2TP / IPsec VPN-сервер с PSK или RSA в pfSense
Для чего нужен VPN-сервер L2TP / IPsec?
VPN-сервер в нашем pfSense позволит нам получить удаленный доступ к различным подсетям, которые мы настроили, он также позволит нам перенаправить весь интернет-трафик на VPN-сервер для выхода в Интернет через него. Благодаря конфигурации VPN-сервера мы сможем безопасно подключаться к незащищенной сети, потому что весь трафик от источника до VPN-сервера зашифрован и аутентифицирован.
Учитывая все это, организация IETF приняла решение использовать криптографические протоколы IPsec в сочетании с L2TP, чтобы обеспечить функции конфиденциальности, аутентификации и целостности туннеля L2TP. По этой причине мы всегда найдем этот протокол, записанный как «L2TP / IPsec» в операционных системах, поскольку он использует оба протокола одновременно.
Как только у нас будет сводка о том, как работают оба протокола VPN, мы продолжим настройку. Имея два протокола для настройки, L2TP и IPsec, мы четко разделим конфигурацию на две части.
Конфигурация протокола L2TP
После того, как мы его настроили и нажали «Сохранить», мы переходим в раздел «Пользователи» и создаем имя пользователя и пароль для доступа. Здесь нам нужно будет зарегистрировать всех пользователей VPN-сервера, к которому они собираются подключиться. Часть IP-адреса можно оставить пустой без настройки, чтобы сервер назначал IP-адрес динамически.
После настройки сервера L2TP мы можем настроить протокол IPsec.
Конфигурация протокола IPsec
Настроить «Мобильные клиенты»
В этом меню мы включаем «Включить поддержку мобильного клиента IPsec» и выбираем «Локальная база данных», хотя мы будем использовать ее, потому что это для аутентификации xAuth. Нажимаем на сохранить.
Как только мы нажмем «Сохранить», нам также нужно будет нажать «Применить изменения», а затем нажать зеленую кнопку, обозначающую «Создать фазу1».
Настроить IPsec Phase 1
В этом меню нам нужно будет правильно настроить протокол IPsec, чтобы использовать его с L2TP, не все конфигурации будут работать, кроме того, в зависимости от используемого VPN-клиента (Android, Ios, Windows …) Конфигурация безопасности может измениться, поскольку не все операционные системы поддерживают лучшие шифры VPN. По умолчанию мы увидим следующее меню, в котором мы выбрали IKEv2, который несовместим с протоколом L2TP / IPsec, который мы хотим настроить.
pfSense поддерживает более надежное шифрование, чем это, которое мы настроили, но проблема в том, что VPN-клиенты, которые будут подключаться, не поддерживают более высокий уровень безопасности. Чтобы настроить его с максимальной безопасностью, мы можем пройти тестирование на основе «полученных предложений» IPsec, которые мы получаем от клиента, таким образом, мы выберем наиболее безопасный из всех.
Остальные параметры конфигурации можно оставить без изменений с параметрами по умолчанию.
По завершении мы нажимаем «Сохранить», и теперь мы попадаем в главное меню, где у нас есть все VPN-туннели с IPsec, нам нужно будет нажать на единственный созданный и на «Показать записи фазы 2», а затем на «Create Phase 2», чтобы продолжить.
Настроить IPsec Phase 2
Остальные параметры конфигурации можно оставить по умолчанию.
В главном меню «IPsec / Tunnels» мы можем увидеть сводку всего, что мы настроили.
Теперь нам нужно перейти в раздел «IPsec / Pre-Shared Keys» и добавить новый идентификатор.
Как только это будет сделано, у нас будет сервер L2TP / IPsec, готовый принимать соединения, но сначала мы должны создать соответствующие правила в брандмауэре.
Откройте порты в брандмауэре pfSense
Сохраняем и применяем изменения, следя за соблюдением этого правила.
Когда мы создаем VPN-сервер типа L2TP / IPsec, у нас будут две дополнительные вкладки в «Брандмауэр / Правила», здесь мы можем разрешить или запретить трафик в определенные подсети, определить различные расширенные правила и т. Д. Для первого подключения и во избежание возможных сбои конфигурации на уровне брандмауэра, мы рекомендуем вам создать правило «передать любое любое» и применить изменения. Позже, когда связь будет установлена, если вам нужно будет определить другие правила, вы сможете редактировать более конкретные правила, чтобы они соответствовали всем вашим требованиям.
После того, как мы успешно настроили брандмауэр, нам нужно будет настроить VPN-клиент для проверки соединения.
Тест подключения
Нажимаем на сохранить, и подключаемся. При подключении он запросит у нас имя пользователя и пароль, эти учетные данные мы вводим в «Пользователи L2TP». После этого он без проблем подключит нас к серверу VPN, и у нас будет доступ к администрированию pfSense и любой сети.
Как вы видели, соединение было успешно установлено и никаких проблем не возникло.
Рекомендации и советы
В зависимости от используемого VPN-клиента конфигурация сервера может отличаться. В целях безопасности всегда рекомендуется использовать лучшие криптографические алгоритмы, по этой причине мы рекомендуем изменить параметры безопасности и заставить клиентов всегда выбирать лучшие, однако мы должны посмотреть записи IPsec, чтобы увидеть, какое «предложение» отправлено. разными клиентами при подключении. Некоторые смартфоны используют клиент L2TP / IPsec VPN с поддержкой новейших шифров, однако другие модели этого не делают. Нам нужно будет попытаться выбрать наиболее безопасный в глобальном масштабе, балансируя между безопасностью и удобством использования.
С помощью этого же руководства вы сможете настроить L2TP / IPsec RSA, изменив «Mutual PSK» на «Mutual RSA» и настроив соответствующие сертификаты сервера и клиента. Мы скоро покажем вам, как это сделать. Это также создает сложности, потому что, если мы создадим CA с клиентским сертификатом, который использует новейшие алгоритмы, возможно, что он вернет ошибку при подключении, потому что они не распознаются.
IPSec всемогущий
История вопроса
Изначально VPN планировался только для организации канала между мини-роутером родителей и домашним «подкроватным» сервером, по совместительству выступающим в роли маршрутизатора.
Спустя небольшой промежуток времени к этой компании из двух устройств добавился Keenetic.
Но единожды начав, остановиться оказалось сложно, и вскоре на схеме появились телефоны и ноутбук, которым захотелось скрыться от всевидящего рекламного ока MT_Free и прочих нешифрованных WiFi-сетей.
Потом у всеми любимого РКН наконец-то окреп банхаммер, которым он несказанно полюбил прилюдно размахивать во все стороны, и для нейтрализации его заботы о простых смертных пришлось поддержать иностранный IT-сектор приобрести VPS за рубежом.
К тому же некоей гражданке, внешне напоминающей Шапокляк, всюду бегающей со своим ридикюлем Пакетом и, вероятно, считающей что «Кто людям помогает — тот тратит время зря. Хорошими делами прославиться нельзя», захотелось тайком подглядывать в чужой трафик и брать его на карандаш. Придется тоже защищаться от такой непрошенной любви и VPN в данном случае именно то, что доктор прописал.
Подведем небольшой итог. Нужно было подобрать решение, которое в идеале способно закрыть сразу несколько поставленных задач:
Обзор существующих решений
Коротко пройдемся по тому что есть сейчас:
Дедушка Ленин всех протоколов. Умер, «разложился на плесень и на липовый мёд».
Кто-то, кроме одного провайдера, это использует?
Проект развивается. Активно пилится. Легко создать туннель между двумя пирами, имеющими статический IP. В остальных случаях на помощь всегда готовы придти костыли, велосипеды с квадратными колёсами и синяя изолента, но это не наш путь.
Приступаем к настройке
Определившись с решением приступаем к настройке. Схема сети в моем случае имеет следующий вид (убрал под спойлер)
ipsecgw.example.com — домашний сервер, являющийся центром сети. Внешний IP 1.1.1.1. Внутренняя сеть 10.0.0.0/23 и еще один адрес 10.255.255.1/30 для установки приватной BGP-сессии с VPS;
mama — Linux-роутер на базе маленького беззвучного неттопа, установленный у родителей. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.3.0/24;
keenetic — маршрутизатор Keenetic с установленным модулем IPSec. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.4.0/24;
road-warriors — переносные устройства, подключающиеся из недоверенных сетей. Адреса клиентам выдаются динамически при подключении из внутренного пула (10.1.1.0/24);
rkn.example.com — VPS вне юрисдикции уважаемого РКН. Внешний IP — 5.5.5.5, внутренний адрес 10.255.255.2/30 для установки приватной BGP-сессии.
Первый шаг. От простого к сложному: туннели с использованием pre-shared keys (PSK)
На обоих Linux-box устанавливаем необходимые пакеты:
На обоих хостах открываем порты 500/udp, 4500/udp и разрешаем прохождение протокола ESP.
Правим файл /etc/strongswan/ipsec.secrects (на стороне хоста ipsecgw.example.com) и вносим следующую строку:
На второй стороне аналогично:
В данном случае в качестве ID выступает вымышленный адрес элестронной почты. Больше информации можно подчерпнуть на официальной вики.
Секреты сохранены, движемся дальше.
На хосте ipsecgw.example.com редактируем файл /etc/strongswan/ipsec.conf:
Аналогично редактируем на удаленном пире /etc/strongswan/ipsec.conf:
Если сравнить конфиги, то можно увидеть что они почти зеркальные, перекрёстно поменяны местами только определения пиров.
Директива auto = route заставляет charon установить ловушку для трафика, подпадающего в заданные директивами left/rightsubnet (traffic selectors). Согласование параметров туннеля и обмен ключами начнутся немедленно после появления трафика, попадающего под заданные условия.
На сервере ipsecgw.example.com в настройках firewall запрещаем маскарадинг для сети 10.0.3.0/24. Разрешаем форвардинг пакетов между 10.0.0.0/23 и 10.0.3.0/24 и наоборот. На удаленном узле выполняем аналогичные настройки, запретив маскарадинг для сети 10.0.0.0/23 и настроив форвардинг.
Рестартуем strongswan на обоих серверах и пробуем выполнить ping центрального узла:
Нелишним будет так же убедиться что в файле /etc/strongswan/strongswan.d/charon.conf на всех пирах параметр make_before_break установлен в значение yes. В данном случае демон charon, обслуживающий протокол IKEv2, при выполнении процедуры смены ключей не будет удалять текущую security association, а сперва создаст новую.
Шаг второй. Появление Keenetic
Приятной неожиданностью оказался встроенный IPSec VPN в официальной прошивке Keenetic. Для его активации достаточно перейти в Настройки компонентов KeeneticOS и добавить пакет IPSec VPN.
Готовим настройки на центральном узле, для этого:
Правим /etc/strongswan/ipsec.secrects и добавляем PSK для нового пира:
Правим /etc/strongswan/ipsec.conf и добавляем в конец еще одно соединение:
Со стороны Keenetic настройка выполняется в WebUI по пути: Интернет → Подключения →
Другие подключения. Всё довольно просто.
Если планируется через тоннель гонять существенные объемы трафика, то можно попробовать включить аппаратное ускорение, которое поддерживается многими моделями. Включается командой crypto engine hardware в CLI. Для отключения и обработки процессов шифрования и хеширования при помощи инструкций CPU общего назначения — crypto engine software
После сохранения настроек рестрартуем strongswan и даём подумать полминуты Keenetic-у. После чего в терминале видим успешную установку соединения:
Шаг третий. Защищаем мобильные устройства
После чтения стопки мануалов и кучи статей решено было остановиться на связке бесплатного сертификата от Let’s Encrypt для проверки подлинности сервера и классической авторизации по логину-паролю для клиентов. Тем самым мы избавляемся от необходимости поддерживать собственную PKI-инфраструктуру, следить за сроком истечения сертификатов и проводить лишние телодвижения с мобильными устройствами, устанавливая самоподписанные сертификаты в список доверенных.
Устанавливаем недостающие пакеты:
Получаем standalone сертификат (не забываем предварительно открыть 80/tcp в настройках iptables):
После того как certbot завершил свою работу мы должны научить Strongswan видеть наш сертификат:
Перезапускаем Strongswan и при вызове sudo strongswan listcerts мы должны видеть информацию о сертификате:
После чего описываем новое соединение в ipsec.conf:
Не забываем отредактировать файл /etc/sysconfig/certbot указав, что обновлять сертификат тоже будем как standalone, внеся в него CERTBOT_ARGS=»—standalone».
Так же не забываем включить таймер certbot-renew.timer и установить хук для перезапуска Strongswan в случае выдачи нового сертификата. Для этого либо размещаем простенький bash-скрипт в /etc/letsencrypt/renewal-hooks/deploy/, либо еще раз редактируем файл /etc/sysconfig/certbot.
Перезапускаем Strongswan, включаем в iptables маскарадинг для сети 10.1.1.0/24 и переходим к настройке мобильных устройств.
Android
Устанавливем из Google Play приложение Strongswan.
Запускаем и создаем новый
Сохраняем профиль, подключаемся и, спустя секунду, можем не переживать о том, что кто-то сможет подсматривать за нами.
Windows
Windows актуальных версий приятно удивил. Вся настройка нового VPN происходит путем вызова двух командлетов PowerShell:
И еще одного, в случае если Strongswan настроен на выдачу клиентам IPv6 адреса (да, он это тоже умеет):
Часть четвертая, финальная. Прорубаем окно в Европу
Насмотревшись провайдерских заглушек «Сайт заблокирован по решению левой пятки пятого зампрокурора деревни Трудовые Мозоли Богозабытского уезда» появилась и жила себе одна маленькая неприметная VPS (с благозвучным доменным именем rkn.example.com) в тысяче километров от обезьянок, любящих размахивать банхаммером и блокировать сети размером /16 за раз. И крутилось на этой маленькой VPS прекрасное творение коллег из NIC.CZ под названием BIRD. Птичка первой версии постоянно умирала в панике от активности обезьянок с дубинками, забанивших на пике своей трудовой деятельности почти 4% интернета, уходя в глубокую задумчивость при реконфиге, поэтому была обновлена до версии 2.0.7. Если читателям будет интересно — опубликую статью по переходу с BIRD на BIRD2, в котором кардинально изменился формат конфига, но работать новая вервия стала намного быстрее и нет проблем с реконфигом при большом количестве маршрутов. А раз у нас используется протокол динамической маршрутизации, то должен быть и сетевой интерфейс, через который нужно роутить трафик. По умолчанию IPSec интерфейсов не создает, но за счет его гибкости мы можем воспользоваться классическими GRE-туннелями, которые и будем защищать в дальнейшем. В качестве бонуса — хосты ipsecgw.example.com и rkn.example.com будут аутентифицировать друга друга, используя самообновляемые сертификаты Lets Encrypt. Никаких PSK, только сертификаты, только хардкор, безопасности много не бывает.
Считаем что VPS подготовлена, Strongswan и Certbot уже установлены.
На хосте ipsecgw.example.com (его IP — 1.1.1.1) описываем новый интерфейс gif0:
Зеркально на хосте vps.example.com (его IP — 5.5.5.5):
Поднимаем интерфейсы, но поскольку в iptables нет правила, разрешающего GRE-протокол, трафик ходить не будет (что нам и надо, поскольку внутри GRE нет никакой защиты от любителей всяких законодательных «пакетов»).
Готовим VPS
Первым делом получаем еще один сертификат на доменное имя rkn.example.com. Создаем симлинки в /etc/strongswan/ipsec.d как описано в предыдущем разделе.
Правим ipsec.secrets, внося в него единственную строку:
На стороне хоста ipsecgw.example.com тоже добавляем в ipsec.conf в секцию setup параметр strictcrlpolicy = yes, включающий строгую проверку CRL. И описываем еще одно соединение:
Конфиги почти зеркальные. Внимательный читатель мог сам уже обратить внимание на пару моментов:
/rkn.example.com.pem, после чего при помощи scp перекрестно копируем их между серверами в расположения, указаные в конфиге
Не забываем настроить файрвол и автообновление сертификатов. После перезапуска Strongswan на обоих серверах, запустим ping удаленной стороны GRE-туннеля и увидим успешную установку соединения. На VPS (rkn):
И на стороне хоста ipsecgw
Туннель установлен, пинги ходят, в tcpdump видно что между хостами ходит только ESP. Казалось бы можно радоваться. Но нельзя расслабляться не проверив всё до конца. Пробуем перевыпустить сертификат на VPS и…
Шеф, всё сломалось
Начинаем разбираться и натыкаемся на одну неприятную особенность прекрасного во всём остальном Let’s Encrypt — при любом перевыпуске сертификата меняется так же ассоциированный с ним закрытый ключ. Изменился закрытый ключ — изменился и открытый. На первый взгляд ситуация для нас безвыходная: если даже открытый ключ мы можем легко извлечь во время перевыпуска сертификата при помощи хука в certbot и передать его удаленной стороне через SSH, то непонятно как заставить удаленный Strongswan перечитать его. Но помощь пришла откуда не ждали — systemd умеет следить за изменениями файловой системы и запускать ассоциированные с событием службы. Этим мы и воспользуемся.
Создадим на каждом из хостов служебного пользователя keywatcher с максимально урезанными правами, сгенерируем каждому из них SSH-ключи и обменяемся ими между хостами.
На хосте ipsecgw.example.com создадим каталог /opt/ipsec-pubkey в котором разместим 2 скрипта.
На VPS (хосте rkn.example.com) аналогично создаем каталог с тем же именем, в котором тоже создаем аналогичные скрипты, изменяя только название ключа. Код, чтобы не загромождать статью, под
sudo vi /opt/ipsec-pubkey/pubkey-copy.sh
Скрипт pubkey-copy.sh нужен для извлечения открытой части ключа и копирования его удаленному хосту во время выпуска нового сертификата. Для этого в каталоге /etc/letsencrypt/renewal-hooks/deploy на обоих серверах создаем еще один микроскрипт:
Половина проблемы решена, сертификаты перевыпускаются, публичные ключи извлекаются и копируются между серверами и пришло время systemd с его path-юнитами.
На сервере ipsecgw.example.com в каталоге /etc/systemd/system создаем файл keyupdater.path
Аналогично на VPS хосте:
И, напоследок, на каждом сервере создаем ассоциированную с данным юнитом службу, которая будет запускаться при выполнении условия (PathChanged) — изменении файла и его закрытии его после записи. Создаем файлы /etc/systemd/system/keyupdater.service и прописываем:
Не забываем перечитать конфигурации systemd при помощи sudo systemctl daemon-reload и назначить path-юнитам автозапуск через sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater.path.
Как только удаленный хост запишет файл, содержащий публичный ключ, в домашний каталог пользователя keywatcher и файловый дескриптор будет закрыт, systemd автоматически запустит соответствующую службу, которая скопирует ключ в нужное расположение и перезапустит Strongswan. Туннель будет установлен, используя правильный открытый ключ второй стороны.
Можно выдохнуть и наслаждаться результатом.
Вместо заключения
Как мы только что увидели чёрт IPSec не так страшен, как его малюют. Всё, что было описано — полностью рабочая конфигурация, которая используется в настоящее время. Даже без особых знаний можно настроить VPN и надежно защитить свои данные.
Конечно за рамками статьи остались моменты настройки iptables, но и сама статья уже получилась и без того объемная и про iptables написано много.
Есть в статье и моменты, которые можно улучшить, будь-то отказ от перезапусков демона Strongswan, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.
Впрочем и рестарты демона оказались не страшны: происходит потеря одного-двух пингов между пирами, мобильные клиенты тоже сами восстанавливают соединение.
Надеюсь коллеги в комментариях подскажут правильное решение.
