Собственное облако на windows server

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

Подготовка

Программа Seafile разработана на языке Python, поэтому для начала переходим на сайт Python и скачиваем последнюю версию для Windows:

Скриншот №1. Загрузка дистрибутива.

Важно! Для установки Python необходимы права администратора.

Нажимаем «ОК» и ждем завершения процесса. Следующий шаг — установка параметров системного окружения. Для этого открываем «Панель управления» и выбираем раздел, отмеченный красной стрелкой на скриншоте:

Скриншот №2. Дополнительные опции.

Далее переходим к пункту «Переменные среды»:

Скриншот №3. Выбор среды.

В открывшемся окне отмечаем системную среду Path и нажимаем кнопку «Изменить»:

Скриншот №4. Отредактировать системную переменную.

Добавляем путь, по которому установился Python. По умолчанию это либо системный диск С, либо домашняя папка пользователя. Нажимаем «ОК», чтобы сохранить изменения.

Seafile

Скачиваем программу с официального сайта Seafile:

Скриншот №5. Выбор версии.

На сайте доступна только версия для Linux. Скачиваем актуальный релиз. Далее создаем на локальном диске папку Seafile и разархивируем файл в эту директорию. Теперь переходим в каталог Seafile и активируем файл run.bat. Он откроет рабочую область, в которой укажем путь для установки серверной части Seafile.

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

Скриншот №7. Контекстное меню.

Откроется рабочее поле, в котором укажем электронный ящик и пароль. Эти учетные данные будут использоваться для подключения к серверу Seafile.

Теперь изменим параметры рабочей среды. Перейдем в каталог с установленным сервером, откроем текстовым редактором файл ccnet.conf., найдем строку Service_url и внесем следующие изменения:

SERVICE_URL = http://192.168.1.10:8000

В качестве IP-адреса используется адрес сервера, на котором установлен Seafile. Перезапустим серверную часть программы через контекстное меню, чтобы изменения вступили в силу:

Скриншот №8. Рестарт сервера.

Подключение

Открываем браузер и в адресной строке прописываем адрес, которой указывали в файле ccnet.conf. Если данные указаны верно, на мониторе появится приветственное окно Seafile. Вводим учетные данные и настраиваем работу с хранилищем.

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

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

В этой статье мы рассмотрим подробное руководство по созданию собственного облачного хранилища на сервере под управлением Windows Server.

Определяя требования вашей организации, вы можете выбрать специальное программное обеспечение для создания облачного хранилища или использовать ряд интегрированных инструментов Windows Server.

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

Что такое облачное хранилище?

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

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

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

Кроме того, облачное хранилище предоставляет масштабируемость и гибкость. Пользователь может увеличивать или уменьшать объем хранилища в зависимости от своих потребностей, а также легко добавлять или удалять пользователя для совместной работы.

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

Преимущества создания собственного облачного хранилища

1. Полный контроль над данными:

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

2. Высокая надежность:

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

3. Гибкость и масштабируемость:

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

4. Защита конфиденциальности:

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

5. Экономическая выгода:

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

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

Шаг 1: Установка и настройка Windows Server

1. Выбор версии Windows Server

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

• Windows Server 2019 — самая новая версия операционной системы, доступная на данный момент. Она обладает всеми последними функциями и улучшениями, но может быть немного сложнее в настройке и использовании для новичков.
• Windows Server 2016 — более старая, но все еще популярная версия операционной системы. Она предлагает стабильную и проверенную функциональность для создания облачных хранилищ.

Скачайте нужную версию Windows Server с официального сайта Microsoft и следуйте инструкциям по установке операционной системы.

2. Установка Windows Server

После загрузки образа Windows Server вам необходимо создать загрузочный носитель (например, CD/DVD или USB-флеш-накопитель) и запустить процесс установки.

При установке Windows Server выберите следующие параметры:

• Язык установки. Выберите язык, который будет использоваться в операционной системе.
• Систему исходного распределения. Если у вас есть лицензионный ключ или образ распространяемой операционной системы, выберите соответствующую опцию. В противном случае выберите «Автоотключение».
• Устанавливаемая операционная система. Выберите версию Windows Server, которую вы хотите установить.
• Соглашение о лицензии. Примите условия лицензионного соглашения, чтобы продолжить установку.
• Тип установки. Выберите «Чистая установка», чтобы начать установку операционной системы на новый жесткий диск или раздел. Если вы уже устанавливали Windows Server ранее и хотите обновить текущую версию, выберите соответствующую опцию.
• Раздел жесткого диска. Выберите раздел, на который будет установлена операционная система.
• Сведения о компьютере. Введите имя компьютера и пароль для учетной записи администратора.

После завершения установки операционной системы вы будете перенаправлены на рабочий стол Windows Server.

3. Основные настройки Windows Server

После установки Windows Server необходимо выполнить несколько основных настроек для обеспечения работоспособности вашего облачного хранилища. Вот некоторые из них:

• Обновление операционной системы. Проверьте наличие обновлений операционной системы и установите их, чтобы получить последние исправления и улучшения.
• Создание учетной записи администратора. Создайте учетную запись администратора для входа в систему и управления облачным хранилищем.
• Настройка сети. Настройте сетевые параметры, включая IP-адрес, доменное имя и прочие сетевые настройки, чтобы обеспечить связь вашего облачного хранилища с другими устройствами и сетями.
• Активация Windows Server. Активируйте лицензию Windows Server, чтобы получить полный доступ к функциям операционной системы.

После выполнения этих основных настроек Windows Server будет готов к установке и настройке облачного хранилища. В следующем шаге мы рассмотрим установку и настройку необходимых программ и компонентов для работы облачного хранилища.

Доброго времени суток! С уходом компаний я задался вопросом: «что делать, если прикроют мой любимый Google Drive?». Понятно, что есть аналоги – Яндекс.Диск и Облако Mail.ru, но оба бесплатно предоставляют только 8 гб дискового пространства, а дальше жесткая тарификация, в то время как Google дает 15 и стоит дешево. «А так, чтобы бесплатно?». Выяснилось, что существует [достаточно много open-source решений]() для домашнего и корпоративного использования. Одним из самых популярных и навороченных является система NextCloud, представляющая собой набор программ и модулей для развертывания своего полноценного облачного хранилища. NextCloud Server даже предлагается для скачивания во время установки Ubuntu Server.

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

