Прямо пойдёшь - и там грабли…
Как неоднократно замечал dmarck, мне давно надо было переквалифицироваться из сисадмина в тестера. Ибо я наступаю на такие грабли, которых остальные почти никогда не замечают.
Недавно настраивал очередной IPsec-туннель. Казалось бы, чего тут может быть сложного..
Но когда я попробовал попингать c местной машинки клиентскую - не получилось. Запустил на этом pfSense tcpdump, он показал, что гейты друг с другом общаются, первая фаза вроде как нормально отрабатывает, значит пароль точно правильный, потом проходит несколько пакетов второй фазы, а потом всё резко замолкает..
Посмотрел в логи - и вправду, первая фаза успешно проходит, потом во второй фазе посылается предложение SA, а с той стороны в ответ приходит DELETE for IKE_SA. Чем-то, значит, ихней циске эта SA настолько не нравится, что она её не просто игнорирует, а вообще предлагает всё закрыть. Сравнили IPsec’овые конфиги, вроде всё одинаковое. Но не работает. Долго думал, что может быть не так, ничего не придумал.
Пошёл смотреть поглубже в логи. Включил повышенный уровень логгирования, и тут увидел, что в том предложении SA локальный IP правильный, а клиентский почему-то превращён в подсетку /24. Пошёл внимательно разглядывать настройки, а… там и вправду ко всем клиентским адресам подписано /24. Стало понятно, почему эти предложения с той стороны отвергают. Но откуда эти подсетки взялись в настройках, я же их точно не вводил.. Пригляделся, оказалось, что pfSense в веб-интерфейсе по умолчанию ожидает не просто адрес, а подсетку. И хотя маску там не видно, но если её явно не указать, то при сохранении записи автоматически добавляется /24.
Первым делом попробовал во всех SA-записях поменять маску на /32, но pfSense всё равно продолжал посылать предложения про /24, и циска продолжала их отплёвывать. Убрал из всех записей сетки, заменив их на конкретные IP, а всё равно при появлении трафика на ту сторону отправляются предложения про /24..
Пошёл смотреть в конфигурационные файлы. В /cf/conf/config.xml всё как надо, указаны конкретные адреса, никаких подсеток. И в /var/etc/ipsec/ipsec.conf во всех rightsubnet тоже просто IPшники, без всяких масок. Так откуда ж они берутся..
Попробовал удалить из настроек SA-запись про IPшники, между которыми я запускал ping, создал её заново, запустил ping, а туннель опять попытался подняться с той же /24, и опять отвалился. Удалил эту запись совсем, вроде как теперь от того ping’а туннель подниматься не должен, ан опять всё то же самое. Отключил весь этот VPN совсем, в config.xml он стал disabled, из ipsec.conf вообще исчез, но при запуске ping’а туннель опять пытался подняться на клиентскую подсетку /24, и опять отваливался..
Видать, оно всё где-то давненько закэшировалось, и все последующие изменения никакого эффекта не оказывали. Попробовал перезапустить ipsec из веб-интерфейса, ничего не поменялось. Попробовал из командной строки - всё то же самое. Попробовал не просто ipsec restart, а stop, потом start, и всё равно никакого эффекта…
Что тут делать? Хорошо бы весь сервер перезапустить, но нельзя, через него множество других клиентов подключено. Посмотрел внимательно, оказалось, что ipsec stop почему-то останавливает только ipsec/starter, а ipsec/charon продолжает работать. Прибил его kill‘ом, запустил ipsec start, и тут конфиги перечитались, и всё наконец-то заработало как надо. Но на хождение по этим граблям ушёл почти весь день..
Оригинал этой записи в личном блоге.
(
| Комментировать в Dreamwidth)