Несколько IP-адресов против реверсивного прокси / переписывания Apache
Мы небольшой бизнес и пытаемся выбрать лучшую архитектуру для наших внутренних блоков. У нас есть среда разработки, производства и постановки. Все они общедоступны (но, конечно, ограничены паролем).
Для довольно простой необходимости я действительно не вижу необходимости иметь несколько IP-адресов для каждого блока. Кажется, добавить ненужную сложность. Вместо этого я спорю о том, что на данном этапе лучше иметь один публичный IP-адрес с обратным прокси-сервером (например, Squid) или просто использовать переписывание в Apache для пересылки запросов на соответствующие серверы (в зависимости от имени домена).
о чем ты думаешь? Я неправильно понял, и множественные IP-адреса - путь, независимо от размера организации? Какой подход вы обычно выбираете?
3 ответа
Я бы предпочел лак или ха-прокси перед squid для обратного проксирования. Однако наличие отдельных IP-адресов дает гораздо большую гибкость - например, если вы хотите получить удаленный доступ к ящикам, используя разные протоколы, такие как ssh. Проксирование также влечет за собой еще один уровень, влияющий на производительность и усложняющий диагностику.
Мы используем apache для перезаписи / проксирования на внутренние веб-серверы, и это работает довольно хорошо. Однако будьте осторожны при настройке виртуальных хостов на сервере, поскольку первое правило, которое соответствует шаблону, является тем, которое выбрано. Порядок может иметь значение. Например, если у вас есть место по умолчанию или резервное место для пересылки (например, ваш основной сайт), оно должно быть последним.
Кроме того, SSL становится немного сложнее. Вам потребуется сертификат подстановки для *.yourdomain.com, а затем использовать сопоставление URL для каждого виртуального хоста для пересылки. Сертификаты с подстановочными знаками могут быть немного сложнее, но не так уж плохо.
Я не вижу ничего плохого в том, чтобы использовать Apache для прокси обратно на соответствующие внутренние серверы. Просто настройте DNS Windcard, чтобы вы могли иметь dev.foo.com, test.foo.com и т. Д., А затем настройте определения vhost с соответствующими правилами прокси-сервера для маршрутизации обратно к соответствующим полям. Тем не менее, вы можете использовать несколько инструментов для этого; Apache не единственное решение.
Что касается сертификатов, если вам не нужны действительные сертификаты dev/test, просто создайте собственный сертификат подстановочного знака.
Кроме того, Squid - хороший прокси-сервер FORWARD, но с другой стороны он довольно тяжелый / хреновый.