Компьютер с Windows 7 Pro не выходит из локальной сети через пакет Magic Packet из внешней сети
Я только что купил новый компьютер под управлением Windows 7 Professional x64. Я хотел бы сэкономить электроэнергию, поспав через час, но я также хотел бы иметь возможность использовать удаленный рабочий стол на досуге.
Я настроил статический IP и настроил переадресацию портов на маршрутизаторе. Если компьютер не спит, RDP-соединение работает просто отлично.
Я скачал и установил Wake-On-LAN благодаря этой статье
Если я уложу свой новый компьютер в спящий режим и отправлю волшебный пакет со своего старого компьютера в мою домашнюю сеть, он проснется. Однако если я делаю то же самое со своего рабочего компьютера за пределами сети, это не так.
Я полагал, что брандмауэр блокирует входящий трафик, но ничто в журналах брандмауэра Windows не указывает на это.
Мне интересно, есть ли у кого-нибудь какие-либо предложения или какие-либо тесты, которые я могу пройти, чтобы сузить проблему.
6 ответов
У меня была такая же проблема, как и у вас, и я использовал веб-страницу на своем сервере для отправки волшебного пакета.
Я использовал код и WolAsp.dll от Depicus:
Функция Wake On Lan для активных страниц сервера позволяет любому веб-браузеру IIS с интерпретатором ASP отправлять пакет Magic Packet на удаленный компьютер.
С их страницы часто задаваемых вопросов:
Проснись на Лане через Интернет (или почему это такая боль в ****)
"IP-широковещательные рассылки используются в очень распространенной и популярной атаке типа" отказ в обслуживании ", а также могут использоваться в связанных атаках.
IP-трансляция - это датаграмма, которая отправляется на широковещательный адрес подсети, к которой аппарат-отправитель не подключен напрямую. Направленная широковещательная рассылка направляется через сеть в виде одноадресного пакета до тех пор, пока не поступит в целевую подсеть, где она преобразуется в широковещательную рассылку на канальном уровне. Из-за особенностей архитектуры IP-адресации только последний маршрутизатор в цепочке, тот, который подключен непосредственно к целевой подсети, может окончательно идентифицировать направленную широковещательную рассылку. Направленные передачи иногда используются в законных целях, но такое использование не распространено за пределами индустрии финансовых услуг.
При атаке "smurf" злоумышленник отправляет эхо-запросы ICMP с фальсифицированного адреса источника на адрес направленного широковещания, в результате чего все хосты в целевой подсети отправляют ответы фальсифицированному источнику. Посылая непрерывный поток таких запросов, злоумышленник может создать гораздо больший поток ответов, который может полностью затопить хост, чей адрес фальсифицируется.
Если интерфейс Cisco сконфигурирован с помощью команды no ip dire-broadcast, вместо этого направленные широковещательные рассылки, которые в противном случае были бы "разбиты" на широковещательные рассылки на этом интерфейсе. Обратите внимание, что это означает, что на каждом интерфейсе каждого маршрутизатора, который может быть подключен к целевой подсети, не нужно настраивать направленную широковещательную рассылку ip; недостаточно настроить только маршрутизаторы брандмауэра. Команда no ipcted-broadcast используется по умолчанию в ПО Cisco IOS версии 12.0 и выше. В более ранних версиях команда должна применяться к каждому интерфейсу локальной сети, который не предназначен для пересылки законных направленных трансляций ".
Цитируется из Cisco.
Интересно, если где-нибудь на линии, пакет заблокирован. Вы можете попробовать WoL Depicus на интернет-странице и посмотреть, попадет ли пакет на ваш компьютер.
Проблема здесь в том, что после того, как ваш компьютер был в автономном режиме в течение более длительного времени (5-10 минут?), Mac-адрес удаляется из кэша arp, и между mac- и ip-адресом нет никакой связи.
Таким образом, единственный способ разбудить ваш компьютер - это отправить широковещательное сообщение. Это не проблема в локальной сети, но напрямую через Интернет это невозможно.
Что вам нужно сделать, это перенаправить порт на ip ...255, который является широковещательным ip по умолчанию.
На моем D-Link DIR655 кажется, что portforward не работает, но виртуальный сервер работает... (Что то же самое)? Более подробная информация здесь: http://forums.dlink.com/index.php?PHPSESSID=78ba918bee8de38323a22f203df16195&topic=5934.15
Ваш маршрутизатор должен быть настроен на прием и пересылку этих пакетов. Если вы не сделаете этого, трафик не сможет попасть извне на спящий компьютер изнутри.
На самом деле делать это или нет - решать вам. Переадресация трафика имеет некоторые риски.
Основные шаги:
- Перенаправьте порт UPD 7 или 9 на IP-адрес нужного компьютера WOL. Какой порт вам нужно использовать, будет зависеть от используемого вами WOL-клиента. Если клиент это разрешит, вы, вероятно, можете использовать любой случайный порт с высоким номером.
- Если вы находитесь в нескольких частных сетях, вам может потребоваться добавить статическую запись ARP вашего компьютера WOL с FF:FF:FF:FF:FF:FF для MAC. Это должно позволить ему пересылать между коммутаторами.
Другая вещь, которую вы можете сделать, это установить DD-WRT на ваш роутер, если он совместим. Это позволит вам использовать маршрутизатор в качестве клиента WOL, и вы можете просто подключиться к нему через telnet и выполнить соответствующие команды.
Отличный документ от DD-WRT, (и где я нашел всю эту информацию) ==> DD-WRT WOL Page
Вместо всего этого - вы можете попробовать Диспетчер устройств - разверните Сетевые адаптеры - Свойства используемого вами сетевого контроллера - затем перейдите на вкладку "Управление питанием" - и ОТКЛЮЧИТЕ опцию, позволяющую ТОЛЬКО пакету Magic выводить компьютер из спящего режима. ОК ОК ОК - тогда тестируйте. Этот сценарий (отключение требования только для Magic Packet, чтобы разбудить ПК) работает в нашем случае. Следует помнить одну вещь - иногда при установке подключения к удаленному рабочему столу, когда компьютер спит, - при первой попытке RDP произойдет сбой, НО он разбудит ПК. Второй раз попробуешь - подключится просто отлично. Пинг не работает, когда ПК спит. Это для настольных ПК HP 6000pro и не уверен, будет ли это исправлено в будущем с помощью исправлений ОС или обновлений драйверов сетевой карты.
По-прежнему не удается выяснить, почему ПК не проснется, если через пару часов перейдет в спящий режим, а не в спящий режим.
Я предполагаю, что ваш маршрутизатор / NAT блокирует волшебный пакет. Волшебный пакет должен быть адресован широковещательному адресу, ваш NAT-блок либо заблокирует его, либо, если у вас есть порт переадресации, вы, возможно, отправили его на определенный адрес, а не широковещательный адрес. Если это так, то вы можете попробовать изменить порт вперед, чтобы он отправлялся на широковещательный адрес вашей локальной сети.
Я не удивлюсь, если вы просто не можете заставить свой домашний маршрутизатор правильно пересылать волшебный пакет. Если это так, то вам понадобится какая-то форма постоянного включения в вашу локальную сеть. Это может быть ваш роутер, если вы можете сменить его прошивку на что-то, что поддерживает это, или меньший ПК, который вы всегда можете оставить включенным. Вы даже можете получить / написать небольшое приложение, которое всегда будет работать на ПК, прислушиваясь к определенной команде, и когда оно получит ее, оно может отправить правильный магический пакет для вас.
Насколько я понимаю, Wake on LAN работает только в том случае, если волшебный пакет отправляется на широковещательный адрес из той же подсети, что и машина, которую вы хотите разбудить. Исходя из этого, мне любопытно, будет ли решение включать дополнительный компьютер, который будет "посредником", который отправляет пакет от вашего имени.
У меня есть только неподтвержденные доказательства, чтобы проверить. Я хотел сделать то же самое с нашими тестовыми машинами на работе; иногда их усыпляют, и пробуждение по локальной сети было бы идеальным. Я никогда не мог разбудить тестовую машину с моей машины разработки, но успешно разбудил тестовые машины с других тестовых машин. Я мог убедиться, что тестовые машины получали пакеты, но они не выходили из моей машины. В конце концов я сдался и предположил, что, поскольку моя машина разработки и тестовые машины находились в разных частных сетях, это было бы невозможно реализовать.