Размещение только одного URL в интернете

Вопрос или проблема

У нас есть приложение, доступное через веб, которое запускается через службы Windows. Я не могу понять, на чем оно действительно работает, но это не через IIS.

Оно распространяется внутри через наш внутренний DNS. Что великолепно.

У этого приложения есть два основных URL: один для консоли управления, а другой для пользовательской стороны.

Назовем их:

https://app.domain.com/manage

https://app.domain.com/app/user

Моя задача состоит в том, чтобы первый URL, app.domain.com/manage, был доступен только для внутренних пользователей (и желательно ограничен в рамках одной из наших VLAN, чтобы только определенные люди имели доступ).

Второй URL, app.domain.com/app/user, должен быть доступен как внутри, так и снаружи.

Все мои поиски в Google указывают на использование обратного прокси через IIS, но это не приложение IIS.

Все мои поиски в Google указывают на использование обратного прокси через IIS, но это не приложение IIS

Ну, весь смысл обратного прокси в том, что он перенаправляет входящие HTTP-запросы на другой HTTP-сервер — в любом случае не имело бы смысла, если бы прокси перенаправлял запросы к самому себе. Таким образом, независимo от того, хостится ли приложение IIS или нет, вы все равно можете разместить HTTP-прокси перед ним.

(Хотя я сам никогда не использовал IIS в качестве обратного прокси, но общий принцип применим в любом случае. Вероятно, для Windows доступны и другие обратные прокси, например, Apache2 — тоже вариант, хотя поддержание его актуальности на Windows было бы отдельной проблемой…)

Ответ или решение

Теория

Работа с веб-приложениями для организации внутреннего и внешнего доступа требует внимания к деталям конфигурации сети и безопасности данных. В рассматриваемой задаче имеются две URL-адреса приложения — один из которых должен быть доступен только для внутреннего использования на одном из VLAN-ов, а второй должен быть доступен как внутри, так и снаружи компании. В этой ситуации важно учитывать, что приложение не использует IIS для хостинга, и, следовательно, необходимо рассматривать альтернативные механизмы для решения данного вопроса доступа и фильтрации.

Это делает обратное проксирование наиболее подходящей технической стратегией, так как оно позволяет нам контролировать и маршрутизировать трафик к нужным частям приложения. Важно понять, что выбор между различными решениями для обратного проксирования зависит не только от операционной системы, но и от дополнительных организационных и технических требований, таких как поддержка последних обновлений безопасности и возможность интеграции с существующей инфраструктурой.

Пример

В качестве примера можно рассмотреть использование Nginx как обратного прокси-сервера. Nginx является популярным выбором для реализации подобных задач благодаря своей гибкости и широким возможностям конфигурации. Он может выступать в роли балансировщика нагрузки, выполнять HTTPS-терминацию и обеспечивать управляемый доступ к различным компонентам веб-приложений. Для случая, описанного в задаче, Nginx можно настроить так, чтобы он обрабатывал запросы к разным URL-адресам приложения по-разному.

Пример конфигурации может включать следующие пункты:

Настройка для внутреннего доступа: Разрешить доступ к https://app.domain.com/manage только из определенного диапазона IP-адресов, соответствующих внутреннему VLAN. Это можно настроить с помощью директивы allow и deny в конфигурации Nginx.
Настройка для общего доступа: Направить все запросы к https://app.domain.com/app/user напрямую на бекэнд сервер, независимо от их источника, чтобы обеспечить доступ для внутренних и внешних пользователей.

Помимо Nginx, также можно рассмотреть и другие решения, такие как HAProxy или Caddy, которые могут предложить дополнительные возможности по управлению трафиком и безопасностью.

Применение

Для реализации подобного решения, первым шагом будет установка и настройка выбранного прокси-сервера на подходящем оборудовании внутри вашей сети. Вот пример шагов, которые можно предпринять:

Установка Nginx: Вы можете установить Nginx на сервер под управлением Windows с использованием специализированных сборок или на виртуальной машине, работающей под управлением Linux. Убедитесь, что версия программного обеспечения актуальна и поддерживает все необходимые функции.
Конфигурация доступа: Создайте конфигурационный файл Nginx с необходимыми директивами server, location, allow, и deny. Директива location позволит вам определить разные правила обработки запросов для разных частей приложения.
SSL и Безопасность: Пропишите SSL-теминацию в Nginx, чтобы обеспечивать безопасность передачи данных. Настройте пересылку только проверенных соединений на бекэнд-сервис.
Тестирование настройок: Протестируйте конфигурацию в тестовом окружении, чтобы убедиться, что правила маршрутизации и ограничения работают ожидаемым образом.
Развертывание и мониторинг: Вынесите настройки в продакшн-среду и установите мониторинг для отслеживания производительности и безопасности системы.

В результате данной реализации, ваша компания получит возможность гибко управлять доступом к важным частям своего веб-приложения, обеспечивая безопасность и соответствие корпоративным стандартам работы сети. Это решение позволит контролировать доступность сервисов на различных уровнях и повысит общую защищенность информационной системы.