Всем привет ?
Врываюсь на Хабр с двух ног со своей первой статьей.
Всё чаще меня посещала мысль: а где на самом деле лежат наши фотографии, документы и личные переписки? Кто имеет к ним доступ и на каких условиях, точно ли все мои данные конфиденциальны? Любознательность и стремление к независимости хранения данных привела меня к идее своего облака, не где-то в далеком ЦОД, а здесь, дома, в гостиной, тихо жужжа в корпусе размером с книгу. Но есть один критически важный нюанс, который отделяет любительскую поделку от полноценной замены коммерческим сервисам — безопасный доступ извне. Зачем нам HTTPS, если для внутренней сети хватило бы и простого HTTP? Ответ выходит далеко за рамки банального «это нужно для шифрования и безопасности».
Нашим полигоном станет 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 доступно несколько решений для организации обратного прокси — критически важного компонента, который будет направлять трафик с ваших субдоменов на соответствующие приложения внутри сети. Давайте рассмотрим каждого из них.
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;Поддержка больших файлов до 10 ГБ вместо стандартных 1-2 МБ
Увеличенные таймауты для операций с большими файлами (загрузка/синхронизация)
Отключение буферизации предотвращает двойное копирование данных и уменьшает задержки при работе с файлами
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;Корректное определение реального IP пользователя в логах Nextcloud
Поддержка WebSocket для реального времени
Правильное определение протокола для генерации URL
Сохранение оригинального 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";HSTS принуждает использовать только HTTPS
Защита от кликджекинга через X-Frame-Options
Предотвращение MIME атак
Блокировка межсайтового скриптинга
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;Снижение трафика на 60-80% за счет сжатия
Ускорение загрузки интерфейса и статических ресурсов
Оптимизированные настройки для веб-приложений
Поддержка современных форматов (WebAssembly, JSON-LD, манифесты)
404 и что с ними будем делать?
Из неплохого варианта - замена стандартной страницы страницы 404 Nginx Proxy Manager на собственную кастомную страницу, для этого можно использовать следующий подход:
Сначала создайте кастомную HTML-страницу в настройках NPM "Default Site".
В настройках прокси-хоста перейдите в раздел "Advanced" и добавьте следующую конфигурацию:
error_page 404 =200 /index.html;
location = /index.html {
root /data/nginx/default_www;
}Итог
Пройдя все этапы настройки, мы создали полнофункциональный домашний сервер с безопасным доступом из вне. Теперь сервер превратился в полноценную альтернативу коммерческим облачным сервисам, но с полным контролем над данными и конфиденциальностью.
Спасибо что прочитали!
Комментарии (31)
igrblkv
06.10.2025 08:051) А в каком месте почитать про UmbrelOS?
2) Почему не unraid, CasaOS/ZimaOS, cosmos-server или Yunohost?
Или TrueNAS Scale, например?
Да и XPenology разве не подойдёт?
requese Автор
06.10.2025 08:05Приветствую.
Был опыт работы ESXI ARM + CasaOS - вполне неплохая и более "открытая", в плане возможностей, ОС. Хотелось пощупать что то другое с более красивым UI. А про UmbrelOS в интернете гайдов не много.
ПС: под "более открытая" имею ввиду деплой приложения напрямую из UI, т.е. нужен только docker compose и все. В UmbrelOS необходимо делать комьюнити маркет на git с docker compose, ссылка тут. Да и к тому же UmbrelOS на ARM не поддерживает внешние накопители, только внутренние диски (например те накопители, в Rasspberry Pi 5, которые подключены через PCIe).
aik
06.10.2025 08:05Большая часть перечисленного на малине не заведётся.
igrblkv
06.10.2025 08:05А, собственно, зачем на малине?
Потому что валяется без дела? Ну так это дело - то же не для неё, пусть дальше валяется.Хочется миниатюризации - есть intel NUC или аналоги с АлиЭкспресса.
aik
06.10.2025 08:05Зачем искать нюки, если есть под рукой малина?
igrblkv
06.10.2025 08:05Raspberry Pi 5 vs Intel N100 mini PC — сравнение характеристик, производительности и цены
Зачем за плюс-минус ту же цену выбирать существенно меньшую производительность, мягко говоря?
PS: Всегда засматривался на Pi400/Pi500, но так и не смог себе ответить "нафига?" - поэтому у меня ни одной малины нет под рукой.
Но если у Вас есть - продайте на Авито и купите нормальный мини-ПК, он сильно расширит возможности без непонятных UmbrelOS.
aik
06.10.2025 08:05Затем, что одно есть в наличии, а другого нет.
Я сам не любитель малин - ибо давно прошли времена, когда они были маленькие и дешевые (разве что зеро осталось). Но если малина есть под рукой и она с задачей справится, то искать альтернатив не буду.igrblkv
06.10.2025 08:05У меня есть предположение почему малина всегда под рукой: для тестов её хватает, но если надо сделать нормально - то решение переезжает на нормальную платформу, а малина снова становится "под рукой", до следующей итерации.
NutsUnderline
06.10.2025 08:05а еще есть репка, luckуfox и какой то роутер с приличным объемом оперативки :)
ki11j0y
06.10.2025 08:05Что то я не знаю, надо будет тоже написать опыт построения nas только на чистом debian13 с haproxy acme.sh и тд
А доверять вот таким сборкам не могу.
aik
06.10.2025 08:05Если вы используете cloudflare только как днс, то весь ваш трафик через него не идёт.
При настройке проброса портов может быть полезно настроить hairpin nat, чтобы изнутри вашей сети обращаться к сервисам по тем же доменным именам.
igrblkv
06.10.2025 08:05Он станет тем самым постоянным адресом, по которому вы будете находить свой сервер из любой точки мира, не завися от капризов провайдера и сложных запоминаний IP-адресов.
Если исходить из этого, достаточно сделать единую сеть между нужными устройствами с помощью ZeroTier/Tailscale/etc и никакие белые ИП-адреса, ДНС и прочее без надобности станут. А внутри хоть виндовые шары.
aik
06.10.2025 08:05достаточно сделать единую сеть между нужными устройствами с помощью ZeroTier/Tailscale/etc и никакие белые ИП-адреса, ДНС и прочее без надобности станут
Как минимум один белый IP нужен будет для впн-сервера.
igrblkv
06.10.2025 08:05Нет.
ZeroTier | Global Networking Solution for IoT, SD-WAN, and VPN
NetBird - Open Source Zero Trust Networking
aik
06.10.2025 08:05Это всё не отменяет наличие реального IP для VPN-сервера. Просто будет не ваш, а провайдерский.
igrblkv
06.10.2025 08:05С одной стороны, да, несомненно, белый ИП-адрес нужен...
С другой стороны, конкретно в ZeroTier/Tailscale/etc пользователю никаких ИП-адресов не надо заводить/оплачивать/знать - у него есть учётка и клиенты под разные ОСи.Но если ставить netmaker у себя (это бесплатный вариант) - то белый ИП-адрес понадобиться (локально или на виртуалке у хостинга).
aik
06.10.2025 08:05С другой стороны, конкретно пользователю никаких ИП-адресов не надо заводить/оплачивать/знать - у него есть учётка и клиенты под разные ОСи.
Если вопрос о том, чтобы максимально не зависеть от дяди, всё же свой сервер придётся поднять.
igrblkv
06.10.2025 08:05Тогда не надо смотреть на ZeroTier/Tailscale/etc
Однако данные решения подходят для
вы будете находить свой сервер из любой точки мира
с минимальными телодвижениями, иначе зачем тогда ставить UmbrelOS, а не нормальный Дебиан или Убунту с нужными сервисами?
PS: Собственно, если у Вас "локалка" на любом Вашем телефоне/планшете в любом месте - Вам и сервер не нужен, достаточно общей шары с нужными в дороге файлами.
vvbob
06.10.2025 08:05а где на самом деле лежат наши фотографии, документы и личные переписки? Кто имеет к ним доступ и на каких условиях, точно ли все мои данные конфиденциальны?
и чуток ниже..
Конфиденциальность со стороны Cloudflare. Используя Cloudflare, вы по умолчанию доверяете ему весь свой трафик
Выглядит как смена шила на мыло. Какому-либо гуглу или майкрософту мы не доверяем, зато, почему-то доверяем Cloudflare :))
igrblkv
06.10.2025 08:05Врываюсь на Хабр с двух ног со своей первой статьей.
С двух пятых ног, видимо.
Первый блин комом, бывает.
requese Автор
06.10.2025 08:05Вы правы, полная конфиденциальность при использовании любых сторонних сервисов, включая Cloudflare, недостижима. Ключевая мысль, которую я, вероятно, не смог донести четко, заключается не в слепом доверии, а в осознанном выборе и распределении рисков.
Идея в том, чтобы не менять "шило на мыло", а заменить потенциально "ржавое шило" на более предсказуемый и профессиональный инструмент, понимая его ограничения. Это компромисс между удобством, производительностью и конфиденциальностью.
vvbob
06.10.2025 08:05Ну, просто, ИМХО, если уж заморачиваться с собственным облаком, то лучше максимально отвязаться от услуг сторонних фирм, оставить только то, без чего это физически невозможно сделать (провайдер, да и то, можно еще и резервный канал сделать) . Это и концептуально правильнее (иначе какой смысл вообще этим заморачиваться) и в нынешних условиях, наверное, разумнее - забугорные сервисы могут заблокировать в любой момент.
Loco2k
06.10.2025 08:05Чем плох старинный способ с ddns и скриптом его обновления на роутере?
NutsUnderline
06.10.2025 08:05если делать https по стандартному порту то помимо всего прочего провайдер прикрывает чисто порт 443 и не работает
dezinger
"Он станет тем самым постоянным адресом, по которому вы будете находить свой сервер из любой точки мира, не завися от капризов провайдера и сложных запоминаний IP-адресов. "
А с каким IP вы связали домен? Полагаю вы забыли упомянуть что потребуется арендовать у провайдера постоянный IP.
igrblkv
Ну, кстати, обычно рекомендуют VPS/VDS с прокси-менеджером, который имеет доступ к локальным ресурсам и все ходят через белый ИП, выданный не Вашим домашним провайдером, а выданный виртуалке хостинг-провайдером. И при этом совсем не требуется белый ИП-адрес у домашнего провайдера.
dezinger
Да это вариант, через VPN тунель, где VPS это VPN-сервер а локальный сервер VPN-клиент. Почему автор опустил этот довольно важный момент непонятно. Так как это уже некоторые постоянные расходы хоть и небольшие.
requese Автор
Верно, да, я не стал углубляться в тонкости получения белого IP у провайдера, так как это сильно зависит от региона и тарифа, у меня например изначально белый IP был. Вариант с VPS и прокси-менеджером или VPN-туннелем — это классическое и более надежное решение, особенно если у провайдера нет белых IP или он использует CGNAT. Он решает проблему "капризов провайдера" кардинально, хоть и влечет небольшие, но постоянные расходы. В контексте статьи я хотел показать максимально бюджетный вариант, но для production-среды вариант с VPS, безусловно, предпочтительнее.