Назад | Перейти на главную страницу

Сохранение сеанса SSL - сердцебиение HA

У меня есть два сервера, назовем их Майло и Отис. Теперь Майло и Отис настроены как активно-пассивная пара высокодоступных серверов, где Майло обычно является главным, а Отис находится в режиме ожидания, ожидая маловероятного отказа Майло, когда Отис возьмет на себя общий виртуальный IP-адрес. У меня вопрос, что происходит с SSL-соединением во время сбоя.

Учтите следующее:

  1. Какой-то клиент (я) устанавливает SSL-соединение с Milo.
  2. SSL-соединение настроено на то, чтобы оставаться активным, поэтому допустим, что веб-страница запрашивается через SSL-соединение. Страница загружена полностью, и соединение открыто, готово для другого запроса (скажем, актива, такого как файл css).
  3. Перед запуском запроса файла css Майло испытывает катастрофический сбой, и теперь Отис взял на себя ответственность.
  4. Что происходит теперь, когда я хочу сделать запрос файла css? Я все еще думаю, что у меня открытое соединение с Майло, но виртуальный IP теперь указывает на Отис.

Подхватывает ли Отис сеансы SSL, которые были у Майло, автоматически? Мой браузер начинает взаимодействовать с Отисом, и Отис говорит: «Эй, мы, наверное, сначала должны пожать руку»? Приветствуются любые комментарии / ответы по этому поводу.

Когда происходит аварийное переключение, текущие активные соединения разрываются. Однако это произойдет на уровне TCP, поэтому SSL / TLS даже не войдет в сцену. TCP-соединение требует, чтобы обе конечные точки знали о соединении и имели правильную информацию (порядковые номера, размеры окон и т. Д.), И поэтому, когда IP-адрес выходит из строя, резервная машина не будет знать TCP-соединения, которые установил мастер. . Когда резервная машина получает пакеты, которые являются частью предыдущих TCP-соединений, она ответит пакетом RST, который заставит клиента закрыть соединение.

Даже если TCP-соединения были восстановлены, аналогичная ситуация возникла бы с SSL / TLS. Каждый сеанс требует состояния на каждом конце, включая сеансовый ключ (который на самом деле защищает данные приложения). На резервной машине не будет этого состояния сеанса, поэтому существующие сеансы будут прерваны.