Удаленный рабочий стол * с * Windows 2008 R2 Server

Описание: как создать соединение RDC с сервера Windows 2008 на другой сервер?

Наш клиент позволит нам подключаться к его серверу только через статический IP-адрес (что вполне справедливо), но, к сожалению, поскольку мы очень маленькая компания, у нас ее нет в офисе.

Как обходной путь, у нас было соединение, работающее через наш старый сервер Windows 2003 ( динамическое облако от 1and1). ... однако мы только что перестроили сервер для работы под Windows 2008 R2 (не спрашивайте, но это было необходимо), и теперь я просто не могу установить соединение.

  • Я добавил "Исходящее правило" в брандмауэр Windows в режиме повышенной безопасности (TCP, все локальные порты, удаленный порт 3389 - я также пробовал наоборот).

  • Я добавил правило IP-безопасности фильтра пакетов с теми же подробностями.

  • Правила брандмауэра 1 и 1 (через онлайн-панель управления) позволяют использовать 3389 TCP и UDP.

Но он просто не подключается (да, сервер определенно включен и может принимать подключения) с общей ошибкой. ..

Удаленный рабочий стол не может подключиться к удаленному компьютеру по одной из следующих причин:
1) Удаленный доступ к серверу не включен
2) Удаленный компьютер выключен
3) Удаленный компьютер недоступен в сети

Есть ли что-то очевидное, что я пропустил - или что-то, что я могу использовать, чтобы узнать, где блокируется запрос? Новый сервер использует тот же IP-адрес, что и раньше, поэтому я не думаю, что это будет проблемой. Разве он пытается использовать адрес IPv6, а не старый адрес IPv4, который был раньше?

Я прошу прощения, что я не сетевой человек по профессии, но я знаю больше, чем кто-либо еще в моем офисе!


редактировать

Я временно остановил брандмауэр Windows (через netsh firewall set opmode disable) и IPSec (через net stop "ipsec policy agent"), но все равно не подключается.

У меня заканчиваются идеи


Редактировать 2

Может показаться, что я не отключил ipsec должным образом (или, если я это сделал, должно быть, что-то автоматически включило его снова).

Если я отключу Block All опция в IPSec, после чего соединение начинает работать. Я попытался найти любую документацию, в которой указан порядок приоритета, но, поскольку я не вижу способа изменить порядок правил безопасности в диалоговом окне, я должен предположить, что Permit Переопределение Block,

Однако, это все еще не имеет смысла для меня, поскольку я специально добавил Разрешение для TCP 3389, которое не работает. Я ненавижу компьютеры!!


Редактировать 3

Мой друг (который является сетевым администратором в компании среднего размера) взглянул на конфигурацию и также не может объяснить, что происходит. .. Я рад, что это не только я!

Его единственные мысли по этому вопросу связаны с Kerberos метод аутентификации, и может ли это иметь эффект. К сожалению, он не смог понять, как именно вы обойдете его, не начав использовать SSL-сертификаты.

На данный момент я нахожусь в ситуации, когда я должен временно отключить Block All правило в списке правил IP-безопасности - подключитесь к соответствующему клиенту - и после завершения снова включите block all, Ни в коем случае не идеал, но если кто-то еще не может дать ответ, это единственное, что у меня есть.

(Еще одно предложение, которое он предложил, - полностью удалить безопасность IPSec и вместо этого просто использовать брандмауэр Windows. Это хорошая идея?)

2 ответа

Решение

Чтобы ответить на мой собственный вопрос... Я просто не выяснил причину, по которой IPSec блокирует RDC (и позже я обнаружил также FTP). Я прошел через все настройки, о которых мне приходилось думать, столько раз я терял счет - но все они выглядят хорошо.

Теперь я отключил (не отмечен) Block All элемент в IPSec, и теперь все работает как положено.

Является ли это дырой в безопасности, которую я только что открыл, я действительно не уверен. Или есть ли какая-либо точка, у которой вообще включен IPSec, если Block All выключен.

Но поскольку брандмауэр Windows в режиме повышенной безопасности настроен и работает, а настройка брандмауэра на панели управления 1and1 также существует, я надеюсь, что этого достаточно для обеспечения хорошего уровня защиты.

Первое, что вы должны сделать, это выполнить traceroute сервер вашего клиента, чтобы определить, действительно ли пакеты выходят из сети, принадлежащей компании, на которой вы пытаетесь подключиться к облачному серверу.

К сожалению, поскольку ваш клиент решил заблокировать ICMP Echo, будет сложно определить, в чем заключается проблема.

У вашего клиента есть свои админы? Если это так, как только вы установили, что пакеты попадают (или близко) в их сеть, вам следует поговорить с ними.

Другие вопросы по тегам