У меня проблемы с RDP от клиента Win 7 к коробке Win 7 на другой стороне сервера OpenVPN. Подключение от моего клиента Win 7 к XP box прекрасно работает.

На компьютерах назначения не требуется проверка подлинности на уровне сети (т. Е. Для них установлен параметр "менее безопасный"). Я удалил все посторонние функции RDP (принтеры, флэш-диски, звук, глубина цвета ... настолько низко, насколько я могу)

Я устанавливаю соединение OpenVPN из дома на работу, затем пытаюсь подключиться к RDP к компьютеру, например, PC2312332.example.com, и он зависает при configuring remote session . Я также могу пропинговать PC2312332.example.com из командной строки моего клиентского компьютера, и NSlookup любого сайта показывает, что мой DNS использует внутренний DNS-сервер моей работы, как и должно быть.

Теперь настоящий кикер: редко он заканчивает соединение и впускает вас. Иногда после пяти минут сидения на настройке. Тогда все будет работать нормально. Обычно даже позволяют восстановить соединение, если вы позволяете компьютеру переходить в спящий режим (и VPN-подключение необходимо восстановить. Может ли кто-нибудь помочь мне получить это работает надежно.

Я видел RDP поверх OpenVPN в Windows 8, но, похоже, он имеет дело с местом назначения, не позволяющим соединения в интерфейсе OpenVPN. В любом случае я отключил брандмауэры на компьютерах источника и назначения для устранения неполадок.

За пределами кампуса:

  • Win7 Client -> Win7 в кампусе = зависает при configuring remote session
  • Win7 Client -> XP в кампусе = Подключается очень быстро и с отличной производительностью

В кампусе:

  • Win7 Client -> Win7 в кампусе = очень быстро и с отличной производительностью
  • Win7 Client -> XP в кампусе = Подключается очень быстро и с отличной производительностью
|источник

3 ответа3

0

У меня те же замечания, что и выше, "вне кампуса", когда я получаю доступ к своим боксам win 7 / win xp извне, используя OpenVPN, то есть win xp работает, win 7 - нет. Я пытался отследить с WireShark, но безуспешно. Тем не менее, мое "решение" заключается в следующем: при удаленном взаимодействии сначала запустить процесс, который неоднократно пингует цель

Окна:

ping -t <target> 
mstsc ...

Linux:

ping <target> &
rdesktop [your options] <target>

Android:

ping <target> ( using any android shell app)
run aFreeRDP ( or any other app - I have tried a few with no probs )

В заключение, насколько я вижу, поддержание целевого соединения "живым" с помощью ping s позволяет избежать "зависания"/ тайм-аута соединения или чего бы то ни было. Как ни странно, я не смог проверить, что это действительно проблема, потому что ничего не регистрируется (ну, в любом случае, я ничего не смог найти).

Я хотел бы изучить "реальное" решение, но пока пинг удаленного хоста с другого процесса на локальной машине помогает мне.

|источник
0

Поиск в Google показывает, что это может быть связано с рядом проблем, связанных с настройками на стороне клиента.

В этой теме упоминается об изменении выбранных ресурсов, глубины цвета.

Этот вопрос и ответы Superuser также могут помочь.

НТН

|источник
0

У Йенса: - Это всего лишь мысль, но ..

обычно системные администраторы устанавливают некоторые списки доступа брандмауэра, чтобы разрешить подключение к целевому компьютеру RDP внутри ИТ-инфраструктуры, и .. правило iptables может выглядеть так:

-A VPN_%USER%_CHAIN% -d %RDP_TARGET_IP%/32 -p tcp -m tcp --dport 3389 -j ACCEPT

... - поскольку RDP обычно использует TCP. Но я где-то слышал, что в более новых системах Windows он переключается на UDP после создания сеанса.

Теперь, когда Дженс использует постоянный ICMP-пинг до того, как он начинает свое RDP-соединение, а ICMP основан на UDP, возможно, что RDP возвращается к использованию TCP, потому что UDP-соединение сетевого интерфейса в значительной степени используется через ICMP-пинг, и из-за если правило брандмауэра считает целесообразным пропустить TCP-соединение.

Поэтому, по крайней мере, неплохо использовать ping или ... попросить администратора добавить правило UDP iptables, например: 

-A VPN_%USER%_CHAIN% -d %RDP_TARGET_IP%/32 -p udp -m udp --dport 3389 -j ACCEPT

на сервере openVPN, а?

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .