Соединение между MikroTik и FortiGate устанавливалось. На экране был статус established, но связь через туннель работала с заметными потерями. В отдельных контрольных сериях не возвращалось около 40% пакетов.
При этом домашний шлюз отвечал без потерь. Значит, одного статуса подключения было недостаточно: требовалось проверить, что происходит с трафиком внутри туннеля.
В итоге я согласовал параметры Phase 2 на двух устройствах. После изменения две параллельные серии по 120 пакетов прошли без потерь, а прежняя перегрузка обработкой IPsec исчезла.
Почему я не остановился на статусе established
У IPsec есть несколько уровней состояния. Устройства могут установить управляющее соединение, но это ещё не подтверждает нормальную передачу данных между всеми нужными сетями.
Поэтому я проверял три вещи отдельно:
- отвечает ли ближайший домашний шлюз;
- проходят ли пакеты к узлам за туннелем;
- как в это время меняются нагрузка и состояние IPsec.
Проверка шлюза помогала отличить проблему локального подключения от сбоя на дальнейшем пути.
В одной из серий шлюз ответил на все 60 запросов. Два узла за туннелем за тот же контрольный период ответили только на 36 и 37 запросов из 60.
Потери были воспроизводимыми и затрагивали оба направления проверки за туннелем.
Сначала я проверил правила доступа
Когда часть пакетов не проходит, легко начать добавлять разрешающие правила. Но сначала мне нужно было понять, действительно ли существующие правила что-то блокируют.
Я сопоставил адреса источника и назначения, разрешённые направления и счётчики firewall. В контрольной серии счётчики соответствующих запрещающих правил не выросли.
Это не доказывало исправность всей сети. Но оснований расширять доступ ради устранения этих потерь у меня не было.
Итоговое исправление тоже не потребовало менять firewall, NAT или маршруты. Разрешённые направления остались прежними.
Нагрузка показала, куда смотреть дальше
Во время проблемного состояния загрузка MikroTik доходила до 100%. Профилирование показывало, что около 86% занимала обработка IPsec.
Одновременно менялось количество установленных защитных ассоциаций — SA. В журнале наблюдались повторные удаления и создание состояний туннеля.
Само изменение SA нормально: ключи и состояния не должны существовать бесконечно. Меня насторожило сочетание признаков: частые изменения состояния, высокая нагрузка и потери при передаче данных.
Я также проверял влияние аппаратного ускорения на стороне FortiGate. Эти наблюдения не дали оснований объявить причиной неисправность ускорителя. При окончательной проверке ускорение оставалось отключённым; выводы о его работе в другом режиме я не делаю.
Следующим шагом стало сравнение Phase 2 на обеих сторонах.
Что было не согласовано в Phase 2
Селекторы Phase 2 описывают трафик, который должен защищаться туннелем: в частности, пары локальных и удалённых сетей.
На одной стороне нужные направления были представлены отдельными политиками. На FortiGate использовалась общая настройка с группами адресов.
Для двух устройств разных производителей такая запись не обязательно означает одинаковое представление защищаемого трафика. Fortinet отдельно описывает применение раздельных селекторов для нескольких подсетей при соединении с устройствами других производителей.
Я заменил групповые селекторы на шесть явных пар, соответствующих существующим политикам MikroTik.
В обезличенном виде смысл изменения такой:
Было:
группа локальных сетей ↔ группа удалённых сетей
Стало:
локальная сеть А ↔ удалённая сеть Б
локальная сеть А ↔ удалённая сеть В
локальная сеть Г ↔ удалённая сеть Д
…Здесь важны не буквы и не количество строк, а одинаковое описание нужных направлений на обеих сторонах. Новые разрешения доступа я этим изменением не добавлял.
Как я проверил исправление
После применения настройки все шесть предусмотренных политик Phase 2 находились в состоянии established.
Затем я повторил проверку трафика. Сначала выполнил серии по 60 запросов к двум узлам за туннелем. Потом запустил к ним одновременно более длинные серии — по 120 запросов с интервалом полсекунды.
Результат получился таким:
| Проверка | Результат |
|---|---|
| Домашний шлюз | 60 из 60, без потерь |
| Первый узел за туннелем | 60 из 60, затем 120 из 120 |
| Второй узел за туннелем | 60 из 60, затем 120 из 120 |
За время этих проверок каждый удалённый узел ответил на все 180 запросов.
Перегрузка обработкой IPsec также исчезла. В одном из итоговых замеров общая загрузка процессора составляла 20% вместо прежних 100%.
Это был уже результат передачи данных, а не только изменение статуса в интерфейсе.
С каким результатом я закончил
После согласования Phase 2 воспроизводимые потери в контрольных сериях прекратились. Два удалённых узла прошли параллельную проверку без пропущенных ответов, а роутер перестал находиться в прежнем состоянии перегрузки.
При этом длительное наблюдение через полный интервал обновления ключей в эту проверку не входило. Я не выдаю несколько минут успешных измерений за подтверждение работы на протяжении суток.
Исходная проблема была воспроизводима до изменения и перестала воспроизводиться после него в повторных контрольных сериях. Именно на этом основании я считаю исправление подтверждённым.
Для меня главный вывод этой истории — смотреть дальше надписи «подключено». В таком случае полезнее сопоставить реальные потери, нагрузку устройства, изменения SA и селекторы Phase 2, чем сразу расширять правила доступа.