Публикация разных сайтов с использованием одного IP и pfSense - Squid
Я довольно новичок в pfSense, так что терпите меня, пожалуйста.
Подводя итог, я имею:
- Сеть с включенным разделенным DNS.
- Один веб-сервер IIS с одним IP-адресом, разные сайты, работающие с использованием разных привязок заголовка узла через порт 80, все сайты работают нормально для внутренних пользователей.
- pfSense 2.3.4-RELEASE-p1 с установленным Squid 0.4.40 на границе сети.
- То, что у меня выглядит, выглядит на картинке ниже:
Чего я пытаюсь добиться:
- Опубликуйте внутренние сайты для внешних пользователей, используя те же внутренние URL-адреса.
- Прозрачный прокси (для внутреннего кеширования и CalmAV) и HTTPS не нужны.
Я прочитал, что pfSense может сделать этот трюк с использованием обратного прокси-сервера, я выполнил шаги, упомянутые здесь, чтобы включить его (за исключением использования того же порта 80 для внутренних сайтов): https://www.reddit.com/r/homelab/comments/2vyiiy/til_reverse_proxy_via_squid_in_pfsense/
Проблема:
- Когда внешние пользователи вводят URL-адрес сайта и нажимают клавишу ввода, браузер начинает пытаться подключиться, но через несколько секунд происходит сбой без загрузки страницы, что даже странно, что введенный ими URL-адрес перенаправляется с HTTP на HTTPS.
Поиск проблемы:
- Отключен Прозрачный HTTP Прокси для внутренней связи.
- Логи Squid не показывают ничего, связанного с перенаправлением URL.
- Журналы брандмауэра pfSense показывают, что внешние пользователи могут подключиться один раз по протоколу HTTP, а затем весь трафик передается по протоколу HTTPS.
Вопросы:
- Является ли этот сценарий действительным даже для pfSense/Squid?
- Если да, то чего мне не хватает? если нет, какова альтернатива?
- Нужно ли публиковать сайты с использованием разных портов в IIS и включать перенаправление портов в Pfsense? (это то, чего я пытаюсь избежать)
Любые дополнительные шаги или советы по устранению неисправностей очень приветствуются.
1 ответ
Решено:
Мне пришлось провести немного интимного времени с руководством по squid, настоятельно рекомендуется по-настоящему понять, как оно работает: http://www.visolve.com/squid/whitepapers/reverseproxy.php
Прочитав руководство, я решил начать с нуля и выполнить полную переустановку pfSense, так как начал понимать, что что-то не так с сервисами Squid, они ничего не отображали в логах.
Советы и рекомендации, которые применимы к моему сценарию:
- Убедитесь, что разделение DNS выполнено правильно.
- Убедитесь, что pfSense сначала использует ваш внутренний DNS. ИЛИ что у вас есть статические записи DNS на pfSense для локальных сайтов. (файлы хостов или статическая запись пересылки DNS)
- Даже если вы не можете использовать его, вам необходимо настроить и включить прямой прокси-сервер, хотя нет необходимости включать прозрачный режим.
- Прямой прокси должен быть включен ПЕРВЫЙ, если вы включите обратный прокси без настройки пересылки, все будет плохо.
- Вам НЕ нужно сообщать pfSense о заголовках узлов, используемых при развертывании, если вы используете раздельный DNS, фактически добавление заголовков узлов приводило к отключению службы squid в моем сценарии.
Поскольку мне потребовалось некоторое время, чтобы понять это, я подумал, что лучше отвечу / заархивирую свои выводы, чтобы я мог помочь другим, которые застряли, как я,
Пошаговое руководство:
Шаг 1. Включите Forward Proxy, перейдя в раздел Сервисы => Squid Proxy Server => Общие.
- Eanble Squid Proxy: Проверить
- Прокси-интерфейс: LAN
- Порт прокси: 3128
- Разрешить пользователям интерфейс: проверено
- Транспортный HTTP-прокси: НЕ проверен
- SSL Man в середине фильтрации: НЕ проверено
Шаг 2. Включите обратный прокси-сервер, выбрав Сервисы => Обратный прокси-сервер Squid => Общие
- Интерфейс обратного прокси: WAN
- Внешнее полное доменное имя: из моего примера это должно быть xyd.com, просто верхнее доменное имя, ввод чего-либо еще вызвал ошибку, люди говорят, что хотя это поле позволяет вам ввести только одно доменное имя, оно не помешает вам проксировать разные доменные имена тоже, пока одно из них совпадает, но я не могу подтвердить, хотя.
- Сброс TCP-подключений по неавторизованным запросам: проверено
- Включить HTTP обратный прокси: проверено
- Обратный порт HTTP: 80
Сделайте все вышеперечисленное и сохраните, прежде чем продолжить, убедитесь, что служба squid запущена и работает, перейдя по адресу: Status => Services => Squid Services Status Зеленый, если это не так, перепроверьте свою работу, пока она не будет.
Теперь пришло время определить сопоставления между внешним DNS и внутренним DNS.
Шаг 3: Определите внутренние веб-серверы, выбрав Сервисы => Обратный прокси-сервер Squid => Веб-серверы
- Добавьте каждый внутренний веб-сервер (не веб-сайт или URL), нажав " Добавить".
- Включить этот узел: проверено
- Peer Alias: имя внутреннего веб-сервера, просто имя для удобной ссылки. из моего примера: Web/IIS
- Одноранговый IP: фактический внутренний IP, разрешенный DNS, из моего примера: 10.0.0.2
- Peer Port: порт, который использует внутренний сайт, из моего примера: 80
- Протокол одноранговой сети: HTTP
Когда вы закончите с этим, pfSense теперь знает, что существует внутренний веб-сервер с настройками, которые вы только что применили, теперь вам нужно сообщить ему, что имеет этот веб-сервер, определив сопоставления.
Шаг 4. Определите внутренние URL-адреса, перейдя в раздел Сервисы => Обратный прокси-сервер Squid => Сопоставления
- Включить этот URI: проверено
- Имя группы: любое имя, которое позволяет вам быстро идентифицировать URL-адреса или заголовки узлов, используемые в этой группе. Я использовал что-то вроде "Группа перенаправления групп Web/IIS".EDIT: запись длинных имен приводила к сбою службы squid, только короткие имена без пробелов
- Пиры: Вы должны выбрать серверы, которые могут отвечать на URL-адреса, указанные в этой группе, из моего примера: веб-сервер, определенный на предыдущем шаге: Web/IIS
- Настройки URI: вы должны записать в заголовки хоста, доменные имена или URL, которые вы хотите, чтобы pfSense совпадал в этой группе. Вот большое примечание: пишите ТОЛЬКО, если у вас включен прозрачный режим ENABLED, в моем примере прозрачный режим был выключен и поэтому мне не нужно было писать заголовки хоста, доменные имена или URL-адреса.
Убедившись, что сервис Squid по-прежнему работает, я выполнил тест со стороны внешнего пользователя и произвел та-да! это сработало:)