В составе продуктов ГК Астра существуют готовые решения, реализующие удаленный доступ, например:

  • Termidesk VDI — готовое решение для развертывание инфраструктуры удаленных рабочих столов. Хорошо подходит для организации рабочих мест удаленных сотрудников, но не подходит для целей удаленного доступа к реальным машинам.
  • ALD Pro — уже включает в себя Подсистему удаленного рабочего стола. Удаленное подключение реализуется по протоколу VNC через веб-интерфейс контроллера домена. Так как для подключения используется VNC, то подключение происходит к уже существующей пользовательской сессии, по одноразовому парою, генерируемому специальной утилитой "Удаленный рабочий стол ALD Pro". Вполне подоходит для целей оказания технической поддержки и удаленного администрирования (в совокупности с поилитиками ALD).

Однако существуют и другие варианты — организация удаленного доступа с использованем штатных средств самой Астры (доступных из "родных" репозиториев). Хорошая обзорная статься по удаленным графическим интерфейсам есть на официальной странице Wiki: рассмотрен проброс X11 серез SSH, XDMCP, VNC и RDP. Именно последний вариант хотелось бы рассмотреть подробнее, как один из наболее компромиссных между удобством настройки, удобством использования и безопасностью.

RDP — протокол удаленного доступа, работающий на уровне сессий и позволяющий осуществлять одно- или двунаправленную передачу аудио- и видеопотоков, буфера обмена, локальный ресурсов, принтеров, USB-устройств и т.д.

Обычно поднятие RDP на Linux-хостах осуществляется с помощью пакета xrdp, открытой реализацией сервера RDP. До некоторого времени данный способ был стандартом де-факто и для Astra Linux SE.

Однако начиная с очередного обновления 1.8 и оперативного обновления 1.7.6 в состав основного репозитория вошел пакет fly-dm-rdp, расширяющий функционал fly-dm до поддержки создания локальных сессий по протоколу RDP (оф. статья). Стоит отметить, что в качестве RDP-сервера по-прежнему используется xrdp.

Применение же fly-dm-rdp имеет ряд некоторых преимуществ, в частности непрерывность и возможность подключения к одной сессии как с локальной машины, так и удаленно (ранее локальная сессия создавалась fly-dm через X11 и подключиться к ней же по RDP (как, например, в Windows) было бы невозможно), а также автоматическую блокировку неактуального подключения (например, при удаленном подключении к сессии с действующим локальным подключением).

Локальная сессия по RDP

Настройки локального входа по RDP

При использовании сессий RDP для локального входа не будет поддерживаться автоматический вход пользователей после загрузки ОС.

  1. Установить пакет fly-dm-rdp

    # apt update
    # apt install fly-dm-rdp
  2. Отредактировать конфигурационный файл /etc/X11/fly-dm/fly-dmrc, заменить в секции [General] значение параметра DefaultSession на fly-rdp-local.

    ...
    [General]
    ...
    DefaultSession=fly-rdp-local 
    ...
  3. Для применения настроек к пользователям, ранее выполнявшим вход на устройстве, удалить конфигурационный файл .dmrc в домашней директории пользователя. Или просто выполнить (для всех пользователей):

    # rm /home/*/.dmrc
  4. Перезагрузить устройство и проверить, что локальная сессия полнялась по RDP:

    echo $DISPLAY

    В стандартной локальной сессии вывод будет иметь вид :0, в сессии RDP — :10.0.

В случае, если не работает повторное подключение к сесии по RDP, то в конфигурационном файле /etc/xrdp/xrdp.ini параметру fork необходимо устаовить значение true и перезапустить службу xrdp.

Исправление санкций Polkit

Отдельно стоит отметить, что сессия, поднимаемая при локальном подключении, технически все равно будет считаться удаленной, что может вызвать некоторые расхождения с санкциями по умолчанию PolicyKit-1 (вообще, про систему Polkit можно почитать здесь). Таким образом, в зависимости от очередного и оперативного обновления может возникнуть ряд проблем с выполнением действий, требующих административных привилегий.

Например, может перестать функционировать редактирование соединения через графическую оснастку NetworkManager (nm-connection-editor). Для исправления потребуется откорректировать соответствующую политику:

  1. Изменить в файле /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla значение ResultAny=no на ResultAny=yes;
  2. Перейти в Меню "Пуск""Параметры""Управление доступом""Санкции PolicyKit-1";
  3. Найти политику Connection sharing via a protected Wi-Fi network;
  4. Указать для параметра Удаленная сессия значение Разрешить;
  5. Перезапустить nm-connection-editor:
    sudo systemctl restart NetworkManager

Настройка санкции Polkit для NetworkManager

В ALSE 1.8 могут также возникнуть проблемы с самой Панелью управления: для действий, требующих административных привилегий, не будет работать их повышение.

Ошибка повышения привилегий в Панеле управления

Лечится это по аналогии редактированием соответствующих санкций. Для следующих санкций (название может несколько отличаться для разных оперативных обновлений) для параметра Удаленная сессия необходимо установить значение, аналогичное параметру Активная консоль.

  • ru.astralinux -> kcm -> Astra common security settings control -> Common access to security settings;
  • ru.astralinux -> kcm -> Astra common settings control -> List directory;
  • ru.astralinux -> kcm -> KCModule Systems Parameters Helper -> Reading States Parameters;
  • ru.astralinux -> kcm -> KCModule Systems Parameters Helper -> Apply Changes.

Таким же образом могут быть исправлены и другие обнаруживаемые проблемы, связанные с повышением привилегий.

При этом при запуске утилиты, требующей повышения привилегий, через механизмы sudo или su санкции PolicyKit применяться не будут.

Previous Post Next Post