Nextcloud только через VPN: сначала опишите все входы

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

Пройдите контрольный список по порядку. Первый пункт определяет, что значит приватный для этого развёртывания; следующие пункты проверяют, действительно ли развёртывание соответствует этому определению.

Определите приватное, прежде чем менять периметр

Запишите требование одним предложением: каждый пользователь должен подключиться к VPN, прежде чем добраться до приложения, либо приложение может оставаться публичным, пока его источник остаётся приватным. Это разные проекты, и публичный обратный прокси, передающий в приватный туннель, удовлетворяет только второму.

Приватный адрес backend не делает приложение приватным. Если публичное сопоставление, второе имя хоста или IPv6-слушатель всё ещё достигают того же экземпляра Nextcloud, вход существует независимо от того, где находится backend. Проверьте каждое имя снаружи, прежде чем объявлять сервис приватным. Отсутствующая запись DNS не то же самое, что закрытый порт.

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

Опишите каждый вход и каждое имя

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

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

Затем заблокируйте входы, которые вы не выбрали. Приватный backend с публичным фронтендом — это не схема только через VPN, а правило брандмауэра, покрывающее только IPv4, оставляет IPv6-слушатель открытым. Закройте оба семейства и оба имени в одном изменении.

Дайте каждому клиенту одно имя сервиса

Направьте приватный DNS на сервис, проведите это имя через VPN и выпустите для него сертификат. Имя должно разрешаться через приватный путь и проверяться без предупреждения. Клиенту, который обращается прямо к IP, всё равно нужно работающее имя.

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

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

Ограничьте сетевой доступ, а не всю локальную сеть

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

Доступ через VPN не заменяет учётные записи, разрешения или дополнительную аутентификацию Nextcloud. Приложение по-прежнему решает, какой пользователь может читать какой файл, и сетевой уровень не должен быть единственным контролем.

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

Просмотрите каждый рабочий процесс вне браузера

Синхронизация на компьютере и мобильные загрузки открывают собственные соединения в своё время. Им нужен утверждённый приватный путь при подключении, и они могут вести себя иначе при отсутствии VPN: повторять попытку, приостанавливаться или показывать ошибку. Проверьте каждый из них, а не только браузер.

Инструменты WebDAV и клиенты календаря или контактов — отдельные интеграции со своей конфигурацией. Клиент, кэширующий публичный URL, продолжает пытаться использовать этот URL после изменения периметра, и сбой выглядит как проблема приложения.

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

Федерация и интеграции сервер-сервер требуют такого же подхода. Это отношения достижимости между установками, и развёртывание только приватное должно сказать, поддерживаются ли они.

Примите и разрешённый, и отклонённый случай

С одобренного клиента проверьте веб-интерфейс и обычную загрузку или скачивание файла. Затем проверьте клиент синхронизации и один рабочий процесс вне браузера. Успех только в браузере не является приёмкой.

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

Наконец, просмотрите настройки приложения, которые легко спутать с сетевой политикой. trusted_domains перечисляет имена, которые принимает экземпляр; это не список разрешённых IP клиентов. Если обратный прокси предоставляет сведения об адресе, trusted_proxies должен указывать фактический прокси, и переданные заголовки следует принимать только от него.

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