Плавающий отказ RDP · Блог "Дети ОИТа"

1. Определение ошибки

Краткое описание

На клиенте ALT Linux 10.4 наблюдается плавающая проблема с подключением по RDP через Remmina:

утром подключение к серверу по имени работает;
позже подключение к тому же серверу перестаёт работать;
при этом явных изменений на клиенте и сервере не вносилось.

Подозрение: проблема связана не с самим RDP-сервисом, а с DNS/DDNS/IPAM, когда один hostname может указывать на разные IP, либо имя и обратная запись расходятся. Для ALT Linux 10.4 это особенно важно, потому что сеть обычно управляется через NetworkManager, а настройки могут жить либо в /etc/net/ifaces/<интерфейс>, либо в /etc/NetworkManager/system-connections; содержимое /etc/resolv.conf может формироваться автоматически.

Типовой симптом

Проблема проявляется по имени узла, но может не проявляться по IP-адресу.

2. Возможные неполадки

Что может ломаться

Подключение Remmina к server01 уходит не на тот IP.
Один и тот же hostname в разное время резолвится по-разному.
На разных клиентах один и тот же hostname резолвится в разные IP.
PTR и A-запись не в порядке.
После смены IP у сервера старое имя или старая запись остаётся в DNS/IPAM.
Remmina/FreeRDP попадает на другой серверный сертификат или на другой хост. Для практической диагностики это удобно проверять и через Remmina, и через xfreerdp; оба клиента доступны в ветке p10 ALT Linux.

Практический эффект

Пользователь вводит правильное имя сервера, но фактически подключается не туда.
RDP «то работает, то нет».
На одном ПК подключение есть, на другом нет.
После обеда проблема появляется без изменений со стороны пользователя.
После очистки кэша или переподключения сеть «вдруг оживает».

3. Диагностика

Шаг 1. Проверка разрешения имени

# Несколько раз с интервалом
for i in {1..5}; do echo "--- $(date) ---"; dig +short server01; sleep 5; done

# Обратная запись
dig +short -x <IP>

# Локальный кэш
resolvectl status
resolvectl flush-caches

# NetworkManager
nmcli device show <интерфейс> | grep IP4.DNS

Шаг 2. Проверка Remmina/FreeRDP

# Прямое подключение по IP
xfreerdp /v:192.168.10.50 /u:user /p:pass

# По имени
xfreerdp /v:server01 /u:user /p:pass

# С логированием
xfreerdp /v:server01 /u:user /p:pass --log-level=DEBUG

Шаг 3. Сравнение с другими клиентами

Проверьте с Windows-клиента (mstsc)
Проверьте с другого Linux-дистрибутива
Проверьте с мобильного клиента

4. Решения

Решение 1. Исправить DNS/IPAM

Убедитесь что A и PTR записи согласованы
Удалите устаревшие записи
Настройте TTL адекватно (300-600 секунд для динамических сред)
Для ALT Linux убедитесь что NetworkManager не конфликтует с локальными resolv-файлами

Решение 2. Локальные хосты как временное решение

echo "192.168.10.50 server01" | sudo tee -a /etc/hosts

Решение 3. Фиксированный IP в Remmina

Сохраните профиль с IP вместо имени
Используйте разные профили для разных IP

Решение 4. Мониторинг

# Простой watch
watch -n 5 'dig +short server01'

# В логах
journalctl -u NetworkManager -f

5. Профилактика

Регулярно аудит DNS/IPAM
Автоматизация очистки устаревших записей
Мониторинг согласованности A/PTR
Для ALT Linux: централизованное управление сетью через Role-объекты

6. Хештеги

#RDP #Remmina #ALT_Linux #DNS #NetworkManager #диагностика #сети #troubleshooting