Come abbiamo visto in un articolo precedente, il Wake on LAN è un protocollo di rete che consente di avviare un computer da remoto attraverso l’invio di un pacchetto speciale chiamato Magic Packet.
Cercando di essere vagamamente tecnici, è importante ricordare che questo protocollo opera sul layer 2 del modello OSI. In altre parole, i pacchetti Wake on LAN sono trasmessi come Broadcast UDP e sono quindi limitati alla rete locale in cui vengono generati.
Questo significa che, in ambienti di rete più complessi, come quelli con VLAN e router, se vogliamo garantire che i pacchetti WoL possano raggiungere la destinazione desiderata, anche cross-network, dovremo fare delle configurazioni specifiche. Vediamo alcune opzioni tratte da casi d’uso reali.
WoL Cisco e IP directed broadcast
Citando Cisco:
An IP directed broadcast is an IP packet whose destination address is a valid broadcast address for some IP subnet but which originates from a node that is not itself part of that destination subnet
Prendiamo il caso dell’immagine in figura dove Host A
dalla Vlan 100
deve inviare il pacchetto WoL a Host B
sulla Vlan 200
.
La prima cosa che notiamo è lo switch L3 SW 1
che fa da router per le nostre Vlan, infatti sarà lui ad occuparsi del routing del pacchetto WoL attraverso le sue SVI (Switched Virtual Interface). SW 2
e SW 3
possone essere anche dei semplici switch unmanaged, ognuno lavora esclusivamente nella sua VLAN di assegnazione.
Questa la configurazione:
SW1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#ip routing
!--- Routing must be enabled
SW1(config)#access-list 100 permit udp host 192.168.100.5 any eq 7
!--- This accepts directed broadcasts only from Host A.
SW1(config)#ip forward-protocol udp 7
!--- Specifies the protocol and port to be forwarded.
!--- The port number may vary with the WOL utility used.
SW1(config-if)#interface vlan 100
SW1(config-if)#ip address 192.168.100.254 255.255.255.0
SW1(config-if)#ip helper-address 192.168.200.255
!-- Enables forwarding of WoL IP broadcast packets (dst=255.255.255.255) to clients.
!-- Works in conjunction with the ip forward-protocol command.
SW1(config-if)#interface vlan 200
SW1(config-if)#ip address 192.168.200.254 255.255.255.0
SW1(config-if)#ip directed-broadcast 100
!--- Enables the translation of a directed broadcast to physical broadcasts.
!--- Here 100 is the acl
SW1(config)#^Z
Con questo setup la destinazione da inserire nel programma di Wake on Lan è 192.168.200.255
Cosa succede in realtà
Continuando con l’esempio riportato prima a Layer 3 i pacchetti WoL possono essere di due tipi:
- IP broadcast, con
src=<sender_ip>
edst=255.255.255.255
. - IP directed broadcast, con
src=<sender_ip>
edst=192.168.200.255
.
Dal punto di vista dello switch però, il Layer 2 si presenta così:
- IP broadcast, con
src=<sender_mac>
edst=ff:ff:ff:ff:ff:ff
. - IP directed broadcast, con
src=<sender_mac>
edst=ff:ff:ff:ff:ff:ff
.
Questo significa che a livello switching entrambi i pacchetti sono dei broadcast Ethernet da inoltrare su tutte le porte della medesima LAN/VLAN, a livello routing solo un pacchetto di tipo IP directed broadcast potrà essere accettato e verrà inoltrato (forwarded) solo se il router è configurato per farlo.
La cosa interessante, ora che conosciamo meglio cosa accade dietro le quinte, è che possiamo trovare modi alternativi per recapitare i pacchetti WoL a destinazioni remote.
WoL con static ARP
Con un record ARP statico si può generare un broadcast layer 2 con un pacchetto unicast layer 3.
Consideriamo due reti interconnesse come in figura attraverso i rispettivi router
Possiamo utilizzare un IP fittizio, diciamo 192.168.200.200
, per generare il broadcast layer 2.
Ci basterà configurare su R2
un record ARP statico come questo
arp 192.168.200.200 ffff.ffff.ffff
e…stop, fatto! Qualunque pacchetto WoL inviato a 192.168.200.200
verrà ricevuto da tutti gli host sulla rete 192.168.200.0/24.
WoL unicast tramite Layer 2 flooding e static ARP
Non tutti i router permettono di configurare un record ARP con MAC ff:ff:ff:ff:ff:ff
, in questi casi possiamo però riciclare parzialmente questa configurazione ed affidarci al funzionamento standard degli switch, il flooding.
Detto in termini semplici, il Layer 2 flooding è ciò che avviene sugli switch quando ricevono un frame con un indirizzo MAC di destinazione che non è presente nella loro memoria. Per garantire che il frame raggiunga il destinatario lo switch trasmette quindi il frame su tutte le porte, tranne quella da cui è arrivato.
Avete già capito dove voglio arrivare? Proviamolo su questa rete in figura.
WoL WatchGuard senza Directed Broadcast
Mettiamo di dover inviare il nostro pacchetto WoL a livello 3, WatchGuard ad esempio non supporta IP Directed Broadcast e nemmeno ARP statiche con MAC ff:ff:ff:ff:ff:ff
. Vediamo come sfruttare il Layer 2 flooding a nostro vantaggio.
Per prima cosa settiamo un record ARP statico fittizio per 192.168.200.200
con un MAC tipo ff:ff:ff:ff:ff:fe
. Senza questa operazione il pacchetto WoL verrebbe scartato sul Firewall dato che tenterebbe, in vano, una risposta ARP dall’host 192.168.200.200
(che non esiste).
Poi… poi basta, abbiamo finito: inviando il pacchetto WoL all’IP 192.168.200.200
questo verrà inoltrato sullo switch il quale, non conoscendo il MAC ff:ff:ff:ff:ff:fe
, scatenerà un layer 2 flooding inoltrandolo su tutte le porte e raggiungendo quindi anche l’host target.
Piccola dritta: se non vi piace riservare un’indirizzo della rete di produzione per questo scopo (il nostro 192.168.200.200
) potete configurare un Secondary IP sulla rete target, magari con una subnet ridotta, ad esempio una 172.16.31.254/30
, l’unico IP fittizio configurabile diventa a questo punto il 172.16.31.253
che andrà inserito in ARP.
Conclusioni
Il bello di queste tecniche, almeno per me, è che anche se non molto diffuse si basano sull’applicazione dei concetti teorici alla base del networking. Come spesso accade, le soluzioni anche se non immediate, le possiamo trovare rimescolando le carte che già abbiamo.
E voi, conoscevate queste tecniche? Il mio consiglio, ovviamente, è di valutare bene quali usare e prima di metterle in produzione approfondire alcuni concetti che in ordine sparso possono essere: smurf attacks, acl, storm control.
Buon approfondimento!