Всем привет ?

Врываюсь на Хабр с двух ног со своей первой статьей.

Всё чаще меня посещала мысль: а где на самом деле лежат наши фотографии, документы и личные переписки? Кто имеет к ним доступ и на каких условиях, точно ли все мои данные конфиденциальны? Любознательность и стремление к независимости хранения данных привела меня к идее своего облака, не где-то в далеком ЦОД, а здесь, дома, в гостиной, тихо жужжа в корпусе размером с книгу. Но есть один критически важный нюанс, который отделяет любительскую поделку от полноценной замены коммерческим сервисам — безопасный доступ извне. Зачем нам HTTPS, если для внутренней сети хватило бы и простого HTTP? Ответ выходит далеко за рамки банального «это нужно для шифрования и безопасности».

Raspberry Pi 5 в сборе
Raspberry Pi 5 в сборе

Нашим полигоном станет Raspberry Pi 5 в компактном корпусе Argon NEO 5 с быстрым M.2 накопителем, на котором будет развернута UmbrelOS. Но для старта нам потребуется не только «железо». Нам нужен собственный зарегистрированный домен. Он станет тем самым постоянным адресом, по которому вы будете находить свой сервер из любой точки мира, не завися от капризов провайдера и сложных запоминаний IP-адресов. При планировании работы домашнего сервера, который должен функционировать непрерывно, вопрос стабильного электропитания выходит в приоритете. Внезапное отключение электричества — это не просто несколько минут простоя, это прямой путь к data corruption, поэтому так же рекомендую использовать ИБП.

Смена DNS серверов домена на Cloudflare

Почему Cloudflare?

  • Во-первых, это бесплатно. Для большинства функций, необходимых домашнему серверу, не требуется платная подписка.

  • Во-вторых, безопасность «из коробки». Cloudflare предоставляет защиту от ботов, эксплойтов, DDoS, частых запросов API, Web Application Firewall.

  • В-третьих, простая работа с SSL. Cloudflare полностью интегрирован с протоколом ACME, который используют центры сертификации вроде Let's Encrypt.

Обратная сторона медали: что стоит учитывать:

  • Наиболее актуальный для пользователей в России минус — это ограничение трафика

  • Возможна задержка доступа к сайту, со стороны прокси, так как теперь весь трафик проходит через серверы Cloudflare

  • Конфиденциальность со стороны Cloudflare. Используя Cloudflare, вы по умолчанию доверяете ему весь свой трафик

Итак приступим к первому этапу. Заходим и регистрируемся на Cloudflare. Добавляем домен, и Cloudflare сам нам выдаст адреса двух DNS-серверов. Далее их необходимо ввести на панели управления регистратора домена. Cloudflare автоматически просканирует существующие DNS-записи у вашего текущего хостера и предложит перенести их. Перенос не мгновенный и может занять до 24 часов.

После успешной миграции рекомендую сразу создать A-записи для субдоменов. Мы будем разворачивать не только саму операционную систему UmbrelOS, но и приложения внутри нее, такие как Nextcloud. Best practice — выделить для каждого сервиса свой субдомен, даже с запасом. Все неактивные субдомены можем выделить в "404 Hosts" и при надобности использовать.


Кто такой этот ваш реверс прокси

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

Nginx Proxy Manager в UmbrelOS App Store
Nginx Proxy Manager в UmbrelOS App Store

RP

Плюсы

Минусы

Nginx Proxy Manager

Встроенная поддержка Let's Encrypt

Более высокое потребление ресурсов

Широкие возможности кастомизации

Избыточность для простых сценариев

Основа основ

Отсутствие мониторинга

Много документации

Zoraxy

Минималистичный и легковесный

Ограниченные возможности SSL

Простота настройки

Меньше документации

Наличие мониторинга

OpenResty Manager

Гибкость конфигурации

Меньше готовых решений "из коробки"

Расширенные возможности

Меньше документации

Наличие мониторинга

Мой выбор - Nginx Proxy Manager во многом благодаря привычке и отлаженности процесса. Однако при его использовании в UmbrelOS есть важный нюанс, про который не могу не сказать. В целях безопасности и избежания конфликтов, NPM внутри UmbrelOS использует нестандартные порты:

  • HTTP → порт 40080

  • HTTPs → порт 40443

