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 прибирає одну поверхню входу; він не робить зареєстрованого клієнта довіреним.