Чи може VPN замінити віддалений робочий стіл? Що робить кожен із них

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

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

Симптом залежить від того, де виконується застосунок

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

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

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

Продуктивність визначається навантаженням, а не назвою

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

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

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

Коли щось відмовляє, перевіряйте кожен рівень окремо

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

Test-NetConnection -ComputerName 172.20.8.30 -Port 3389
Resolve-DnsName workstation-14.corp.example
qwinsta /server:172.20.8.30

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

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

Вирішіть, що має залишатися всередині організації

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

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

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