Администрирование 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 — это место, где такое разделение должно обеспечиваться.
Общий или транслированный адрес выхода тоже не может идентифицировать отдельного администратора. Если журнал аудита должен назвать человека, личность должна приходить из аутентифицированной учётной записи, а не из адреса источника туннеля, которым пользуются многие.
Что не стоит публиковать случайно
Публичный обратный прокси и ретранслятор производителя — обе реальные архитектуры, и каждая несёт свои решения о доверии и экспозиции. Ни одна не становится необходимой из-за того, что администратор вдали от дома, и ни одна не должна появляться как побочный эффект публикации медиасервера или файлового ресурса.
Задокументируйте четыре вещи и остановитесь: частное имя, прослушиватель, на который оно отображается, группу, которой разрешено им пользоваться, и путь восстановления, если туннель недоступен. Эти четыре также отвечают на вопросы, которые задаст разбор инцидента, чего нельзя сказать о снимке экрана страницы перенаправления портов. В итоге у вас одна стабильная административная точка входа, а не устройство, каждая функция которого смотрит в интернет.