Чтобы весь входящий интернет-трафик перенаправлялся в нашу домашнюю сеть на правильные порты Nginx Proxy Manager, нужно настроить на роутере (в нашем случае MikroTik) правила dst-nat.

Не забываем про masquerade. Правило masquerade необходимо для того, чтобы пакеты, возвращающиеся из вашей локальной сети обратно в интернет, помнили свой исходный путь. Без этого правило dst-nat может не работать корректно, так как ответные пакеты от сервера пойдут напрямую клиенту в обход роутера, и соединение не установится.


По горам с NPM и SSL

Теперь, когда инфраструктура готова, пришло время создать первый прокси-хост в Nginx Proxy Manager. Это мост между нашим доменом и локальным сервисом.

Открываем веб-интерфейс Nginx Proxy Manager и переходим в раздел "Proxy Hosts". Нажимаем кнопку добавления нового хоста. В поле "Domain Names" вводим полный адрес, который мы зарезервировали ранее для доступа к самой UmbrelOS. Убеждаемся, что в настройках "Scheme" выбрано http, так как внутри нашей локальной сети нет HTTPS. Поле "Forward Hostname / IP" должно содержать локальный IP-адрес вашего сервера Umbrel в сети. В поле "Forward Port" указываем стандартный порт 80, на котором работает веб-интерфейс UmbrelOS.

После сохранения конфигурации можно проверить ее работоспособность. Попробуйте перейти в браузере по доменному адресу. На этом этапе вы, скорее всего, увидите ошибку "521 — Host error". Эта ошибка означает, что доменное имя корректно резолвится и запрос доходит до вашего сервера, но сам веб-сервис пока недоступен извне. Причина в том не настроили корректную работу с SSL-сертификатами.

Во вкладке SSL для созданного прокси-хоста выбираем опцию «Запросить новый SSL-сертификат». Откроется форма с несколькими важными параметрами, которые необходимо настроить. Активируем чекбокс «Force SSL» — это гарантирует, что все HTTP-соединения будут автоматически перенаправляться на защищенный HTTPS-протокол. Указываем действующий email адрес для уведомлений от Let's Encrypt и принимаем условия обслуживания. Ключевым моментом является использование "DNS Challenge" — метода проверки, при котором не требуется прямой доступ к серверу из интернета. Этот способ идеально подходит для наших условий, так как позволяет провайдеру сертификатов убедиться в нашем контроле над доменом через DNS-записи. Выбираем провайдера Cloudflare из выпадающего списка. Теперь нам потребуется создать API-токен для авторизации. Переходим в личный кабинет Cloudflare:

  • Открываем раздел управления аккаунтом "Manage Account"

  • Переходим в подраздел "API Tokens"

  • Создаем новый токен, используя шаблон "Edit zone DNS"

  • На этапе настройки прав доступа обязательно указываем наш домен в параметре "Zone Resources"

  • Копируем полученный токен и вставляем его в поле "Credentials File Content", вместо шаблона ключа 0123456789abcdef0123456789abcdef01234567

Проверяем доступность домена UmbrelOS по HTTPs


А что там с Nextcloud?

После успешного получения SSL-сертификата и проверки доступности Nextcloud по HTTPS, необходимо выполнить финальную корректировку в самой конфигурации Nextcloud. Без этого шага могут возникать проблемы с генерацией корректных URL и предупреждения о небезопасном соединении.

Необходимо изменить config.php. Файл конфигурации Nextcloud обычно находится в директории данных приложения. В UmbrelOS путь может выглядеть так:

*/umbrel/app-data/nextcloud/data/config.php

Нужно найти и отредактировать два критически важных параметра:

<?php
$CONFIG = array (
  ...
  // Добавляем домен в доверенные
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'nextcloud.your-domain.com', // Ваш субдомен для Nextcloud
  ),
  ...
  // Принудительное использование HTTPS
  'overwriteprotocol' => 'https',
  ...
);

Nextcloud будет отклонять запросы с доменов, не указанных в этом списке. Без добавления вашего субдомена вы можете столкнуться с ошибкой "Доступ запрещен".

