Правда ли, что мы не можем позволить любой машине спать, к которой может потребоваться доступ через соединение VPN?
(Я спрашиваю об этом по вине сервера, так как речь идет о VPN-серверах так же, как о компьютерах конечного пользователя, которые спят)
Ответы:
Старая тема, но я хотел бы присоединиться к ней, потому что это все еще лучший результат поиска по запросу "wol over vpn".
Да, магический пакет WOL определен в пределах ограничений уровня 2, но это не означает, что он не может содержаться внутри объекта сетевого и транспортного протокола, который затем может использоваться для маршрутизации его через VPN. Причина этого в том, что «волшебная» последовательность может быть где угодно в пределах полезной нагрузки. По сути, это становится вопросом получения обычного маршрутизируемого пакета на целевой хост с «магической» последовательностью внутри его полезной нагрузки.
В большинстве реализаций магического пакета используется UDP-порт 9, хотя это действительно не имеет значения, если он правильно маршрутизируется и передается в том же домене широковещательной рассылки, что и целевой компьютер. Пока VPN-клиент имеет правильные маршруты, он может правильно отправлять широковещательный пакет, такой как 192.168.1.255 (широковещательный адрес), на шлюз VPN через Интернет.
Таким образом, маршрутизация действительно проста, проблема может заключаться в правильной трансляции с целевого шлюза VPN. Это означает настройку шлюза VPN / поиск опции для пересылки широковещательного трафика от удаленных клиентов VPN в локальную сеть.
Обычно нет, так как «MagicPacket» на самом деле находится на уровне 2. Он даже не маршрутизируется без помощи серверов пересылки (например, IP-помощник).
Существует причудливый способ построить туннель уровня 2 с SSH, и с этим WOL должен хорошо работать. Поэтому не вижу смысла обходиться без отправки машин в спячку.
На основании упоминания @slm я включил важные части источника ниже.
Предпосылки:
1) на обоих компьютерах должен быть включен root. (извините - ваши учетные данные на обоих компьютерах должны позволять вам создавать устройства TAP). Это означает: на системном уровне root имеет пароль;
2) в файле sshd_config хоста, на котором запущен демон ssh, задаются параметры PermitTunnel yes и PermitRootLogin yes;
3) в ядре включена ip forwarding Используйте команду sysctl для установки этой опции: sysctl -w net.ipv4.ip_forwarding = 1; также добавьте строку net.ipv4.ip_forwarding = 1 в ваш файл /etc/sysctl.conf, чтобы параметр оставался после перезагрузки. Сделайте это на обоих компьютерах;
4) Вы установили пакет bridge-utils или иным образом получили команду brctl на обоих компьютерах.
Создайте туннель:
ssh -w 1: 1 -o Tunnel = имя хоста Ethernet
опция -w устанавливает имя устройства TAP на любом хосте (здесь, tap1 будет создан на обоих концах).
опция -o предназначена для указания опции файла конфигурации в командной строке. Мы используем Tunnel = ethernet для настройки туннеля второго уровня.
Эта форма будет держать сессию ssh открытой на переднем плане. Если вы хотите, чтобы он покинул оболочку после того, как туннель был установлен, вы можете использовать опцию -f, чтобы сказать ему, что он должен переходить в фоновый режим. Тем не менее, ему нужна команда для разветвления, поэтому вы можете просто использовать фиктивную команду, такую как true, чтобы она заработала. Вы также можете использовать эту функцию для настройки моста на удаленном конце, но сейчас я не буду вдаваться в подробности. Итак, это будет выглядеть так:
ssh -f -w 1: 1 -o Tunnel = имя хоста Ethernet
Добавьте устройства TAP к мосту:
brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 up
вы запускаете это на обоих хостах (обратите внимание, что я не назначил IP). brctl - это команда, используемая для управления мостовыми устройствами. brctl addbr добавляет мост br0, а команда addif присоединяет к нему устройство tap1.
Следующим шагом будет добавление физических интерфейсов Ethernet к мостовому устройству. То, как вы захотите это сделать, будет меняться, поэтому я рассмотрю пару сценариев. Первый сценарий - это когда ваши VPN-узлы находятся в одной подсети (т. Е. Между ними нет маршрутизации), а второй - через Интернет.
Бесстыдно похищен из: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/
Да, вы можете вместо отправки пакета WoL на широковещательный адрес в целевой сети просто отправить его на IP-адрес компьютера, который вы хотите активировать. Программы, протестированные с PPTP VPN:
Я согласен с user48838 - по определению волшебный пакет отправляется только через локальную подсеть. Однако ранее я использовал скрипт, написанный jpo, который работал из другой подсети через обычный маршрутизатор. Попробуйте это - YMMV
ну на самом деле ответ ДА.
Я успешно использую WOL через PPTP VPN с помощью этого приложения: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl
Я проверил это, и ответ ДА :)
В интернете я нашел инструмент, который отправляет пакет WOL как одноадресный на предполагаемый хост, с помощью которого можно избежать передачи широковещательного пакета через проблему с маршрутизатором.
В этом решении нужно обратить внимание на один момент: вам нужно поместить статическую запись arp в маршрутизатор, поскольку хост будет отключен и не будет отвечать на запрос ARP маршрутизатора. Ура!