Отдалечен работен плот през 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 за достъп до отдалечен работен плот отвън описва поддържаните варианти за излагане и е по-добра справка от публичен слушател, добавен под натиск.