Что полезного содержит эта статья.

• Запуск NextCloud в докере на Windows и Linux.

• Запуск NextCloud на домашнем компьютере. Проблемы, ограничения.

• Запуск NextCloud для тестирования. Приобретение понимания, нужен ли этот продукт.

• Анализ целесообразности развертывания облака дома.

• Подробный разбор параметров контейнера NextCloud AIO.

• VPN-тоннель домой с использованием сервиса Hamachi. Обход проблемы отсутствия белого ip.

• Настройка reverse-proxy на базе Nginx, Apache или Caddy.

• Запуск HTTPS-сервера на домашнем компьютере.

• Получение SSL-сертификата с помощью сервиса letsencrypt.

• Краткий разбор форматов SSL-сертификатов.

• Настройка файервола в Windows.

Стэк.

Домашняя машина, на которой запущен NextCloud: Windows 10, Docker, образ NextCloud AIO, Hamachi-клиент для Windows, PuTTy.

Reverse-proxy-сервер: Ubuntu Server, certbot, Nginx, или Apache, или Caddy, консольный Hamachi-клиент для debian.

Ключевые слова.

NextCloud, NextCloud-AIO, reverse-proxy, Nginx, Apache, Certbot, Hamachi, localhost, Windows, Defender, SSL, HTTPS дома.

Содержание.

• Целесообразность

• Об образе NextCloud AIO

• Этап 1. Настройка VPN

• Этап 2. Получение SSL-сертификата

  • Покупка

  • Самописные сертификаты certbot

• Этап 3. Настройка reverse-proxy

  • Apache

  • Nginx

  • Caddy

  • Тестирование

• Этап 4. Запуск NextCloud AIO в Docker

  • Переменные окружения

  • Volumes

  • Порты

  • Пояснения к опциям docker run

  • Запуск

  • Первичная настройка

  • Не работает domaincheck

• Этап 5. Фаервол

• Инструменты Windows для диагностики сетевых интерфейсов

• Заключение

Целесообразность.

Зададимся вопросом: а надо ли оно нам? Когда я приступал к настройке в первый раз, не зная особенностей этого программного комплекса, я бы однозначно ответил «да». Собственно, проблема стояла четко, и ее надо было преодолеть. У меня была техническая возможность и пометка в документации, что это развернуть NextCloud дома возможно. Но действительность оказалась, как всегда, скажем, другой. Сравним ожидание и реальность:

Ожидание:

• Использование своего железа: большие объем диска и ОП, быстрый процессор.

• Сервер установлен на той же машине, с которой осуществляется подключение loopback (localhost), следовательно, доступ к файлам мгновенный, как при использовании средств просмотра.

• Быстрый доступ (до 100 Мбит/с) со всех устройств в квартире, находящихся в локальной Wi-Fi- или Ethernet-сети: ПК, ноутбука, планшета, смартфона, часов, холодильника – для всей семьи.

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

• Доступ к файлам на ПК из любой точки мира с шифрованием.

• Авторизация подключений путем добавления пользователей в сеть VPN.

• Гибкая настройка доступа с помощью дополнительных модулей NextCloud для авторизации.

• Клевые расширения: сервис авторизации через соцсети, аналоги Google Meets, Google-карт и Google-календаря, таск-трекеры и т.д. — все в одном месте —  прямо как у «корпорации добра».

• OpenSource, а значит, поддержка на форумах, постоянные обновления.

• Все бесплатно, исключая затрат на железо: нет платы за ПО и аренду диска в облаке.

• Не надо настраивать файервол, т. к. vpn — это частная сеть.

Реальность:

• Отсутствие дистрибутива сервера NextCloud под Windows. Придется разворачивать на VM или в Docker. Но есть Windows-клиент. Однако, основным является браузерный клиент, а он кроссплатформенный.

• NextCloud обязывает завести домен несмотря на то, что часто достаточно было бы подключаться по VPN. Его нельзя запустить на localhost (127.0.0.1) или другом IP без домена.

• SSL. В принципе на этом можно было бы закончить. В репозитории NextCloud прямым текстом говорится о том, что концепция этой утилиты состоит в работе только с прокси по HTTPS. К сожалению, обязательная привязка к SSL перечеркивает все преимущества, основанные на быстром доступе по следующим причинам:

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

  • Белый IP требует денежных вложений, чего изначально я пытался избежать. За внешний сервер даже самый слабый так же нужно платить аренду. Кроме того, согласно документации NextCloud’а не желательно, чтобы само облачное хранилище работало на том же хосте, на котором хранятся SSL-сертификаты, так что придется настраивать reverse-proxy. Я арендовал самый дешевый сервер: за 400 рублей в месяц, 1 ядро, 1 Гб, 32 Гб – супер-невыгодное предложение (об этом далее). Это уже дороже, чем подписка Google Drive (от 140 рублей за 30 Гб до 700 за 2 Тб). В идеале, стоило бы разместиться у друга или на выделенном сотрудникам сервере в офисе компании, в которой Вы работаете (обязательно проконсультируйтесь у сисадмина по устранению уязвимостей, связанных с работой VPN).

  • Сервер с 1 ГБ виртуальной ОЗУ тормозит (утилита top показывает загрузку 70-90%), и не может скомпилировать даже небольшой проект, а в режиме reverse-proxy с трудом способен обеспечить доступ 2-м клиентам одновременно, хотя значительную задержку вносят операции на моем HDD (чтение HDD происходит со скоростью около 30 Мбит/с).

  • Большая задержка по сети: трафик идет от клиента в датацентр, где развернут прокси, а оттуда ко мне домой, при этом пропускная способность датацентра, как водится, отличная, а ADSL-линия (старая технология доступа в интернет по телефонным проводам), протянутая ко мне провайдером, обеспечивает скорость входящих пакетов (на скачивание) всего 40 Мбит/с, и если я не ошибся в определении технологии, используемой провайдером, скорость исходящих пакетов (выгрузка в интернет, т.е. максимальная скорость доступа к моему «облаку») ограничена где-то 10 Мбит/с, когда обычная jpeg-картинка весит 4.2 Мб.

  • SSL-сертификат иногда выписывается при оплате домена, но в других случаях требует отдельной покупки. Однако его можно выписать себе самому. Самописные сертификаты не принимаются современными браузерами или принимаются ограниченно. Преимущество NextCloud состоит в том, что он умеет самостоятельно решать эту проблему, но только если не используется свой reverse-proxy.

