Предоставление доступа к услугам общественности через VPN-шлюз

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

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

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

Поэтому моя первая идея заключалась в том, чтобы арендовать недорогой облачный VPS, направить туда наш домен и настроить наложение сети, чтобы передавать трафик из интернета во внутреннюю сеть. Однако я не уверен, что это лучший подход, и считаю это немного расточительным, поскольку меня интересуют только пропускная способность и публичный IP, а не CPU/RAM. Вот схема моего плана, если я недостаточно ясно объяснил:

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

Чтобы дать вам некоторое представление, это не совсем корпоративный проект, это ближе к домашнему проекту, и количество предоставляемых нами услуг может увеличиваться или уменьшаться в будущем. Мы стараемся снизить текущие затраты, поэтому я и подумал о аренде недорогого VPS вместо размещения нашей инфраструктуры в облаке.

Это хороший способ подойти к этой проблеме? Есть ли какие-то альтернативы?

Это способ выполнить ваши задачи, учитывая ваши ограничения и требования. Я так понимаю, что вы бы направляли весь трафик, попадающий на VPS, к одному обратному прокси на вашей локальной инфраструктуре. Весь трафик будет проходить через HTTP/HTTPS? (предполагается, что да, учитывая подход с обратным прокси). В этом случае вам нужно будет настроить NAT на VPS, чтобы весь трафик, поступающий на порты 80 и 443 TCP, перенаправлялся на частный IP-адрес обратного прокси в вашей локальной инфраструктуре. Вы можете легко сделать это с помощью Linux VPS и IPTables для NAT.

Обратите внимание, это не очень масштабируемый подход, так как вы добавляете две единичные точки отказа (дешевый VPS, обратный прокси) для всех ваших служб, и оба будут узкими местами. Учитывайте это в зависимости от ваших потребностей в будущем масштабировании по сравнению с быстрым запуском этой услуги.

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

Теория

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

Однако, не стоит забывать, что такой подход, как аренда VPS и настройка NAT (Network Address Translation) через правила IPTables, может создавать узкие места и точки отказа в системе, как из-за самого VPS так и из-за последующего реверс-прокси на вашей стороне.

Пример

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

Аренда VPS. Это будет ваш основной шлюз в интернет. На нем же будет осуществляться первичная маршрутизация входящего HTTP/HTTPS трафика.
Настройка NAT на VPS. Используя IPTables, вы настроите переадресацию входящего трафика HTTP (порт 80) и HTTPS (порт 443) на внутренний адрес реверс-прокси, который расположен в вашей сети. Это обеспечит базовую маршрутизацию трафика для всех доменов и поддоменов на один единственный интерфейс входа в ваши сервисы.
Установка реверс-прокси. Это решение позволит вам направлять трафик на соответствующие серверы внутри вашей инфраструктуры в зависимости от запрашиваемого домена или пути. В качестве реверс-прокси можно использовать такие решения, как Nginx или Apache, которые предоставляют гибкие возможности для распределения и фильтрации трафика.

Применение

Теперь давайте рассмотрим, как это можно применить в вашей ситуации:

Выбор и настройка VPS. Вам нужно выбрать VPS облачного провайдера, который обеспечит минимально необходимую производительность, так как как вы упомянули, вашей целью является использование только пропускной способности и публичного IP. Убедитесь, что выбранная конфигурация способна обрабатывать ожидаемое количество запросов, иначе возникнет узкое место.
Сетевые настройки. Настройте на VPS IPTables или другое средство для настройки NAT, чтобы обеспечить переадресацию пакетов на ваш внутренний реверс-прокси. Например, следующим образом:
```
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination <внутренний_IP_прокси>:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination <внутренний_IP_прокси>:443
```
Настройка реверс-прокси. Разверните реверс-прокси, который может обрабатывать запросы ко всем вашим сервисам и распределять их в зависимости от доменного имени или других критериев маршрутизации. Например, можно использовать Nginx с следующим конфигурационным файлом:
```
server {
   listen 80;
   server_name example.com;

   location / {
       proxy_pass http://<внутренний IP сервиса>;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}
```
Безопасность. Включите в конфигурацию SSL/TLS шифрование на вашем реверс-прокси, чтобы обеспечить безопасность данных при передаче. Для этого вам понадобится сертификат, который можно получить у сертификационного центра (например, Let’s Encrypt).
Мониторинг и Отказоустойчивость. Убедитесь, что у вас есть мониторинг состояния и производительности как VPS, так и реверс-прокси. Это поможет вовремя реагировать на потенциальные проблемы и минимизировать время простоя.

Если ваши нужды будут расти, возможно, стоит рассмотреть более масштабируемые решения, такие как использование облачных сервисов развертывания приложений или распределенные системы доставки контента (CDN), которые смогут эффективно распределять нагрузку и уменьшать задержки.

Подводя итог, этот подход дает вам необходимую гибкость и контроль для развертывания услуг, но его недостатки в виде точек отказа и потенциальных узких мест нужно иметь в виду, чтобы предотвратить негативное влияние на оказываемые вами услуги.