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. INFO Сети 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.