IKEv2 подключение на AltLinux - неожиданные проблемы
По работе понадобилось иметь доступ к некоторыми серверам в кушерях, с таким подключением. Ну и внезапно столкнулся с проблемами когда разные типовые конфигурации не сработали. Причем как не сработали - представьте себе два клиента, один стандартный клиент Windows (шлюз, логин, пароль - и привет), другой - NetworkManager-strongswan в альтлинукс. Оба в одной подсети. NM вообще не работает.
Повышаю логи харон - и вижу, что клиент в валидном но wildcard сертификате сервера находит CN типа *.domain.com. И естественно реальный сервер имеет отличное имя.
И по политикам клиента это харам все. Нельзя соединятся - рестрикшен там разный.... И хрен разберешь где работает, вроде как на клиенте. Наверняка есть опция "не паниковать если идент сервера кривой", но я не нашел.
Тут прислали мне скриншот добрые люди из NM ubuntы - и видно там что для таких случаев там поле предусмотрели, вводишь id ожидаемый от сервера и все ок (хотя вообще странно это - почему не галка: "принимать кривой идент сервера"? Хотя впрочем понятно - так больше определенности и безопасности. Абы что прислать нельзя.).
Ну а в альтлинуксе более старая версия NM - там этого костыля нет. Но, думаю - давай прям в файл конфигурации закину опцию remote-ident. И вуаля - соединение поднялось! Правда связи нет... И NM при любых попытках нажать ОК в свойствах подключения - неизвестные ему опции убирает. Что делать? решил собрать свежий NM. Ну и заодно плагин strongswan, ну и сам strongswan уже.
И все вроде бы проканало, но выяснилось, что нужен еще плагин под плазму,зачемто. А его без самой плазмы.... я даже не стал узнавать можно ли собрать. Так как даже если можно - то это уже спорт а не работа. Бросил это дело - дождусь обновления.
Ну и естественно - решил сам strongswan клиент настроить. Тот настроился с ходу, получил адреса, установил маршруты, подкинул DNS - но есть проблема. Связи нет.
Представьте себе - два клиента, один windows другой linux, в одной подсети. Оба соединяются, но под линуксом не работает связь в итоге.
IKEv2 сложный протокол - особенно в реализации под линукс, с его правилами и xfrm политиками - он совсем не похож на обычные туннельные протоколы. (да - вот так, всю жизнь считал ipsec разновидностью тоннельных протоколов и вот только сегодня вдруг по настоящему понял что это не так) Куча опций с довольно самобытными названиями напрягает). В общем - в итоге вышла такая шляпа:
Сначала добивался чтобы заработала esp in UDP. Понадобилось какие то переменные sysctl подправить чтобы трафик завернуло в политики ipsec. Ок. Но связь не заработала).
Стал снимать дамп на внешнем интерфейсе маршрутизатора, тоже альтлинукс кстати,- что там уходит. Вижу что уходят esp in udp, но ответа нет никакого. Ну может, думаю, кудато в другое место приходит ответ, какие нибудь попытки ответить на другой порт, изза того что сервер подозревает NAT а он не правильно работает... но нет. Все перепроверил.
Включил виндовс клиента, и вижу - те же самые пакеты уходят). Но на них сервер отвечает). И единственное отличие - чуть меньше длинна.
И тут я заподозрил что есть проблема с ключами esp. Постучался к ИИ, че-как, говорю, по умолчанию для esp в windows клиенте используется? Едрит тот накидал мне разного.... Ничего не подошло.
Отдельно хочется отметить что по идее опций по хешированию и тп - в настройках не было, тоесть клиент сам должен был согласовать вариант подходящий серверу, и непонятно почему - но он использовал не все алгоритмы для esp. Возможно sha128 уже всё... для разработчиков strngswan. А сервер - вероятно согласовался для использования sha256 для ike но при этом согласовал но не смог использовать для esp..... В итоге он просто не мог распаковать то что я ему прислал и тупо забил на моего клиента.
В общем - поставил я sha128 в настройках esp принудительно, и вуаля - сервер начал отвечать мне). Связь появилась.