Debian Wake о пересылке пакетов по локальной сети?

Проблема пробуждения хоста заключается в том, что для отправки ему пакета сетевой стек должен знать MAC-адрес NIC. Обычно это динамически обрабатывается ARP . Если запись MAC была удалена из таблицы ARP маршрутизатора, когда хост спит, он не может ответить на запрос ARP, поэтому маршрутизатор не может получить MAC-адрес, необходимый для связи с спящим хостом, чтобы отправить ему пакет WOL Magic. ™, даже если такой пакет включает в свою полезную нагрузку 16 раз этот MAC-адрес .

Вот два способа решить эту проблему, полагаясь только на сетевой стек (и сопутствующие устройства, такие как iptables или tc).

Постоянный ARP

Поскольку на маршрутизаторе есть управление, можно установить постоянную запись ARP на маршрутизаторе для спящего хоста. Таким образом, предыдущая проблема никогда не возникнет. Маршрутизатор теперь может легко отправлять или пересылать пакеты WOL Magic Packet™ без использования какой-либо широковещательной рассылки. С NAT для «переадресации портов» удаленный хост может затем использовать командуwakeonlan(, а не команду etherwake, поскольку он может изменить порт UDP ).

Таким образом, спящему хосту требуется статический адрес (или адрес с постоянной арендой DHCP ). Допустим, адрес WAN на маршрутизаторе — 192.0.2.2 на wan0 , сторона LAN на маршрутизаторе — 192.168.1.1/24 на интерфейсе lan0 и спящий хост 192.168.1.101/ 24 на интерфейсе с MAC-адресом 12 :34 :56 :78 :9a :bc.

На роутере:

ip neighbour replace 192.168.1.101 lladdr 12:34:56:78:9a:bc dev lan0 nud permanent

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

Проблема поступления первого пакета в другое место в описании OP решается путем выбора всех интерфейсов, кроме интерфейса lan0 .

Итак, все еще на маршрутизаторе, используя iptables , выполните DNAT и разрешите перенаправленный пакет:

iptables -t nat -I PREROUTING ! -i lan0 -p udp --dport 9 -j DNAT --to-destination 192.168.1.101
iptables -I FORWARD -m conntrack --ctstate DNAT -d 192.168.1.101 -j ACCEPT

Удаленный хост в Интернете теперь может сделать это, чтобы разбудить спящий хост:

wakeonlan -i 192.0.2.2 -p 9 12:34:56:78:9a:bc

Системная интеграция зависит от метода, используемого для настройки сети. Например, если он настроен с помощьюinterfacesи ifupdown , две команды iptablesмогут быть добавлены как команды pre-upв разделе iface lan0...(и удалены в команде down), а ip neighbourкак команду up.

Направленная широковещательная рассылка подсети(начиная с ядра 4.19)

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

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

Направленная широковещательная рассылка подсети должна быть включена глобально и на принимающем интерфейсе WAN (, а не на целевом интерфейсе LAN ). Если возможно несколько интерфейсов WAN (OP описывает пакеты, поступающие сначала на один интерфейс, а затем на другой ), включите его на всех вовлеченных.

sysctl -w net.ipv4.conf.all.bc_forwarding=1
sysctl -w net.ipv4.conf.wan0.bc_forwarding=1

Добавить правила NAT и FORWARD:

iptables -t nat -I PREROUTING ! -i lan0 -p udp --dport 9 -j DNAT --to-destination 192.168.1.255
iptables -I FORWARD -m conntrack --ctstate DNAT -d 192.168.1.255 -j ACCEPT

И, как вариант, чтобы ограничить риски, окончательно преобразовать фрейм IPv4 Ethernet (ethertype 0x800 )в фактический ethertype 0x842, используемый для WOL, используя tc , чтобы результат был проигнорирован сетевые стеки (, но не сетевые карты WOL ). Можно было бы использовать метку, установленную iptables,или здесь просто рассмотрим IP-адрес назначения и порт назначения UDP 9. Прежний метод столкнулся бы с метками, если бы использовался Untangle, любой метод будет конфликтовать в любом случае, если Untangle использует tc для QoS.

tc qdisc add dev lan0 root handle 1: prio # simple classful qdisc used only to enable filters
tc filter add dev lan0 parent 1: protocol ip basic match '
    cmp (u32 at 16 layer network eq 0xc0a801ff) and
    cmp (u8 at 9 layer network eq 17) and
    cmp (u16 at 2 layer transport eq 9)
    ' action skbmod set etype 0x842

Выше,

• u32 в 16-уровневой сети eq 0xc0a801ff означает IP-адрес назначения 192.168.1.255,
• u8 в 9-уровневой сети eq 17 означает UDP,
• u16 в 2-уровневом транспортном уравнении 9 означает порт назначения 9.
• и результирующим действием является изменение ethertype на 0x842

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

wakeonlan -i 192.0.2.2 -p 9 12:34:56:78:9a:bc

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

Другой метод для рассмотрения:

fwknopd, установленный на сервере, и fwknop, установленный на клиенте, реализуют механизм авторизации зашифрованного одиночного пакета для запуска команд. Его можно использовать для запуска wakeonlan/ etherwakeна маршрутизаторе.