Віддалений робочий стіл через VPN: на якій стадії збою ви перебуваєте?

Ваш тунель активний, внутрішня вікі завантажується, а віддалений робочий стіл досі відмовляється підключатися. Така комбінація нормальна, бо VPN дає маршрут до хоста, тоді як служба робочого столу має слухати, бути дозволеною власним брандмауером і бути готовою автентифікувати обліковий запис. Між робочим тунелем і придатним сеансом стоять чотири стадії збою, і кожна завершується іншим повідомленням. Спершу прочитайте повідомлення, бо воно називає стадію.

Чотири збої, які виглядають як один

Стадії впорядковані: ім'я розв'язується в приватну адресу, яку передбачає проєкт, порт відповідає на рукостискання TCP, хост приймає з'єднання за своєю політикою, а вхід у сеанс успішний. Кожна стадія робить наступну неперевірюваною, тому зміна налаштувань RDP до того, як мережа залагоджена, дає лише шум. Симптом з боку користувача виглядає однаково в усіх чотирьох випадках. Розділяє їх лише повідомлення клієнта.

Робочий внутрішній сайт не доводить жодної з чотирьох речей. Він доводить, що хост у тій самій мережі відповів на іншому порту іншою службою. Сприймайте це як доказ про маршрутизацію і не більше.

Перевіряйте по порядку і записуйте результат. Перескочити на екран входу через те, що порт відповів, — це спосіб витратити півдня на проблему брандмауера, яку перший крок уже локалізував.

Чи щось слухає на 3389?

Почніть з імені, бо ім'я, що розв'язується в неправильну адресу, знецінює кожну подальшу перевірку. Запитайте в резолвера тунелю, що означає ім'я, потім порівняйте відповідь із приватною адресою, яку передбачає проєкт, а не з успішною відповіддю. Ім'я, що розв'язується в публічну адресу, — це вся проблема, і жодна зміна RDP її не виправить:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Потім перевірте порт, а не хост. Завершене рукостискання TCP на 3389 відокремлює доступність від усього, що вище:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Виконайте цю перевірку з LAN і з тунелю, бо різниця між двома результатами локалізує несправність на шляху VPN. На шляху стоять два брандмауери, і їх легко переплутати: мережа має дозволяти адресі тунелю клієнта досягати хоста, а власний брандмауер хоста має дозволяти те саме джерело на слухаючому порту. Правило, обмежене підмережею LAN, не охоплює пул клієнтів VPN, і це найчастіша причина тайм-ауту, про який повідомляють лише віддалені користувачі. Перевірте область дії, а не існування правила.

Зворотний шлях заслуговує такої ж перевірки. Відповідям потрібен маршрут назад у пул клієнтів, а не в LAN, і трансляція перед хостом змінює джерело, яке покаже ваш журнал. Якщо порт відповідає в один бік і не відповідає в інший, відсутня половина зазвичай і є зворотним шляхом.

Прочитайте повідомлення раніше за конфігурацію

Третя стадія — хост відхиляє з'єднання за своєю політикою, що часто виглядає як порт, який одразу відкривається й закривається. Щось відповіло, і це корисна інформація, а не тиша. Якщо рукостискання завершилося, а сеанс помер одразу, мережа гаразд і вирішує хост. Подивіться дозволи віддаленого робочого столу, перш ніж знову торкатися мережі.

Функцію може бути ввімкнено для машини, але доступ обмежено певними групами, а слухач може бути прив'язаний так, що виключає адресу, з якої ви прийшли. Автентифікація на рівні мережі додає шлюз, який відмовляє до завантаження робочого столу, і текст його помилки відрізняється від неправильного пароля. Порівняйте повідомлення клієнта з журналом подій хоста, бо повідомлення називає шлюз, а журнал — обліковий запис.

Вхід у сеанс — окрема межа

Автентифікація належить службі робочого столу, а не VPN. Ідентичність тунелю й обліковий запис робочого столу — окремі дані з окремими політиками блокування, тому робочий тунель доводить лише те, що тунель вас прийняв. Блокування облікового запису робочого столу не заважає тунелю, і навпаки теж правильно.

Тримайте обидва цілими. Коли приватного маршруту немає, виправте маршрут, бо публікація слухача в інтернеті міняє помилку доступності на відкритий робочий стіл. Не послаблюйте й перевірки ідентичності сеансу, щоб обійти попередження про сертифікат, яке з'явилося одночасно. Самопідписаний сертифікат на слухачі RDP за задумом дає попередження, тож його прийняття — рішення, а не крок.

Порахуйте спроби перед повторенням. Пороги блокування робочого столу рахують невдалі входи окремо від збоїв VPN, і клієнт, що повторює за таймером, може перевищити поріг, поки ви ще редагуєте правило. Це той самий механізм паралельних повторів, який блокує облікові записи після зміни пароля.

Що сеанс може переміщати і де це залишається

Вивчіть затверджений порядок виходу до того, як він знадобиться. Закриття вікна може лише від'єднати подання, поки сеанс далі працює за своєю налаштованою політикою, що важливо на спільному або перевіреному хості. Виходьте зсередини сеансу, коли політика цього очікує.

Потім вирішіть, що сеанс може переносити, бо буфер обміну, переспрямовані диски, переспрямування принтера й передавання файлів переміщують дані між локальною та віддаленою системами там, де політика дозволяє. Опублікований застосунок, що працює на тому боці, не є автоматично межею без завантаження, а сеанс, що виглядає лише для читання, все одно може переносити буфер обміну. Перевіряйте реальне завдання, а не з'єднання: відкрийте файл, скористайтеся застосунком і підтвердьте потрібне переспрямування. Настанова Microsoft щодо доступу до віддаленого робочого столу ззовні описує підтримувані варіанти публікації, і це краще джерело, ніж публічний слухач, доданий під тиском.