• Использование виртуальной машины накладывает ограничение на работу с облачным хранилищем напрямую через диск: все изменения в хостовой ФС NTFS должны быть проиндексированы (продублированы) в гостевой ФС Ext4. Хорошая новость состоит в том, что это не препятствие: перемещаем папку с ДЗ 30 Гб в папку NextCloud/data/<user>/files и создаем директорию с таким же названием через веб-клиент (в документации называется UI-client); однако иногда выскакивают предупреждения о невозможности выполнения операции особенно при удалении. На деле, мы всегда знаем, что ничего никуда не удаляется, а файлы просто перемещаются по диску в т. ч. в корзину.

• Нужно не забыть настроить файервол как на домашнем компьютере, так и на reverse-proxy сервере.

• Прежде чем приступать к настройке облака через веб-панель администратора, надо обязательно обеспечить доступ на сервер по порту 443. Этого требует NextCloud. Главная проблема при работе сервера на домашнем компьютере связана с этим. В Windows и Linux открыть для входящих соединений зарезервированные порты 0-1024 можно только лишь с правами администратора через настройки файервола. 443 порт может быть также заблокирован роутером. В Windows придется еще повозиться с политиками безопасности, в т. ч. групповыми. Прокси сервер и Docker тут кстати: можно настроить проброс портов и обойти эти трудности.

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

• Установка программного комплекса NextCloud только для пользования в ЛВС нецелесообразна, т. к. локальная сеть — это изолированная система без возможности принимать входящие подключения, а значит, смысл облака теряется. В таких случаях требуется настроить шлюз с белым IP-адресом. Для работы чисто в ЛВС, возможно, достаточно настроить совместный доступ к папкам на диске NTFS и включить сервер RPC (стандартная возможность в Windows).

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

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

Если Вам важно наличие именно функций NextCloud’а, некоторые люди на форумах предлагают поднять локальный DNS-сервер. Я пытался сделать и это, но такое решение не избавляет от необходимости подтверждать SSL-сертификат и разворачивать reverse-proxy, зато добавляет еще одну задачу по конфигурированию DNS в ЛВС. Если Вы решитесь пойти этом путем, посмотрите на bind9.

Итак, поставим задачу.

Задача

Хостинг NextCloud в локальной сети на Windows. Берем образ NextCloud AIO (all-in-one – англ. все в одном) – образ со всеми необходимыми утилитами.

Ресурсы

Наша библия для этого гайда – документация в репозитории.

Есть и другие варианты установки (листать до DOWNLOAD SERVER).

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

Мне очень помог этот гайд на youtube. Автор подробно объясняет, как будет работать итоговая система с точки зрения сисадмина. Он прошел через все этапы, настройки, которые затрагиваются в этом гайде. Единственное, он не рассказывает, как он установил сам NextCloud Server на свою машину. Кроме того, он использует Apache вместо Nginx и OpenVPN вместо Hamachi, не затрагивает тему Docker-контейнера NextCloud AIO.

На youtube, я не нашел гайдов, как запустить Docker-образ NextCloud AOI на локальной машине. А жаль, ведь есть много камней вроде выбора портов. Все развертывают NextCloud на внешнем арендованном сервере. Тем не менее, эти гайды демонстрируют, как правильно настроенный сайт выглядит в браузере.

Если Вы не знакомы с Docker, то для этого гайда это не критично. Но я все же посоветую посмотреть какой-нибудь гайд по запуску сервера в docker-контейнере. Бегло ознакомится стоит также с docker-compose.

Об образе NextCloud AIO.

Чтобы понять, что и для чего делается дальше, нужно пояснить, что входит в поставку образа NextCloud AIO. Если запустить этот контейнер, как сказано в документации, получим несколько дополнительных:

• nextcloud-aio-mastercontainer – главный контейнер, в который превращается с образ NextCloud AI при запуске.

• nextcloud-aio – основное приложение и веб-клиент к нему.

• nextcloud-aio-redis – кто бы мог подумать, редис.

• nextcloud-aio-database – контейнер, обеспечивающий соединение с БД. После установки будет предложено подключить свою: postgres, mysql или создать sqlite.

• nextcloud-aio-apache – контейнер, обеспечивающий подключение ssl-сертификатов. Работает как reverse-proxy. Принимает HTTPS-запросы на порту 443 и передает их HTTP-версию на обработку в контейнер с основным приложением. Также, генерирует ssl- сертификаты. Самое интересное, что внутри контейнера, который называется nextcloud-aio-apache используется еще и готовый reverse-proxy Caddy. Caddy позволяет запустить HTTPS-сервер с самописными сертификатами с помощью однострочного конфига. Внутри себя запускает утилиту certbot, о которая также затрагивается в этом гайде (этап 2). Функционал этого контейнера не используется целиком, если подключаем внешний прокси-сервер. В этом гайде расписано, как это работает в этапе 2 и этапе 3.

• nextcloud-aio-domaincheck – в этом контейнере обрабатываются ACME DNS Challenge-запросы для подтверждения самописанных ssl-сертификатов, если не используется внешний прокси. См. этап 2 вариант 2.

• nextcloud-aio-callabora и nextcloud-aio-talk – дополнительные модули NextCloud. Их будет предложено подключить по окончании настройки.

На reverse-proxy не стоит обращать внимания. Это «имя проекта» — имя директории, где лежит docker-compose.yml.

Этап 1. Настройка VPN.

VPN позволит принимать соединения на домашнем компьютере без приобретения белого ip-адреса у провайдера.

Буду использовать Hamachi. У него хороший десктоп-клиент на Windows и есть консольный на Linux. Можно использовать любой другой VPN: например, в этом гайде используется аналог —  OpenVPN.

Ставим клиент на Windows. Создаем сеть, даем ей имя и пароль.

Переходим в Настройки -> безопасность. Ставим: Шифрование – включено, Сжатие – любой. Переходим в Дополнительные -> Соединения с одноранговым узлом -> фильтрация трафика — разрешить все.

