Удалённый рабочий стол через 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 по доступу к удалённому рабочему столу извне описывает поддерживаемые варианты публикации, и это лучший источник, чем общедоступный слушатель, добавленный под давлением.