Компьютер с Windows 7 Pro не выходит из локальной сети через пакет Magic Packet из внешней сети

У меня была такая же проблема, как и у вас, и я использовал веб-страницу на своем сервере для отправки волшебного пакета.

Я использовал код и WolAsp.dll от Depicus :

Функция Wake On Lan для активных страниц сервера позволяет любому веб-браузеру IIS с интерпретатором ASP отправлять пакет Magic Pack на удаленную машину.

С их страницы часто задаваемых вопросов:

Разбуди на Лане через Интернет (или почему это такая боль в ****)

«IP-широковещательные рассылки используются в очень распространенной и популярной атаке типа« отказ в обслуживании »и могут также использоваться в связанных атаках.

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

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

Если интерфейс Cisco сконфигурирован с помощью команды no ip dire-broadcast, вместо этого направленные широковещательные рассылки, которые в противном случае были бы «разбиты» на широковещательные рассылки на этом интерфейсе. Обратите внимание, что это означает, что на каждом интерфейсе каждого маршрутизатора, который может быть подключен к целевой подсети, не нужно настраивать направленную широковещательную рассылку ip; недостаточно настроить только маршрутизаторы брандмауэра. Команда no ipcted-broadcast используется по умолчанию в ПО Cisco IOS версии 12.0 и более поздних. В более ранних версиях команда должна применяться к каждому интерфейсу локальной сети, который не предназначен для пересылки законных направленных трансляций ».

Цитируется по Cisco.

Интересно, если где-нибудь на линии, пакет заблокирован. Вы можете попробовать WoL Depicus на интернет-странице и посмотреть, попадет ли пакет на ваш компьютер.

Вместо всего этого - вы можете попробовать Диспетчер устройств - разверните Сетевые адаптеры - Свойства используемого вами сетевого контроллера - затем перейдите на вкладку «Управление питанием» - и ОТКЛЮЧИТЕ опцию, позволяющую ТОЛЬКО пакету Magic выводить компьютер из спящего режима. ОК ОК ОК - тогда тестируйте. Этот сценарий (отключение требования только для Magic Packet, чтобы разбудить ПК) работает в нашем случае. Следует помнить одну вещь - иногда при установке подключения к удаленному рабочему столу, когда компьютер спит, - при первой попытке RDP произойдет сбой, НО он разбудит ПК. Второй раз попробуешь - подключится просто отлично. Пинг не работает, пока ПК спит. Это для настольных ПК HP 6000pro и не уверен, будет ли это исправлено в будущем с помощью исправлений ОС или обновлений драйверов сетевой карты.

По-прежнему не удается выяснить, почему компьютер не проснется, если через пару часов перейдет в спящий режим, а не в спящий режим.

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

На самом деле делать это или нет - решать вам. Пересылка трафика имеет некоторые риски.

Основные шаги:

1. Перенаправьте порт UPD 7 или 9 на IP-адрес нужного компьютера WOL. Какой порт вам нужно использовать, будет зависеть от используемого вами WOL-клиента. Если клиент позволяет это, вы, вероятно, могли бы использовать любой случайный порт с высоким номером.
2. Если вы находитесь в нескольких частных сетях, вам может потребоваться добавить статическую запись ARP вашего компьютера WOL с FF: FF: FF: FF: FF: FF для MAC. Это должно позволить ему пересылать между коммутаторами.

Другая вещь, которую вы можете сделать, это установить DD-WRT на ваш роутер, если он совместим. Это позволит вам использовать маршрутизатор в качестве клиента WOL, и вы можете просто подключиться к нему через telnet и выполнить соответствующие команды.

Отличный документ от DD-WRT, (и где я нашел всю эту информацию) ==> DD-WRT WOL Page

Проблема здесь в том, что после того, как ваш компьютер был в автономном режиме в течение более длительного времени (5-10 минут?), Mac-адрес удаляется из кэша arp, и между mac- и ip-адресом нет никакой связи.

Таким образом, единственный способ разбудить ваш компьютер - это отправить широковещательное сообщение. Это не проблема в локальной сети, но напрямую через Интернет это невозможно.

Что вам нужно сделать, это переслать порт на ip ... 255, который является широковещательным ip по умолчанию.

На моем D-Link DIR655 кажется, что portforward не работает, но виртуальный сервер работает ... (Что то же самое)? Более подробная информация здесь: http://forums.dlink.com/index.php?PHPSESSID=78ba918bee8de38323a22f203df16195&topic=5934.15

Насколько я понимаю, функция Wake on LAN работает только в том случае, если волшебный пакет отправляется на широковещательный адрес из той же подсети, что и машина, которую вы хотите активировать. Исходя из этого, мне любопытно, будет ли решение включать дополнительный компьютер, который будет «посредником», который отправляет пакет от вашего имени.

У меня есть только неподтвержденные доказательства для проверки. Я хотел сделать то же самое с нашими тестовыми машинами на работе; иногда их усыпляют, и пробуждение по локальной сети было бы идеальным. Я никогда не мог разбудить тестовую машину с моей машины разработки, но успешно разбудил тестовые машины с других тестовых машин. Я мог убедиться, что тестовые машины получали пакеты, но они не выходили из моей машины. В конце концов я сдался и предположил, что, поскольку моя машина разработки и тестовые машины находились в разных частных сетях, это было бы невозможно реализовать.

Я предполагаю, что ваш маршрутизатор / NAT блокирует волшебный пакет. Волшебный пакет должен быть адресован широковещательному адресу, ваш NAT-блок либо заблокирует его, либо, если у вас есть порт переадресации, возможно, вы отправили его на определенный адрес, а не широковещательный адрес. Если это так, то вы можете попробовать изменить порт вперед, чтобы он отправлялся на широковещательный адрес вашей локальной сети.

Я не удивлюсь, если вы просто не можете заставить свой домашний маршрутизатор правильно пересылать волшебный пакет. Если это так, то вам понадобится какая-то форма постоянного помощника в вашей локальной сети. Это может быть ваш роутер, если вы можете сменить его прошивку на что-то, что поддерживает это, или меньший ПК, который вы всегда можете оставить включенным. Вы даже можете получить / написать небольшое приложение, которое всегда будет работать на ПК, прислушиваясь к определенной команде, и когда оно получит ее, оно может отправить правильный магический пакет для вас.