Так же рекомендую ввести следующую конфигурацию в "Custom Nginx Configuration", в реверс прокси.

client_max_body_size 10G;
client_body_timeout 3600s;
client_body_buffer_size 512k;

proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
send_timeout 3600s;

proxy_buffering off;
proxy_request_buffering off;
  1. Поддержка больших файлов до 10 ГБ вместо стандартных 1-2 МБ

  2. Увеличенные таймауты для операций с большими файлами (загрузка/синхронизация)

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

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
  1. Корректное определение реального IP пользователя в логах Nextcloud

  2. Поддержка WebSocket для реального времени

  3. Правильное определение протокола для генерации URL

  4. Сохранение оригинального Host заголовка

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN always;
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;
add_header X-XSS-Protection "1; mode=block";
  1. HSTS принуждает использовать только HTTPS

  2. Защита от кликджекинга через X-Frame-Options

  3. Предотвращение MIME атак

  4. Блокировка межсайтового скриптинга

gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
  1. Снижение трафика на 60-80% за счет сжатия

  2. Ускорение загрузки интерфейса и статических ресурсов

  3. Оптимизированные настройки для веб-приложений

  4. Поддержка современных форматов (WebAssembly, JSON-LD, манифесты)

404 и что с ними будем делать?

Из неплохого варианта - замена стандартной страницы страницы 404 Nginx Proxy Manager на собственную кастомную страницу, для этого можно использовать следующий подход:

  1. Сначала создайте кастомную HTML-страницу в настройках NPM "Default Site".

  2. В настройках прокси-хоста перейдите в раздел "Advanced" и добавьте следующую конфигурацию:

error_page 404 =200 /index.html;
location = /index.html {
    root /data/nginx/default_www;
}

Итог

Пройдя все этапы настройки, мы создали полнофункциональный домашний сервер с безопасным доступом из вне. Теперь сервер превратился в полноценную альтернативу коммерческим облачным сервисам, но с полным контролем над данными и конфиденциальностью.

Спасибо что прочитали!

Комментарии (5)


  1. dezinger
    06.10.2025 08:05

    "Он станет тем самым постоянным адресом, по которому вы будете находить свой сервер из любой точки мира, не завися от капризов провайдера и сложных запоминаний IP-адресов. "

    А с каким IP вы связали домен? Полагаю вы забыли упомянуть что потребуется арендовать у провайдера постоянный IP.


    1. igrblkv
      06.10.2025 08:05

      Ну, кстати, обычно рекомендуют VPS/VDS с прокси-менеджером, который имеет доступ к локальным ресурсам и все ходят через белый ИП, выданный не Вашим домашним провайдером, а выданный виртуалке хостинг-провайдером. И при этом совсем не требуется белый ИП-адрес у домашнего провайдера.


      1. dezinger
        06.10.2025 08:05

        Да это вариант, через VPN тунель, где VPS это VPN-сервер а локальный сервер VPN-клиент. Почему автор опустил этот довольно важный момент непонятно. Так как это уже некоторые постоянные расходы хоть и небольшие.


  1. igrblkv
    06.10.2025 08:05

    1) А в каком месте почитать про UmbrelOS?

    2) Почему не unraid, CasaOS/ZimaOS, cosmos-server или Yunohost?
    Или TrueNAS Scale, например?
    Да и XPenology разве не подойдёт?


    1. requese Автор
      06.10.2025 08:05

      Приветствую.

      1. Собственно оф сайт: ссылка и гит: ссылка

      2. Был опыт работы ESXI ARM + CasaOS - вполне неплохая и более "открытая", в плане возможностей, ОС. Хотелось пощупать что то другое с более красивым UI. А про UmbrelOS в интернете гайдов не много.

      ПС: под "более открытая" имею ввиду деплой приложения напрямую из UI, т.е. нужен только docker compose и все. В UmbrelOS необходимо делать комьюнити маркет на git с docker compose, ссылка тут. Да и к тому же UmbrelOS на ARM не поддерживает внешние накопители, только внутренние диски (например те накопители, в Rasspberry Pi 5, которые подключены через PCIe).