1. Поведение.
Отваливается VPN между Check Point Quantum Spark и MikroTik раз в сутки и не восстанавливается. Для того, чтобы восстановить VPN канал нужно провести перезагрузку MikroTik устройства. Получается, что канал работал, а теперь просто не работает. Причем ситуация повторяется
Отваливается VPN между Check Point Quantum Spark и MikroTik раз в сутки и не восстанавливается. Для того, чтобы восстановить VPN канал нужно провести перезагрузку MikroTik устройства. Получается, что канал работал, а теперь просто не работает. Причем ситуация повторяется
2. Причина проблемы.
Причина данной проблемы связана с неправильной настройки параметра Peer ID или его отсутствием на устройствах, где строится VPN канал. В данном примере это Check Point QuantumSpark и MikroTik.
Причина данной проблемы связана с неправильной настройки параметра Peer ID или его отсутствием на устройствах, где строится VPN канал. В данном примере это Check Point QuantumSpark и MikroTik.
Подробное описание причины:
Peer ID – это уникальный логический идентификатор пира. Идентификатором может быть доменное имя или IP адрес.
Peer ID используется для идентификации и аутентификации удаленного устройства, а также поиска правильного секретного ключа (PSK) для аутентификации.
Теоретически, несовпадение Peer ID должно приводить к немедленному обрыву на этапе Фазы 1, так как сторона не может пройти идентификацию удаленной стороны и найти правильный PSK для аутентификации. Однако на практике, VPN туннель может построится и без настроенного Peer ID.
Построение VPN туннеля без Peer ID. PSK на обоих концах туннеля при правильной настройки одинаковый, несмотря на неверный Peer ID. Демон IKE видит, что Peer ID в запросе не совпадает с ожидаемым, но он пробует использовать тот PSK, который был ассоциирован с ожидаемым Peer ID, и он подошел, потому что на удаленной стороне был установлен тот же самый ключ. И VPN туннель поднялся.
Peer ID – это уникальный логический идентификатор пира. Идентификатором может быть доменное имя или IP адрес.
Peer ID используется для идентификации и аутентификации удаленного устройства, а также поиска правильного секретного ключа (PSK) для аутентификации.
Теоретически, несовпадение Peer ID должно приводить к немедленному обрыву на этапе Фазы 1, так как сторона не может пройти идентификацию удаленной стороны и найти правильный PSK для аутентификации. Однако на практике, VPN туннель может построится и без настроенного Peer ID.
Построение VPN туннеля без Peer ID. PSK на обоих концах туннеля при правильной настройки одинаковый, несмотря на неверный Peer ID. Демон IKE видит, что Peer ID в запросе не совпадает с ожидаемым, но он пробует использовать тот PSK, который был ассоциирован с ожидаемым Peer ID, и он подошел, потому что на удаленной стороне был установлен тот же самый ключ. И VPN туннель поднялся.
Почему же туннель падал раз в сутки?
В IPsec туннель живет в рамках сессии (Security Association, SA). У каждой SA есть время жизни (Lifetime).
Первая фаза (IKE_SA) обычно имеет большое время жизни (часы или сутки).
Вторая фаза (IPsec_SA) обновляется чаще.
Когда истекает время жизни Фазы 1, необходимо заново пройти весь процесс IKE с аутентификацией. И при повторном согласовании ключей, система пыталась строго проверить все параметры, включая Peer ID. Если Peer ID неверный, то VPN туннель не строился.
В IPsec туннель живет в рамках сессии (Security Association, SA). У каждой SA есть время жизни (Lifetime).
Первая фаза (IKE_SA) обычно имеет большое время жизни (часы или сутки).
Вторая фаза (IPsec_SA) обновляется чаще.
Когда истекает время жизни Фазы 1, необходимо заново пройти весь процесс IKE с аутентификацией. И при повторном согласовании ключей, система пыталась строго проверить все параметры, включая Peer ID. Если Peer ID неверный, то VPN туннель не строился.
3. Устранение проблемы.
Необходимо на обеих шлюзах, где строится VPN – настроить Peer ID.
Необходимо на обеих шлюзах, где строится VPN – настроить Peer ID.