Администраторский доступ с нескольких хостов
Системы хранения NetApp позволяют ограничить доступ к админской консоли, задав IP-адрес админского хоста либо при установке, либо в параметре admin.hosts
Однако, иногда хотелось бы задать не один конкретный адрес, а подсеть, или несколько адресов.
В этом случае возможен следующий простой трюк. Можно указать в качестве админхоста gateway соответствующей подсети, например в которой находятся рабочие места админов. В этом случае доступ будет ограничен только хостами указанной подсети:
fas1> options admin.hosts 192.168.1.254
Другой вариант – указать их в таком виде:
fas1> options admin.hosts host1.domain.com:host2.domain.com:host3.domain.com
Не забывайте, что это ограничение предельно примитивное, и строить защиту админского доступа только на нем не стоит, так как определяет возможность доступа к логину консоли исключительно по легко изменяемому IP источника. Если стоит задача серьезного разграничения доступа, то стоит использовать как “секурный” доступ по SSH и HTTPS (команда secureadmin), pre-shared key, и средства RBAC (Role-based Access Control), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.
А в чём разница с документированной опцией trusted.hosts?
trusted.hosts
Specifies up to 5 clients that will be allowed telnet, rsh, and administrative HTTP (i.e. FilerView)access to the server.
Я имел в виду принципиальную разницу - есть документированная опция trusted.hosts, поддерживается в том числе System Manager-ом. ?? есть недокументированная “deleted” опция вроде бы с тем же функционалом. Зачем её использовать?
Вообще как эта опция работать-то должна? Как вообще получается, что она шлюз воспринимает в качестве адреса? Адреса не из её подсети работать не будут, потому что она видит шлюз? Вообще как это согласуется с tcp/ip - какое отношение имеет шлюз к пакету? он с точки зрения tcp/ip вообще прозрачен - пакет приходит от исходного адреса - никаких шлюзов в пакете не отмечается. Как система узнаёт, из какого шлюза пришёл пакет? reverse arp? из своей таблицы _исходящего_ роутинга?
Вы уверены, что вы (или Mohit Garg? ;) не перепутали gateway и proxy server? Трюк с proxy будет работать и с trusted.hosts, более того, из-за настройки прокси-сервера казалось бы допустимый хост может не пускать в админку, потому что он через прокси лезет (особенный казус с System Manager-ом, которому пишут имя хоста, а он его резолвит и лезет по ip).
Что касается trusted.hosts, то практика показывает, что как минимум список из 6 хостов вполне работает, а если уж нужен более гибкий инструмент - то “option *.access” (na_protocolaccess) позволяет гибче некуда конфигурировать доступ вполне документированным и современным способом.