Адміністрування NAS через VPN: збережіть ім'я, відмовтеся від публічного порту
Добирайтеся до сторінки адміністрування через тунель, а не через новий публічний порт. Розв'яжіть справжнє ім'я, узгодьте з ним сертифікат і дозвольте одну службу з одного джерела.
Сторінка адміністрування NAS працює вдома і перестає працювати тієї миті, коли адміністратор вирушає в дорогу, тож хтось відкриває порт, і проблема зникає разом із приватністю. Для цього є краща форма. Залиште сторінку там, де вона є, нехай тунель забезпечує доступність, а те, що ви документуєте, робіть повним URL з іменованим шляхом дозволу, а не адресою пристрою, який випадково відповідає. Кожне рішення нижче, від імені до сертифіката й єдиного дозволеного порту, випливає з такого запису.
Одиниця проєктування — URL, а не адреса
Запишіть точку входу як повний URL з його портом і схемою, потім додайте умови: кому можна ним користуватися, з якої мережі та яким шляхом. Прикладом може бути https://nas.corp.example:8443, опублікований лише для схвалених приватних клієнтів, де ім'я та порт замінюють те, що пристрій насправді слухає.
Така схема змушує ухвалювати рішення рано. URL передбачає ім'я, ім'я передбачає сертифікат, а сертифікат передбачає домовленість про довіру. Адреса не передбачає нічого з цього, і саме тому версія лише з адресою живе до першого попередження браузера, а потім перетворюється на звичку проскакувати його.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Збережіть ім'я, для якого видано сертифікат
Клієнту потрібен дозволений маршрут до приватної адреси NAS, і приватна схема DNS може розв'язати потрібне ім'я хоста в цю адресу, зберігаючи ім'я, якого очікує служба HTTPS. Обидві половини важливі: маршрут доставляє пакети туди, ім'я повідомляє клієнту, яку особу перевіряти.
Якщо ввести натомість числову адресу, вимога до особи змінюється. RFC 9525 розділяє ім'я, з яким клієнт має намір зв'язатися, і особу, яку представляє служба, тож сертифікат, виданий для nas.corp.example, може законно не пройти, коли браузер було спрямовано на 10.20.0.15. Попередження правильне, і виправлення — це ім'я, а не виняток.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleВиконайте обидві команди, перш ніж звинувачувати тунель. Перша показує, чи розв'язується приватне ім'я там, де ви думаєте, а друга — який сертифікат і які альтернативні імена суб'єкта служба насправді представляє. Приватний CA може бути цілком добре керованим вибором; звичкою не має ставати навчання людей ігнорувати попередження про особу.
Обмежте шлях керування
Дозвольте саме службу керування з потрібного джерела — і на шлюзі, і на NAS. Ця фраза приховує деталь, яка кусає: пул маршрутизованих клієнтів і шлюз із трансляцією джерела приходять на NAS з різними адресами джерела, тож правило дозволу, написане для одного, мовчки не спрацьовує для іншого.
NAS потрібен і зворотний шлях, а браузер має використовувати налаштовані порт і схему, а не типове значення виробника з допису на форумі. Дістатися пристрою — не дозвіл діставатися кожного його порту. Розрив між пристроєм, що відповідає на ping, і сторінкою адміністрування, що завантажується, — це розрив між двома окремими правилами. Запишіть їх як два правила з двома коментарями, щоб наступна людина бачила, чому існують обидва.
Відокремте допуск у VPN від привілеїв NAS
Бути пропущеним через тунель — не те саме, що мати право адмініструвати пристрій. Користувач, якому законно потрібне файлове сховище, не повинен успадковувати адміністрування пристрою лише тому, що обидва живуть за одним шлюзом, і модель облікових записів NAS — це місце, де таке розділення має забезпечуватися.
Спільна або трансльована адреса виходу теж не може ідентифікувати окремого адміністратора. Якщо журнал аудиту має назвати людину, особа має походити з автентифікованого облікового запису, а не з адреси джерела тунелю, яким користуються багато людей.
Що не варто публікувати випадково
Публічний зворотний проксі та ретранслятор виробника — обидві реальні архітектури, і кожна несе власні рішення про довіру та експозицію. Жодна не стає потрібною через те, що адміністратор далеко від дому, і жодна не повинна з'являтися як побічний ефект оприлюднення медіасервера чи файлового ресурсу.
Задокументуйте чотири речі й зупиніться: приватне ім'я, прослуховувач, на який воно відображається, групу, якій дозволено ним користуватися, і шлях відновлення, якщо тунель недоступний. Ці чотири також відповідають на питання, які поставить розбір інциденту, чого не можна сказати про знімок екрана сторінки переспрямування портів. У підсумку у вас одна стабільна адміністративна точка входу, а не пристрій, кожна функція якого дивиться в інтернет.