1. 1 История tcpIP
 Скачать 340.83 Kb.
|
3.3.5 Определение жизнеспособности IPSec-соединенияЗачастую бывает необходимо как можно скорее определить, что соединение с противоположной стороной потеряно. IKE не предоставляет способа выполнить это, кроме как ждать до тех пор, пока не истечет период обновления ключей (lifetime). В большинстве случаев это неприемлемо, поэтому необходим способ проверки состояния противоположной стороны. В этом случае обычно используют механизмы Keepalive или Heartbeat. В схеме Keepalive каждой стороне требуется регулярное подтверждение жизнеспособности противоположной стороны. Обмен сообщениями происходит с использованием аутентифицированной нагрузки Notify. Оба участника согласовывают на фазе I интервал, в течение которого посылаются сообщения, например, 10 секунд. Каждое сообщение HELLO служит доказательством жизнеспособности противоположной стороны. В свою очередь каждая из сторон должна подтвердить сообщение HELLO. Если по истечении 10 секунд какая-либо из сторон не получила HELLO, она сама посылает сообщение HELLO, ожидая ACK от противоположной стороны в качестве доказательства жизнеспособности. При получении как HELLO, так и ACK таймер перезапускается. Схема Heartbeat основана на отправке однонаправленных (без подтверждения) сообщений. Сторона, которая заинтересована в жизнеспособности противоположной стороны, должна полагаться на то, что противоположная сторона сама периодически будет посылать сообщения HELLO, демонстрируя свою жизнеспособность. Протокол Dead Peer Detection (DPD) описан в RFC 3706. Он позволяет ликвидировать недостатки схем Keepalive и Heartbeat введением определенной логики управления обменом сообщений. В частности, Keepalive и Heartbeat должны обязательно обмениваться HELLO через определенные интервалы времени. При использовании DPD каждая из сторон в меньшей степени зависит от другой. Любая сторона может запрашивать доказательство жизнеспособности в тот момент, когда ей это необходимо, а не через фиксированный интервал времени. Такая асинхронность DPD-обменов позволяет посылать разное количество сообщений, чем достигается большая масштабируемость. Рассмотрим взаимодействие двух DPD-узлов А и В. Если между ними существует IPSec-трафик, то нет необходимости в регулярном доказательстве жизнеспособности. С другой стороны, если существует период простоя, в течение которого между ними нет обмена пакетами, то жизнеспособность каждого узла может вызывать сомнения. Однако знание о жизнеспособности противоположной стороны необходимо только в том случае, если должен быть передан трафик. Например, если узел А должен послать IPSec-пакеты после определенного периода простоя, он должен быть уверен в жизнеспособности В. В этот момент узел А может инициировать DPD-обмен. DPD-обмен представляет собой двунаправленный обмен сообщениями HELLO/ACK. Сторона, заинтересованная в получении сведений о жизнеспособности противоположной стороны, отправляет запрос R-U-THERE, соответствующий HELLO. Противоположная сторона должна отправить сообщение R-U-THERE-ACK, соответствующее ACK. Получение этого сообщения служит доказательством жизнеспособности. Следует отметить, что решение о том, когда необходимо инициировать DPD-обмен, во многом зависит от реализации. Возможна реализация, когда DPD-сообщения посылаются через определенные интервалы после периода простоя. Каждая сторона может иметь разные требования к определению жизнеспособности. Узлу А, например, может требоваться высокая отказоустойчивость, в то время как требования к ресурсам не столь жесткие. При использовании DPD каждая сторона может определить свою собственную «метрику волнения» — интервал, который определяет необходимость DPD-обмена. Этот интервал настраивается администратором на устройстве. Допустим, что на узле А настроили DPD-интервал, равный 10 секундам. Когда узел А посылает исходящий IPSec-трафик, но в течение 10 секунд происходит сбой при получении входящего трафика, он может инициировать DPD-обмен. С другой стороны, на узле В настроили DPD-интервал, равный 5 минутам. Если IPSec-сессия простаивает в течение 5 минут, то узел В может инициировать DPD-обмен, если в следующий момент он собирается послать IPSec-пакет к А. Реализация допускает повторную отправку запроса R-U-THERE, если не получен ответ R-U-THERE-ACK. Администратор может настроить на устройстве количество повторно отправляемых запросов. Если противоположная сторона не отвечает на указанное количество запросов, она считается нежизнеспособной, соединение обрывается, IKE SA и IPSec SA удаляются. |