Фильтрация трафика – это по сути файервол. Hamachi добавит новую (виртуальную) сеть, которая для ОС аналогична полноценному сетевому интерфейсу, т.е. в компьютере как бы появится новая сетевая карта. Посмотреть на нее можно в панели управления: Панель управления -> Сеть и Интернет -> Центр управления сетями и общим доступом:

Также можно увидеть этот интерфейс, введя в консоль или powershell, запущенную от имени администратора (Win+X -> Windows PowerShell от имени администратора) команду ipconfig:

На этой сети может работать встроенный файервол Windows (Defender). Его настроим в конце. 

Перейдем на Ubuntu-сервер. Я для этого использую клиент PuTTy.

На reverse-proxy-сервере достаточно подключиться к нашей сети как клиент (показано для Debian/Ubuntu (Про установку в CentOS):

wget http://www.vpn.net/installers/logmein-hamachi_2.1.0.165-1_amd64.deb
sudo dpkg -i logmein-hamachi_2.1.0.165-1_amd64.deb
# подключение к сети > в графическом клиенте появится новый участник
hamachi join <network id> <password>
# включение автозагрузки сервиса 
sudo systemctl enable logmein-hamachi

Теперь можно проверить работу VPN-тоннеля. Либо на сервере, либо на домашнем ПК наберите ping <ip домашнего ПК или ip сервера, который выдал Hamachi>. Также это можно сделать в графическом клиенте Hamachi: ПКМ по участнику сети -> Проверить доступность.

Этап 2. Получение SSL-сертификата.

Если хотите использовать Caddy в качестве reverse-proxy, этот этап можно пропустить. Главное, чтобы Ваш сервер был доступен в интернете (имел белый ip), т. к. Caddy внутри себя использует certbot (см Этап 2. Вариант 2 ниже). Более того, при использовании образа NextCloud AIO на той же машине, где развернут сам NextCloud Вам не требуется его настраивать, т.к. он входит в образ.

Вариант 1. Покупка сертификата.

Покупаем сертификат. Получаем 2 файла: fullchain-сертификат и приватный ключ, переводим их в формат .pem. Тут и далее будем называть их fullchain.pem и privkey.pem. Для Apache еще нужен будетpublic.pem с публичным ключом.

Примечание. В основном встречаются 3 типа форматов ключей: .pem, .crt, .cer, .key. Расширение файла не имеет значения. Имеют значение блоки в них. Подробнее тут. Центр выдачи сертификатов, например, reg.ru, даст Вам 5 файлов следующего вида:

Публичный сертификат

——BEGIN CERTIFICATE——

<много букв и цифр>

——END CERTIFICATE——

Корневой сертификат
——BEGIN CERTIFICATE——

<много букв и цифр>

——END CERTIFICATE——

Промежуточный сертификат
——BEGIN CERTIFICATE——

<много букв и цифр>

——END CERTIFICATE——

Запрос на получение сертификата
——BEGIN CERTIFICATE REQUEST——

<много букв и цифр>

——END CERTIFICATE——

И приватный ключ

——BEGIN RSA PRIVATE KEY——

<много букв и цифр>

——END RSA PRIVATE KEY——

Из конечного, промежуточного, корневого сертификатов в обычном блокноте нужно собрать fullchain, а приватный ключ записать отдельно. Если используете Apache, вынесете также отдельно публичный сертификат в файл public.pem. Если чего-то для fullchain не хватает, вставляйте то, что есть, главное, чтобы был корневой или промежуточный.

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

Промежуточные сертификаты. Любые виды цепочек сертификатов. Тоже имеют право удостоверять (подписывать) другие сертификаты.

Сохраняем 2 файла в папку /certificates на сервере. В PuTTy вставка текста осуществляется через ПКМ.

Вариант 2. Генерация самописного сертификата с помощью сервиса letsencrypt и утилиты certbot.

apt update
apt install -y software-properties-common
apt update
apt install -y certbot
certbot certonly -d www.<Ваш домен>,<Ваш домен> --agree-tos –n
certbot certificates
certbot renew --dry-run

Первые 4 команды обновляют репозитории для скачивания и устанавливают утилиту certbot. Команда на пятой строке говорит сгенерировать или обновить сертификат (certbot certonly) для доменов <Ваше доменное имя> с доменом верхнего уровня www и без него (вводить домены через запятую) (-d www.<Ваш домен>,<Ваш домен>) в неинтерактивном режиме для пропуска всех вопросов (certbot -n), соглашаясь с лицензионным соглашением ACME DNS Challenge (certbot --agree-tos). Предпоследняя покажет, в какую директорию certbot записал сертификаты. Последняя команда просит автоматически обновлять сертификаты по их истечению. Сами по себе сертификаты действительны 3 месяца.

Возможно, Вам также пригодятся следующие флаги команды certbot:

-m <email> — сюда будут приходить уведомления о состоянии сертификата, например, напоминания о том, что его надо продлить.

--webroot <путь> — certbot положит сертификаты в эту папку. Удобно, если уже есть развернутый сервер.

ACME DNS Challenge – это специальный стандарт проверки доменов, которые использует letsencrypt. Это накладывает дополнительные ограничения. Например, эти сертификаты не будут работать на собственном DNS, ведь для их подтверждения на Ваш сервер будет приходить запрос от letsencrypt по url, начинающимся на _acme-challenge или .well-known/acme-challenge. Надо научить сервер правильно на него отвечать. Это для нашей задачи вообще не понадобится, но кому интересно, подробнее тут. В Nginx-конфиге, например, поддержку ACME через HTTP можно осуществить, добавив что-то вроде

location ~ .well-known/acme-challenge {
    allow all;
    root /usr/share/nginx/html;
} 

От выбора способа получения сертификата в нашем случае зависит не только положение ключей на диске (будем считать, что они лежат в /certificates). В случае с certbot’ом, если Вы используете Nginx, надо будет немного изменить конфиг (об этом в конфиге ниже).

Этап 3. Настройка reverse-proxy.

Образ NextCloud AIO поддерживает внешний reverse-proxy как опцию и требует, связать его и порт машины, где развернут контейнер Apache, входящий в поставку NextCloud AIO, а для этого надо указать переменную среды для контейнера APACHE_PORT с номером этого порта. В конфиге прокси-сервера требуется все внешние HTTPS-запросы перенаправлять на этот порт. Он может быть любым, но в документации используется 11000. Его и укажем. Итак, перенаправляем HTTP-запросы (порт 80) на HTTPS (443), а HTTPS 443 на HTTP11000. Таким образом, любой запрос в браузере к нашему домену, где явно не указан порт, будет приходить на порт 11000 машины, где развернут контейнер NextCloud AIO.

Вариант 1. Reverse-proxy на базе Apache

Наглядно процесс настройки показан в том ролике, на который я ссылался ранее. Конфиг ниже взят из него.

# файл apache.conf – конфиг, как в видеоролике

<VirtualHost *:80>
    ServerName www.<домен>
  
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>


<VirtualHost *:443>
    SSLEngine on
    RequestHeader set X-Forwaded-Proto "https"
    SSLCertificateFile /certificates /public.pem
    SSLCertificateKeyFile /certificates /privkey.key
    SSLCertificateChainFile /certificates /fullchain.crt
    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5:!3DES
    SSLHonorCipherOrder on
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

    ServerName www.<домен>

    ProxyPreserveHost On
    ProxyPass / http://<ip домашнего компьютера в сети hamachi>:11000/
    ProxyPassReverse / http://<ip домашнего компьютера в сети hamachi >:11000/
</VirtualHost>

Можно попробовать альтернативный конфиг, представленный в документации.

Установим сам Apache и активируем конфиг.

apt update
apt install apache2

# Создаем или перемещаем конфигурационный файл в правильную директорию
mv <домен>.apache.conf /etc/apache2/sites-available/<домен>.conf

# Подключаем модули для работы с https в режиме проксирования
a2enmod proxy rewrite ssl headers proxy_http

# По умолчанию Apache уже имеет конфиг с базовым сайтом-пустышкой.
#Отключаем. И подключаем свой.
a2dissite 000-default.conf
a2ensite <домен>.apache.conf

# Проверка конфига
apachectl configtest

# Если выскочит предупреждение о том, что apache не знает имени сервера,
# выполним следующие 3 команды (необязательно):
chmod 777 /etc/apache2/apache2.conf
echo -e "$(cat /etc/apache2/apache2.conf)\nServerName <любое имя>" > /etc/apache2/apache2.conf
chmod 644 /etc/apache2/apache2.conf

# Обязательно перезапускаем apache
service apache2 restart  # или systemctl restart apache2

Развернуть Apache сервер для теста с NextCloud можно, например, в докере, воспользовавшись docker-compose.

# docker-compose-apache.yml
services:
  apache-reverse-proxy:
    image: php:7.4-apache
    restart: unless-stopped
    container_name: apache
    volumes:
      - ./certificates:/certificates
      - ./apache.conf:/etc/apache2/sites-available/apache.conf
    ports:
      - "80:80"
      - “443:443” 
      - "11000:11000"
    network_mode: 'host'
    tty: true
    command: bash -c "
      chmod 777 /etc/apache2/apache2.conf
      && echo -e \"$$(cat /etc/apache2/apache2.conf)\\nServerName www.sabernews.ru\" > /etc/apache2/apache2.conf
      && chmod 644 /etc/apache2/apache2.conf
      && a2enmod proxy rewrite ssl headers proxy_http
      && a2dissite 000-default.conf
      && a2ensite sabernews-nexcloud.apache.conf
      && service apache2 restart
      && apachectl configtest
      && apt update
      && apt install -y net-tools
      && tail -f /dev/null
      "

  nextcloud:
    image: nextcloud/all-in-one:latest
    restart: unless-stopped
    container_name: nextcloud-aio-mastercontainer
    ports:
      # про порты для nextcloud далее
      - "8080:8080"
      - "80:80"
      - "11000:11000"
      - "8443:8443"
    environment:
      - NEXTCLOUD_DATADIR=nextcloud_aio_nextcloud_datadir
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - //var/run/docker.sock:/var/run/docker.sock:ro
    depends_on:
      - apache-reverse-proxy

volumes:
  nextcloud_aio_mastercontainer:

Вариант 2. Reverse-proxy на базе Nginx

Лично я использовал сервер, на котором был запущен другой веб-сайт, работающий на Nginx, а значит порты 443 и 80 уже были заняты. Как уже отмечалось выше, NextCloud’у обязательно нужен 443 порт. Однако домены разные, а значит, надо просто дополнить конфиг Nginx следующими строчками, которые будут работать и как самостоятельный конфиг-файл:

# <домен>.nginx.conf
# -> нужно поместить в /etc/nginx/nginx.conf

http {

## reverse-proxy
  server {
    listen 80 default;
    server_name www.<домен>;
    access_log off;
    error_log off;
    return 301 https://$server_name$request_uri;
  }

  server {
    server_name www.<домен>;
    listen 443 http2 ssl;
    access_log  /root/reverse-proxy/access.log;

    ssl_certificate     /certificates/fullchain.pem;
    ssl_certificate_key /certificates/privkey.pem;
    # эти строчки требуются для правильной работы сертификатов сертбота
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY13305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

    location / {
      add_header Cache-Control "public, must-revalidate";
      add_header Front-End-Https on;
      add_header Strict-Transport-Security "max-age=2592000; includeSubdomains";
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_pass http://<ip>:11000;    }
  }
#server ## reverse-proxy

} # http

В документации написано, что конфиг, представленный там, может не работать. Он действительно не работает из-за строчки proxy_set_header Host $host;, которая сохраняет заголовок Host HTTP, содержащий ip-адрес клиента. Это стандартное решение для прокси-серверов, иначе бекенд не сможет отличать клиентов по этому заголовку, если требуется. Однако в режиме reverse-proxy, когда прокси сервер перенаправляет через себя как запросы клиентов, так и ответы бекенда: и то, и то для прокси сервера является входящими сообщениями, которые подлежат обработке. Nginx опирается на Host, чтобы их различать. Если подменить хост, то это приводит к бесконечному перенаправлению запросов.

Запустим Nginx:

mv <домен>.nginx.conf /etc/nginx/nginx.conf
# тестируем конфиг
nginx –t
# Обязательно перезапускаем nginx
service nginx restart  # или systemctl restart nginx

Вариант 3. Caddy reverse-proxy

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

# Caddyfile

https://<домен>:443 {
    reverse_proxy <ip>:11000
}

Проверка работы

Остается протестировать. Я написал простой сервер на NodeJS для этого.  Для запуска Вам понадобится установить node.

// server.js
const http = require("http");

const host = '0.0.0.0';
const ports = [80, 443, 8443, 11000, 8080];

const servers = ports.map((port) => {
  try {
    return [http.createServer((req, res) => {
      console.log(`[${port}]`, req.url, '  |', req.headers['user-agent'].slice(0, 20), '|   ', req.headers['x-forwarded-for']);
      req.on('error', (err) => {
        console.error(err);
      });

      res.writeHead(200);
      res.end(`served by ${port}\n${req.headers["user-agent"]}\n`);
    }), port];
  }
  catch (err) {
    console.error(err);
  }
});


servers.forEach(([server, port]) => {
  try {
    server.listen(port, host, () => {
      console.log(`Server is running on ${host}:${port}`);
    });
  }
  catch (err) {
    console.error(err);
  }
});

Здесь запускается прослушка 5 портов (они перечислены в массиве на строке 5). Запустим на домашнем компьютере:

node server.js

Перейдем в браузер и вобьем: http://localhost:80, http://localhost:443  и т.д. – будет отображаться надпись с тем портом, на который мы подключились и Ваши текущие user-agent, и ip-адрес в заголовке Host. Обратите внимание, что протокол здесь только HTTP, и значка с замочком в браузере при таком подключении не появится.

Теперь заменим строку 4 const host = '0.0.0.0'; на  const host = '<ip-адрес ПК в сети Hamachi>'. Перезапустим: Ctrl+C и снова node server.js. Подключиться теперь можно только по портам 80 и 443, т.к. наш конфиг прокси сервера (любой из 3-х представленных выше) указывает ему перенаправлять запросы с порта 80 на порт на 443, а к запросам с порта 443 подключать сертификат и перенаправлять его на порт 11000 по протоколу HTTP, поэтому вбив <ip>:80, http://<ip>, <ip>:443 или https://<ip>(ip — это ip-reverse-proxy-сервера), или www.<домен>, увидим что-то вроде:

Хоть мы и не подключались явно к порту 11000, сервер принял запросы на нем, что отображено в ответе. Обратите внимание на замочек – установлено HTTPS-соединение.

Этап 4. Запуск NextCloud AIO в Docker.

Переменные окружения

У данного образа есть две основные опции, которые передаются как переменные окружения:

• NEXTCLOUD_DATADIR – абсолютный путь до директории, а в случае с Windows, константная строка “nextcloud_aio_nextcloud_datadir” – это имя того docker-volume, в которой будут записаны все файлы пользователей и системные файлы, необходимые для функционирования NextCloud. Соответственно, надо будет предварительно создать этот volume.

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

  Обратите внимание на простые правила преобразования пути. Абсолютный путь в Windows C:\NextCloudData превращается в host_mnt/c/NextCloudData.

• APACHE_PORT – переменная уже затрагивалась выше. Это номер порта, на который пересылает запросы Ваш reverse-proxy.

• SKIP_DOMAIN_VALIDATION=true – выставить, если есть неразрешимые проблемы с тем, что NextCloud неправильно определяет домен, на котором запущен. Это будет понятно после первой настройки. В документации указано, что пользоваться этим надо только в крайнем случае, если Вы уверены, что всё остальное было сделано правильно. В этом гайде пользоваться этим флагом не нужно. Ниже приведены советы, что делать, если не получается запустить NextCloud.

Volumes

Есть 2 фиксированных имени вольюмов, которые нам понадобятся.

• nextcloud_aio_nextcloud_datadir – директория, где будут содержаться все файлы в облаке NextCloud. См пояснения выше к переменной NEXTCLOUD_DATADIR.

• nextcloud_aio_backupdir – директория, куда будут помещаться архивы с копиями состояния облака, если Вы захотите использовать эту функцию. История точно такая же как с nextcloud_aio_nextcloud_datadir: проверить, что путь существует, и соблюсти формат преобразования.

Их надо будет только создать. Подключать к контейнерам ничего не нужно. NextCloud сам умеет ими пользоваться.

Порты контейнера

Контейнер на образе NextCloud AIO использует 3 порта, которые согласно документации, нужно указать при запуске контейнера:

• 8080 порт используется для первичной настройки NextCloud. Там будет панель администратора.

• 80 порт – единственный, который предназначается для взаимодействия с веб-приложением непосредственно. Соответственно, это протокол HTTP. Напомню, что все сторонние запросы  к системе переводятся на HTTPS нашим прокси и поступают на 11000 порт контейнеров, которые уже внутри, неявно для нас, переведут их на 80 порт на обработку приложением.

• 8443 порт должен использоваться для обновления самописного сертификата. Лично я с этим не работал, и не могу ничего сказать.

Как говорилось выше, на домашней машине будет непросто открыть порт 80. Да это и не нужно, когда докер представляет нам простой механизм переадресации портов. Я просто использовал порт 9090 вместо 80. Также я подменил порт 8080 в мастер-контейнере на 9880, т.к. иногда использую порт 8080 моего ПК при разработке своих серверов, и подменил 8443 портом 9443 просто за компанию.

Другие порты, такие как 11000 (наш APACHE_PORT) и 3478, используемые дополнительными модулями, будут подключаться автоматически. При запуске master-контейнера, их не нужно привязывать явно. После запуска будет автоматически созданы контейнеры nextcloud-aio-domaincheck и nextcloud-aio-apache, которые свяжутся с портом APACHE_PORT, а после настройки системы в панели администратора, появятся и другие контейнеры, например, nextcloud-aio-talk, которые займут свои порты.

Опции Docker

Очень важно не передавать настоящий сетевой интерфейс операционной системы хостовой машины как внутренний сетевой интерфейс контейнера. Это делается с помощью передачи опции --net=host в команде docker run или network_mode: 'host' в docker-compose. Можно встретить некоторые гайды в интернете, которые предписывают делать именно так. Но это не соответствует документации! Единственное, когда это может быть оправдано, — запуск контейнера на выделенном Linux-сервере, когда докер применяется как IaC средство в задаче оркестрирования. В нашем же случае, контейнер просто не сможет открыть порты 80, 443, т.к. у него нет прав.

• --sig-proxy=false – отключает проксирование сигналов ОС.

• --name=<имя> — задает имя контейнеру

• --restart=<always | no | unless-stopped> — регулирует, что делать в случае критической ошибки или иных случаях, когда контейнер может завершить работу. Соответственно: всегда, никогда и до тех пор, пока пользователь вручную пошлет SIGTERM/SIGBRK. Облако должно быть доступно всегда. Ставим always.

• -e <имя>:<значение> – передача переменной окружения

• -v (--volume) <директория хост>:<директория в ОС контейнера>, либо <имя volume> — передача volume или директорий хостовой машины в пользование контейнеру. Что передавать берем из документации: nextcloud_aio_mastercontainer:/mnt/docker-aio-config, //var/run/docker.sock:/var/run/docker.sock:ro.

• -p (--port) <порт хост>:<порт в интерфейсе контейнера> — соединение порта сетевого интерфейса хостовой машины и сетевого интерфейса контейнера.

Запуск

Сначала надо создать volume’ы.На Windows nextcloud_aio_nextcloud_datadir обязательный, nextcloud_aio_backupdir — опциональный.

Тут последовательность из пробела и обратной кавычки ( ` ) используется для ввода многострочной команды.

В Unix-системах аналогом выступает пробел и обратный слэш ( \).

# Backup dir
docker volume create `
--driver local `
--name nextcloud_aio_backupdir `
-o device="/host_mnt/c/NextCloudBackups" `
-o type="none" `
-o o="bind"

# Datadir
docker volume create `
--driver local `
--name nextcloud_aio_nextcloud_datadir `
-o device="/host_mnt/c/NextCloudData" `
-o type="none" `
-o o="bind"

Запускаем контейнер ровно так, как предписывает документация, но подменяем порты:

docker run `
-e NEXTCLOUD_DATADIR="nextcloud_aio_nextcloud_datadir" `
-e APACHE_PORT=11000 `
--sig-proxy=false `
--name nextcloud-aio-mastercontainer `
--restart always `
-p 9090:80 `
-p 9880:8080 `
-p 9443:8443 `
--volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config `
--volume //var/run/docker.sock:/var/run/docker.sock:ro `
nextcloud/all-in-one:latest

Либо через docker-compose:

# docker-compose.yml

services:
  nextcloud:
    image: nextcloud/all-in-one:latest
    restart: "always"
    container_name: nextcloud-aio-mastercontainer
    environment:
      - NEXTCLOUD_DATADIR=nextcloud_aio_nextcloud_datadir
      - APACHE_PORT=11000
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - //var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "9080:80"
      - "9090:8080"
      - "8443:8443"

volumes:
  nextcloud_aio_mastercontainer:

docker-compose up

После запуска панель docker станет выглядеть так:

Тут видно все то, о чем было написано выше: появились новые контейнеры, которые заняли нужные ими порты. Master-container появляется первым и занял порты 9090, 9880 и 9443.

Остается настроить само облако

Переходим в браузер. Нужно подключиться к 8080 порту контейнера, т.е. для нас это адрес, оканчивающийся на :9880. Какой ip вводить? Любой, чтобы не попасть на прокси, ведь тот не знает о том, что что-то нужно пересылать на порт 9880. Можно вбить localhost:9880, <ip в локальной сети домашнего маршрутизатора 192. …>:9880 или <ip ПК в сети Hamachi>:9880 – все эти адреса ведут на порт 9880 одной и той же машины. Подключаться нужно по HTTPS (обязательно вбейте https:// перед адресом и портом, потому что браузер скорее всего сам подставит http, и тогда появится Bad Request от Apache с просьбой перейти на HTTPS). Далее выскачет предупреждение, что соединение небезопасно, но мы ведь знаем, что все безопасно, верно ;). Нажимаем «все равно подключиться» (на разных браузерах эта кнопочка может называться по-разному и быть скрыта за другой кнопкой, например, в Opera надо сначала нажать “help me understand”).

В NextCloud всё сделано именно так, потому что все внешние соединения должны быть зашифрованы и поэтому осуществляются через прокси по HTTPS. Считается, что раз до контейнера доходят HTTP-сообщения, значит, они либо защищены протоколом ssl на уровень выше, либо у оператора есть прямой доступ к машине.

Скопируем и сохраним в блокнот мнемоническую фразу для восстановления системы.

Далее на следующей странице надо будет ввести домен, который пользователь вбивает в браузере, чтобы подключиться, т.е. тот, по которому он попадает на reverse-proxy. В нашем случае www.<домен>. Форма ниже, связанная с бекапом понадобится не сейчас, а во время восстановления бекапа.

Если все успешно, Вас пробросит дальше на страницу, где будет создана учетная запись администратора. Сохраняем куда-нибудь выданный нам пароль. Тут же можно установить некоторые дополнительные модули (их намного больше). Знайте, что каждый модуль – это отдельный докер-образ, а значит весит он много, и его контейнер строится долго. Запустите все контейнеры и дождитесь, когда индикаторы загорятся зеленым.

Скриншоты к вышеописанному процессу не прилагаю. Все есть в обилии на youtube.

Что делать, если проверка домена не выполняется?

Для начала, это значит, что NextCloud попробовал найти сам себя по запросу https://<домен, который Вы ввели на панели администратора> и не смог.

Проверьте, что на домене, который Вы приобрели, есть А-запись с правильным ip-адресом прокси-сервера. Если вы только что обновили эту запись, DNS-сервера провайдера распространяют её иерархически на магистральные роутеры, и на это может потребоваться время (по моим оценкам, до получаса). Можно,  например, воспользоваться командой windows powershell ping <домен>. В Widows она хороша тем, что вместо домена нам будет показан ip-адрес, ассоциированный, как считает домашний роутер, с введенным доменом. Другие утилиты, такие как tracert могут не помочь в случае с арендованными серверами или vpn — все зависит от того, какие запросы пропускает к себе в датацентр хостинг.

Также стоит проверить, что прокси сервер работает, доступен в сети по собственному ip-адресу и на нем запущен Apache/Nginx/Caddy. Не пренебрегайте тестированием конфигов. Узнать, работает ли сервер можно, вбив systemctl status <apache2 | nginx | caddy>.

Не забудем проверить и vpn-тонель со стороны сервера на домашний компьютер.

Для остальных случаев есть флаг SKIP_DOMAIN_VALIDATION.

В конце есть список сетевых утилит Windows, которые могут помочь с отладкой сетевого маршрута.

Этап 5. Фаервол

Финальная часть – предотвращение несанкционированных попыток подключения к домашнему компьютеру и спама до состояния DDOS – настроим файервол.

В Linux – воспользуйтесь утилитами ufw или iptables.

Вбиваем в поиск системы «Защита от вирусов и угроз», или «Безопасность Windows», или «Defender», переходим в Брандмауэер -> дополнительные параметры ->правила для входящих подключений.

 Нажимаем справа «создать правило», выбираем фильтрацию по порту: специальные порты, 11000. Если накладываете какие-то другие опции фильтрации, помните, что Hamachi – это частная сеть в ОС Windows.

Если планируете использовать эту же сеть Hamachi для передачи еще какого-то трафика, обязательно откройте порт здесь. Правила Defender можно редактировать на лету.

Инструменты Windows для диагностики сетевых интерфейсов

Все перечисленные здесь утилиты работают в powershell и cmd. Лучше выполнять от имени администратора.

nslookup – получение ip по доменному имени на DNS-сервере, сведения о ближайшем DNS-сервере. Будьте внимательны, лично я столкнулся с тем, что nslookup кеширует свои ответы, и если, например, Вы меняете А-запись к своему домену, браузер может видеть изменения, а nslookup – нет. На этот случай есть команда ipconfig/flushdns, но мне она не помогала.

ipconfig/flushdns – сброс dns-кеша в ОС. Работает только в cmd.

Работу DNS можно сымитировать, добавив запись в системный файл C:\Windows\System32\drivers\etc\hosts.

netstat -na | findstr ":8080"  — просмотр установленных соединений. Просто netstat -na покажет все соединения.

ipconfig   — просмотр сетевых интерфейсов. Тут можно наблюдать сеть докера docker0 или WSL — она нужна, когда контейнер общается с сервером на хосте (почитайте про внешний адрес host.docker.internal).

Посмотреть, куда и как (редиректы, HTTP-заголовки) идут запросы в браузере можно через инструменты разработчика. Ctrl+Shift+I или ПКМ по пустому пространству в браузере -> network

Заключение

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

Тем не менее, опыт, я считаю, интересный. Пользоваться дома вполне можно. Все еще остается возможность переноса хранилища на какой-то тихий компьютер, такой который бы не жужжал при постоянной эксплуатации 24/7. Прекрасно подойдет старый системный блок или ноутбук с утилитой управления скоростью вращения вентиляторов.

Если планируете использовать NextCloud ровно так, как описано в этом гайде, то главное не забыть поставить Docker и Homachi на автозапуск. Так будет достигнута неплохая отказоустойчивость.

Надеюсь, материал был полезен. Спасибо, что читаете. Увидимся в другом гайде.

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

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

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

В этой инструкции мы покажем, как установить и настроить ownCloud на операционной системе Windows, чтобы создать свою собственную облачную платформу. Следуя этой подробной инструкции, вы сможете хранить, обрабатывать и синхронизировать свои файлы с различных устройств, а также обеспечить безопасность и контроль данных.

Выбор необходимых программ и компонентов

Для создания собственного облачного хранилища на операционной системе Windows вам понадобятся следующие программы и компоненты:

1. Операционная система Windows:

Для создания облачного хранилища на базе Windows можно использовать любую версию операционной системы, начиная с Windows 7 и выше. Желательно выбрать самую актуальную версию ОС для обеспечения безопасности и доступности последних обновлений.

2. Специализированное облачное программное обеспечение:

Для создания облачного хранилища на Windows можно использовать различное программное обеспечение, такое как:

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

— Nextcloud: форк OwnCloud, также бесплатное программное обеспечение с открытым исходным кодом, с более широкими возможностями и дополнительными функциями;

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

3. Веб-сервер:

Для работы программного обеспечения облачного хранилища вам может потребоваться веб-сервер. Популярными выборами для Windows являются Apache и Nginx. Выбор веб-сервера зависит от предпочтений и требований к производительности.

4. База данных:

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

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

Установка и настройка сервера

Для создания собственного облачного хранилища на операционной системе Windows необходимо выполнить следующие шаги:

1. Установить и настроить серверное программное обеспечение. Для этого можно использовать такие популярные программы, как OwnCloud, Nextcloud или Seafile. Следуйте инструкциям по установке и настройке, предоставляемым разработчиками каждого ПО.
2. Выбрать директорию на сервере, в которой будет размещаться облачное хранилище. Убедитесь, что у пользователя, под которым будет работать серверное ПО, есть необходимые разрешения для доступа к этой директории.
3. Настроить соединение с Internet и прокинуть необходимые порты на маршрутизаторе, если требуется доступ к облачному хранилищу извне локальной сети.
4. Создать учетную запись администратора облачного хранилища. Учетная запись администратора обеспечивает доступ к административным функциям и настройкам облачного хранилища.
5. Настроить пользовательские учетные записи и права доступа. Определите пользователей, которым будет предоставлен доступ к облачному хранилищу, и установите соответствующие права доступа к данным и функционалу.
6. Настроить параметры безопасности. Убедитесь, что облачное хранилище защищено паролем и/или другими мерами безопасности, чтобы предотвратить несанкционированный доступ к данным.

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

Настройка сетевого доступа и безопасности

1. Защита сети:

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

2. Использование SSL-сертификата:

Для обеспечения безопасного соединения между пользователем и сервером, рекомендуется использовать SSL-сертификат. Установите SSL-сертификат на сервере и настройте его для использования HTTPS протокола.

3. Аутентификация и авторизация:

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

4. Резервное копирование данных:

Не забудьте настроить регулярное резервное копирование данных вашего облачного хранилища. Создайте график резервного копирования и сохраните копии данных на внешних носителях или в удаленном облачном хранилище.

5. Обновление программного обеспечения:

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

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