Всем привет 👋
Врываюсь на Хабр с двух ног со своей первой статьей.
Всё чаще меня посещала мысль: а где на самом деле лежат наши фотографии, документы и личные переписки? Кто имеет к ним доступ и на каких условиях, точно ли все мои данные конфиденциальны? Любознательность и стремление к независимости хранения данных привела меня к идее своего облака, не где-то в далеком ЦОД, а здесь, дома, в гостиной, тихо жужжа в корпусе размером с книгу. Но есть один критически важный нюанс, который отделяет любительскую поделку от полноценной замены коммерческим сервисам — безопасный доступ извне. Зачем нам 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; }
Итог
Пройдя все этапы настройки, мы создали полнофункциональный домашний сервер с безопасным доступом из вне. Теперь сервер превратился в полноценную альтернативу коммерческим облачным сервисам, но с полным контролем над данными и конфиденциальностью.
Спасибо что прочитали!
