Администриране на 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 е мястото, където това разделение трябва да се наложи.
Споделен или транслатиран изходен адрес също не може да идентифицира отделен администратор. Ако одитната следа трябва да назове човек, самоличността трябва да идва от удостоверен акаунт, а не от адреса на източника на тунел, който много хора използват.
Какво да не публикувате случайно
Публичният обратен прокси и релето на доставчика са и двете реални архитектури и всяка носи свои собствени решения за доверие и експозиция. Нито едно от тях не става необходимо, защото администраторът е далеч от дома, и нито едно не бива да се появява като страничен ефект от излагането на медиен сървър или файлово споделяне.
Документирайте четири неща и спрете: частното име, слушателя, към който се съпоставя, групата, на която е разрешено да го използва, и пътя за възстановяване, ако тунелът е недостъпен. Тези четири отговарят и на въпросите, които ще зададе прегледът на инцидент, което не е вярно за екранна снимка на страница за пренасочване на порт. Това, което получавате, е една стабилна административна входна точка, а не устройство, чиято всяка функция гледа към интернет.