Мы запускаем несколько веб-приложений, некоторые только внутренние, некоторые внутренние / внешние. Я составляю предложение о том, чтобы мы использовали обратные прокси-серверы для изоляции исходных серверов, обеспечения завершения SSL и (когда это возможно) обеспечения балансировки нагрузки. Я уверен, что для большей части нашей установки она будет работать нормально, но у нас есть несколько менее известных проприетарных приложений, которые могут нуждаться в особом обращении, когда мы будем двигаться вперед с обратным проксированием.
Какие типы ловушек обычно вызывают проблемы при перемещении исходного сервера с переднего края на прокси-сервер? (Например, я могу представить себе проблемы, если приложению необходимо знать IP-адрес входящих запросов.)
Наиболее частой ошибкой являются перенаправления, сгенерированные в приложении, которые вам придется переписать в обратном прокси, проблема с IP-адресом клиента, о которой вы уже говорили, при использовании завершения ssl, возможно, сервер хочет проверить сертификат клиента или получить от него информацию о пользователе. Для правильного кэширования обратного прокси на стороне края могут потребоваться модификации приложения (правильные заголовки с истекающим сроком действия, отключенные ненужные файлы cookie и т. Д.). Если вы используете встроенную аутентификацию Windows, это может быть недостижимым или настоящим кошмаром
Тогда у вас могут возникнуть проблемы с настройкой, но я думаю, что их будет намного легче решить. Мой предпочтительный набор инструментов для этой задачи:
Проблемы, которые могут возникнуть с приложениями за обратным прокси:
nginx и varnish вы можете добавить X-Forwarded-for заголовок с исходным IP-адресом и заставит приложение его распознать.Я сейчас использую nginx на фронтенде и лак за ним, чтобы выполнять прокси и балансировку нагрузки / проверку бэкэнда. В качестве единой точки отказа очень важно использовать кластерное решение на обратном прокси-сервере / балансировщике нагрузки.
я использую corosync / кардиостимулятор (Linux HA, самая последняя версия) для балансировки нагрузки балансировщиков нагрузки: три балансировщика нагрузки, каждый с внешним IP-адресом, балансировка RR с использованием DNS (одно имя указывает на три IP-адреса). Если одна из машин не работает, назначенный ей IP-адрес перемещается с помощью corosync на одну из двух других оставшихся машин. Также, если я добавлю больше машин / IP-адресов, они автоматически сбалансируются, и если все машины, кроме одной, не работают, все IP-адреса будут на том, который активен. Вы можете использовать corosync для настройки активно-активного, активно-пассивного и многих других конфигураций кластера.
Распространенный (и дешевый) способ сделать это - использовать squid в качестве обратного прокси ... вам следует взглянуть на их FAQ, где они обсуждают общие проблемы .. Squid revers Proxy FAQ
Вы также можете столкнуться с проблемами с внутренними перенаправлениями: прокси заставит приложение «думать», что оно находится в одном URL-адресе, который, очевидно, отличается от реального (внешнего) URL-адреса.
В Linux / BSD и некоторых других операционных системах прокси-сервер вполне может маскироваться под IP-адрес клиента, чтобы вы не теряли видимость (при этом используются сетевые функции ОС - iptables / ipfw, а не прокси).
Если вы используете проверку подлинности сертификата клиента в одном из приложений, вам будет сложно переместить точку завершения SSL и обеспечить безопасность.
Балансировка нагрузки может быть сложной задачей - для http-приложений вам нужно либо реплицировать состояние в реальном времени по кластеру, либо использовать `` липкие сеансы '', что скорее подрывает принцип отказоустойчивости (гибридный подход с использованием ограниченной репликации / отработки отказа определенного сеанса обычно наиболее практичное решение).