Обзор
В настоящее время я развертываю пару устройств брандмауэра высокой доступности, которые будут действовать как прозрачный прокси-сервер (трафик будет направляться через прокси-сервер через маршрутизацию, а не настраивать URL-адрес прокси на клиентских машинах) для исходящего трафика. У меня есть конфигурация высокой доступности, и я вижу, что состояние сеанса совместно используется обоими устройствами. Когда запускается аварийное переключение, пассивное устройство принимает IP-адреса (фактически, весь сетевой адаптер перемещается, как это находится на AWS) ранее активного экземпляра.
Схема подключения
Клиент - -> брандмауэр / прокси - -> веб-сервер
Проблема
В качестве теста я установил веб-сервер и создал большой html-файл. Затем я использовал клиентскую машину для получения этого файла с помощью wget и curl (через свои прокси), и во время загрузки файла я выполнил ручное переключение. Когда я выполнил аварийное переключение, загрузка wget (то же самое произошло с curl) застряла. Затем я добавил тайм-ауты подключения и время ожидания команды wget истекло, а затем перезапустил загрузку, которая работала нормально, хотя я мог видеть, что был создан новый сеанс. Следует отметить, что это облачная установка, в которой время переключения при отказе намного медленнее, чем на локальных устройствах с высокими техническими характеристиками, поэтому для завершения переключения может потребоваться от 15 до 60 секунд. Я пытаюсь гарантировать, что мое развертывание не сильно повлияет на приложения, которые в основном будут отправлять HTTP-трафик.
Вопросы
Разумно ли ожидать продолжения загрузки по протоколу HTTP после отработки отказа, если состояние сеанса синхронизируется между устройствами высокой доступности или клиенту следует использовать тайм-ауты и повторять попытки для повторного запуска загрузки?
Возможно, мне потребуется, чтобы группы приложений изменили настройки тайм-аута и повторных попыток? Что считается нормальным для настроек тайм-аута и повтора для приложений, которые регулярно отправляют запросы API? Я надеюсь, что командам разработчиков приложений не придется что-либо менять на своей стороне после того, как я разверну это.
Есть ли способ предотвратить зависание wget или curl во время загрузки, когда соединение временно прерывается на срок до минуты и автоматически продолжается после восстановления соединения на устройстве, которое приняло на себя активную роль? Я знаю, что вы можете прервать запрос и продолжить загрузку с того места, где оно было остановлено, но это не то, что группы приложений будут делать.
Я в основном заменяю шлюзы NAT на AWS парой брандмауэров Nextgen высокой доступности с возможностями синхронизации сеансов и проверки, и я не хочу, чтобы это приводило к каким-либо операционным проблемам.
Основываясь на вашем описании, «прозрачный прокси» - это настоящий прокси, который завершает TCP-соединения и даже завершает SSL в вашем случае. Это означает, что между клиентом и прокси и между прокси и сервером будет TCP-соединение, независимо от того, какой фактический адрес назначения используется клиентом (прозрачный прокси).
Из-за этого для каждого инициированного клиентом TCP-соединения будет два TCP-соединения (клиент-прокси и прокси-сервер), которые имеют свое собственное состояние, которое хранится в ядре ОС брандмауэра. Кроме того, существует некоторое состояние уровня приложения для HTTP, а также для части TLS - оба хранятся в прокси-приложении, то есть в пользовательском пространстве.
Разумно ли ожидать продолжения загрузки по протоколу HTTP после аварийного переключения или клиенту следует использовать тайм-ауты и повторять попытки начать загрузку снова?
Даже если вам удастся синхронизировать состояния TCP-соединений между брандмауэрами (что, я сомневаюсь, возможно, поскольку они завершаются на брандмауэре), вы не сможете синхронизировать состояние приложения (то есть HTTP и TLS). Это означает, что существующее соединение не может быть продолжено на другом брандмауэре. Таким образом, клиенту необходимо повторить запрос.
Возможно, мне потребуется, чтобы группы приложений изменили настройки тайм-аута и повторных попыток? Что считается нормальным для настроек тайм-аута и повтора для приложений, которые регулярно отправляют запросы API?
Зависит от варианта использования, приложения и от того, как часто проблема будет возникать на практике (т.е. как часто брандмауэр выходит из строя). Обратите внимание, что невозможно повторить все запросы, т.е. следует повторить только идемпотентные запросы (которые не изменяют состояние на сервере). Обычно это означает GET, но не POST, хотя не все веб-приложения ведут себя так.
Действительно ли совместное использование сеанса TCP через прокси-устройства подходит только для чистых TCP-соединений (соединения с базой данных и т. Д.), И есть ли реальное использование совместного использования сеанса для HTTP-соединений?
Как я уже сказал, совместного использования TCP-соединения недостаточно для HTTP и тем более для TLS. Совместного использования состояния HTTP недостаточно, если задействован HTTPS. Я знаю только теоретические работы о том, как разделять состояние HTTP и TLS между системами межсетевого экрана в кластере высокой доступности, и о каких-либо практических реализациях - это было бы довольно сложно, с большими накладными расходами, даже если не происходит переключения при отказе, и, вероятно, не стоит того.