Заранее извините, если этот вопрос немного новичок. Я загрузил Microsoft Connection Manager и добавил несколько .rdg файлы для разных серверов, к которым мне нужен доступ. Я могу просмотреть только некоторые из них, но при большинстве из них я получаю следующие ошибки:
Я проверил пароли и учетные данные, и они кажутся правильными (проверено по настройкам коллег). Я могу ping серверы и я получаем от них ответ, но не могу подключиться к ним через диспетчер подключений.
Кроме того, для двух серверов я могу перейти к ним в браузере (но не могу подключиться к ним в диспетчере подключений).
Поскольку я очень мало знаю о серверах и сетях, я хотел бы знать, как я могу исследовать это дальше и выяснить (и исправить), почему некоторые из них подключаются, а некоторые нет - тем более что я могу пинговать их, но не подключаться к их? Главное, что меня озадачивает, - это то, почему я могу просматривать их в браузере для некоторых серверов или пинговать их, когда они не могут быть подключены в диспетчере подключений.
Я видел несколько решений подобных проблем в сети, которые рекомендуют очистить стек TCP IP; но я не уверен, относится ли это к вышесказанному. Может ли это быть связано с разрешениями?
Что я могу сделать, чтобы исследовать / исправить эту проблему?
Тот факт, что вы можете проверить связь с системой или подключиться к ней через веб-браузер, не означает, что вы можете подключиться другими способами. Поскольку вы, как вы выразились, «новичок», я не буду объяснять это простым языком. Компьютеры используют определенные порты для связи с другими системами и для связи с их собственной системой. Службы запускаются на определенных портах, чтобы разрешить подключения с других компьютеров. Например, когда вы подключаетесь к Google.com, вы используете веб-браузер, который отправляет соединение с Google.com (подключение к Google) через порт 80 (Http) или 443 (Https). Я поместил туда К GOOGLE, потому что ваша система не использует порт 80 для отправки исходящего соединения, она подключается к GOOGLE через порт 80. В фоновом режиме происходит много других вещей (DNS, NAT и т. Д.) но я стараюсь сделать это как можно проще.
В зависимости от конфигурации сети, возможно, порт 80/443 (Http / Https) разрешен (брандмауэр, магистраль VLAN и т. Д.), Но 3389 (RDP) - нет. Возможно, сервер, на который вы пытаетесь подключиться по RDP, даже не разрешает подключения RDP (без прослушивания порта / службы). Может быть, это должно быть, но исключение не было добавлено в локальный брандмауэр этой системы или, возможно, был изменен стандартный порт 3389.
Существует множество факторов, но первое, что приходит на ум в моей рабочей среде, - это транкинг. У нас есть более 25 VLAN на нашем коммутаторе Cisco Catalyst 6513. Одна VLAN предназначена для общего пользования (студенты могут использовать системы), а другая - для управления. Каждая VLAN ограничена от другой при определенных условиях. Теперь я могу пинговать системы управления, но если бы я хотел подключиться через RDP, HTTP, SMTP, SSH и т. Д., Я бы не смог, потому что трафик на этих определенных портах не может быть передан в эти системы на другой VLAN. Транкинг также может быть направленным, т. Е. Из управляющей VLAN я могу подключиться к любой системе на любом порту, который я хочу (в общем), но из общего доступа разрешены только определенные виды трафика (21,22,80,443,135,137,445 и т. Д.) )
Во-первых, убедитесь, что система, в которую вы пытаетесь подключиться по RDP, прослушивает службу удаленного рабочего стола. После этого убедитесь, что в брандмауэре есть исключение, разрешающее подключения к этой службе. Определите, находитесь ли вы в одной подсети или нет. Могут ли другие люди использовать RDP на машине, на которую вы пытаетесь подключиться? Вы находитесь в той же подсети, что и люди, которые могут подключиться к этой системе?
Существует множество других факторов, но, если вы не знаете, в какой среде вы работаете, существуют различные факторы, которые могут быть проблемой. Перезапуск TCP / IP, стек Winsock может помочь, но вряд ли проблема. Это может быть просто ipconfig / release / Renew / flushdns, а может быть сложнее туннелирование трафика.
Загрузите Teamviewer на обе машины. Это бесплатно для личного использования. www.teamviewer.com, вы запускаете его на обеих машинах и, используя «свой идентификатор» на другой машине, вы можете соединить два компьютера, использовать их программы, Интернет и файлы. Вы найдете возможность передавать файлы в верхнем меню на экране. Укажите, где находится файл и куда вы хотите его переместить, выберите файл и отправьте его. Готово и сделано. Когда закончите, просто нажмите X в верхнем меню, и все готово.
Проблема здесь в том, что, хотя вы можете пинговать и трассировать между двумя машинами [окнами], ни одна машина не распознает другую вообще как-либо. Для меня это означает, что никакое программное обеспечение, способное работать с подключенными компьютерами, не работает. ИЛИ, нужные порты так или иначе блокируются. Уловка здесь состоит в том, чтобы приобрести какое-то полнодуплексное программное обеспечение, которое будет работать на обеих машинах и сможет распознавать причину отсутствия соединения или нераспознавания. Я не вижу никого, кто выпускает автономные программы для устранения неполадок в сети, предназначенные ТОЛЬКО для LAN [НЕ ИНТЕРНЕТ]. Он должен иметь собственные драйверы ETHERNET, независимые от операционной системы. Все, что я хочу сделать, это передавать файлы между двумя машинами, используя ETHERNET, и не могу найти простых в использовании программ, которые бы это сделали. CD / DVD / BRD / USB работают слишком медленно. Ethernet - безусловно, лучший способ сделать это. Я думаю, что большие парни намеренно затрудняют создание локальных сетей.