English · Ελληνικά
Κάνε relay magic packets σε flat δίκτυα, routed VLANs, και απομακρυσμένα tunnels Tailscale — χωρίς να αγγίξεις τη συσκευή-στόχο.
Το Wake-on-LAN ακούγεται τετριμμένο μέχρι να μπει στη μέση ένα routed boundary. Ένα magic packet είναι ένα ωμό Layer-2 broadcast — πεθαίνει τη στιγμή που χτυπά ένα interface router. Αυτό το tutorial ξεσκίζει γιατί συμβαίνει αυτό, μετά ξαναχτίζει το μονοπάτι: ξεκινώντας με ένα απλό relay ίδιου-subnet, προσθέτοντας τον forwarder UDP cross-VLAN που το κάνει να δουλεύει σε routed segments, και τελικά προσαρτώντας ένα script πυροδοτημένο από Tailscale ώστε να μπορείς να ξυπνήσεις έναν server σε δωμάτιο server ξενοδοχείου από οπουδήποτε στον πλανήτη.
Κάθε layer χτίζεται πάνω στο προηγούμενο. Στο τέλος θα έχεις ένα επαναχρησιμοποιήσιμο toolkit RouterOS — /tool wol, ονομαστά scripts, τον scheduler, και κανόνες firewall — συν ένα checklist defender ώστε το WoL να μη γίνει ένα μη εξουσιοδοτημένο vector remote-power-on.
01
Πριν αγγίξεις το RouterOS, κατάλαβε τι στέλνεις πραγματικά — και πού σπάει.
Ένα magic packet Wake-on-LAN είναι ένα UDP datagram που μεταφέρει ένα συγκεκριμένο payload 102-bytes: έξι bytes 0xFF ακολουθούμενα από τη διεύθυνση MAC του στόχου επαναλαμβανόμενη δεκαέξι φορές. Η IP προορισμού είναι τυπικά η διεύθυνση broadcast του subnet (π.χ. 192.168.1.255) ή το global broadcast 255.255.255.255, στη θύρα UDP 7 ή 9. Η θύρα 9 (discard) είναι το μοντέρνο πρότυπο.
Το NIC που λαμβάνει — όχι το OS — ακούει για αυτό το pattern στο καλώδιο. Πυροδοτεί ένα σήμα power-on ανεξάρτητα από το αν η συσκευή είναι σε S4 (hibernate) ή S5 (off). Το OS δεν βλέπει ποτέ το πακέτο· το κύκλωμα wake του NIC το βλέπει.
Το RouterOS σου δίνει δύο μηχανισμούς να το λύσεις αυτό. Το /tool wol παράγει ένα magic packet από τον ίδιο τον router — χρήσιμο για scripted ή προγραμματισμένα wakes. Τα leases /ip dhcp-server σου επιτρέπουν να κάνεις resolve ένα hostname σε MAC. Για παράδοση cross-VLAN, χρειάζεται είτε να κάνεις script ένα /tool wol στοχευμένο στο σωστό interface, ή να ρυθμίσεις forwarding UDP broadcast ώστε ένα πακέτο που φτάνει στο subnet ενός VLAN να γίνεται relay σε άλλο.
Κάποιοι παλιότεροι οδηγοί χρησιμοποιούν θύρα UDP 7 (echo). Τα μοντέρνα NICs ανταποκρίνονται στη θύρα 9 (discard). Χρησιμοποίησε τη θύρα 9. Πιο σημαντικό: κάποιοι routers και hosts Linux επίσης ακούνε στη θύρα 7 και θα επεξεργαστούν το πακέτο οι ίδιοι πριν φτάσει στο καλώδιο. Μείνε στη θύρα 9 εκτός αν έχεις συγκεκριμένο λόγο να μην το κάνεις.
02
Η απλούστερη περίπτωση: ο router και ο στόχος ζουν στο ίδιο broadcast domain. Μία εντολή, τέλος.
Αν η συσκευή που θες να ξυπνήσεις είναι στο ίδιο subnet με ένα από τα interfaces RouterOS σου, το /tool wol χειρίζεται τα πάντα. Ορίζεις το interface (ώστε το RouterOS να ξέρει σε ποιο καλώδιο να φωνάξει) και τη διεύθυνση MAC. Ο router κάνει broadcast το magic packet έξω από εκείνο το interface.
[admin@MikroTik] > /tool wol interface=bridge-lan mac=AA:BB:CC:DD:EE:FF # Χωρίς output σε επιτυχία — το πακέτο στέλνεται σιωπηλά. # Αντικατέστησε το bridge-lan με το πραγματικό bridge ή ether interface σου. # Το MAC είναι το MAC του NIC της συσκευής-στόχου (έλεγξε BIOS ή αυτοκόλλητο στο NIC).
Για να αποφύγεις το να ψάχνεις το MAC κάθε φορά, αποθήκευσέ το. Αν η συσκευή έχει static lease DHCP μπορείς να το ανακτήσεις προγραμματιστικά:
[admin@MikroTik] > ip dhcp-server lease print where host-name="fileserver" # Flags: X - disabled, R - radius, D - dynamic, B - blocked # Columns: ADDRESS, MAC-ADDRESS, HOST-NAME, SERVER, STATUS # 0 D 192.168.1.50 AA:BB:CC:DD:EE:FF fileserver dhcp1 bound # Πιάσε την τιμή MAC-ADDRESS από τη γραμμή που ταιριάζει.
interface= και mac= όπως το CLI — χρήσιμο για μεμονωμένα χειροκίνητα wakes χωρίς να ανοίξεις terminal.
Μια κοινή περίπτωση χρήσης SMB: ξύπνα το NAS ή τον backup server στις 02:00 για ένα προγραμματισμένο job backup, μετά άσ' το να κλείσει μόνο του αφού ολοκληρωθεί το job.
[admin@MikroTik] > system scheduler add \ name="wake-fileserver" \ start-time=02:00:00 \ interval=1d \ on-event="/tool wol interface=bridge-lan mac=AA:BB:CC:DD:EE:FF" # interval=1d = επανάλαβε καθημερινά. interval=0 = τρέξε μία φορά.
Αν ορίσεις μια φυσική θύρα (π.χ. ether3) αντί για το bridge, και εκείνη η θύρα είναι down (καλώδιο βγαλμένο, λείπει SFP), το πακέτο WoL γίνεται drop σιωπηλά. Στόχευσε πάντα το bridge στο οποίο είναι μέλος η θύρα, όχι το φυσικό interface, εκτός αν είσαι σίγουρος ότι η θύρα είναι ενεργή.
03
Η πραγματική πρόκληση: ο σταθμός εργασίας management είναι στο VLAN 10, ο server είναι στο VLAN 20, και ένα broadcast δεν θα διασχίσει ποτέ εκείνο το routed boundary μόνο του.
Σε ένα segmented δίκτυο — που είναι το σωστό design για κάθε ξενοδοχείο, βίλα, ή SMB — management, servers, guest Wi-Fi, και IoT ζουν όλα σε ξεχωριστά VLANs. Ένα magic packet που στέλνεται από το VLAN 10 με προορισμό μια διεύθυνση broadcast στο subnet του VLAN 20 θα γίνει drop από τον router. Το RouterOS δεν κάνει forward ωμά Layer-2 broadcasts ανάμεσα σε routed interfaces by default, και δεν θες να το κάνει.
Η σωστή λύση είναι ένα UDP broadcast relay: ο router ακούει για πακέτα WoL που φτάνουν στο interface του VLAN 10, τα αναχαιτίζει, και ξαναδημιουργεί ένα πανομοιότυπο magic packet έξω από το interface του VLAN 20 προς τη διεύθυνση broadcast του VLAN 20. Το RouterOS το παρέχει αυτό μέσω /ip dhcp-relay σε λειτουργία broadcast-helper — αλλά για WoL συγκεκριμένα, η πιο αξιόπιστη προσέγγιση είναι ένα στοχευμένο script /tool wol πυροδοτημένο από έναν κανόνα firewall IP.
Πρόσθεσε έναν κανόνα Input chain που ταιριάζει πακέτα WoL που φτάνουν από το VLAN management σου. Αυτός ο κανόνας ελέγχει ποιος επιτρέπεται να φτάσει το input chain του router στο UDP/9 — δεν καλεί αυτόματα το /tool wol. Η ενέργεια relay χειρίζεται από το ονομαστό script στο Βήμα 2, που ο admin (ή ένας scheduler) τρέχει ρητά. Αυτό το design δύο-βημάτων κρατά την πολιτική firewall ξεχωριστή από τη λογική relay.
[admin@MikroTik] > /ip firewall filter add \ chain=input \ protocol=udp \ dst-port=9 \ in-interface=vlan10 \ src-address=192.168.10.0/24 \ action=accept \ comment="Allow WoL from MGMT VLAN" # Αυτό δέχεται το πακέτο UDP/9 μέσα στο input chain του router. # ΔΕΝ κάνει auto-relay στο VLAN 20 — δες το Βήμα 2 για το script relay. # Χωρίς αυτόν τον κανόνα, μια default πολιτική drop-all θα το απέρριπτε σιωπηλά.
Το RouterOS δεν κάνει εγγενώς parse τα payloads magic packet για να εξάγει το MAC στόχο. Για ένα μικρό, γνωστό σύνολο servers (που είναι η ρεαλιστική περίπτωση SMB/φιλοξενίας), η απλούστερη και πιο αξιόπιστη προσέγγιση είναι ένα ονομαστό script ανά στόχο. Ένας admin καλεί το script· ο router εκτοξεύει το πακέτο wake έξω από το σωστό interface VLAN.
[admin@MikroTik] > system script add \ name="wake-fileserver-vlan20" \ source="/tool wol interface=vlan20 mac=AA:BB:CC:DD:EE:FF" # Για χειροκίνητο τρέξιμο: [admin@MikroTik] > system script run wake-fileserver-vlan20 # Ή προγραμμάτισέ το (ίδιο με το παράδειγμα scheduler του Τμήματος 02). # Πρόσθεσε ένα script ανά server — το MAC είναι το μόνο που αλλάζει.
Αν τα VLANs σου είναι χτισμένα πάνω σε bridge (η σωστή προσέγγιση RouterOS v7), το interface που περνάς στο /tool wol πρέπει να είναι το interface VLAN (π.χ. vlan20) — όχι η φυσική θύρα ή το bridge. Το interface VLAN είναι αυτό που έχει τη μελος στο broadcast domain. Το να στοχεύσεις απευθείας το ether2 θα στείλει ένα untagged broadcast και το NIC στόχος δεν θα το δει ποτέ.
Το DHCP relay (/ip dhcp-relay) κάνει forward broadcasts DHCP ανάμεσα σε subnets — μόνο θύρα 67/68. Δεν κάνει relay αυθαίρετα UDP broadcasts στη θύρα 9. Το να ρυθμίσεις ένα DHCP relay και να περιμένεις να μεταφέρει magic packets δεν θα κάνει τίποτα σιωπηλά. Τα πακέτα πρέπει να ξαναδημιουργηθούν από ένα script που στοχεύει το σωστό interface.
04
Είσαι στην Αθήνα, ο server είναι σε δωμάτιο server ξενοδοχείου στα Χανιά, και το χρειάζεσαι online σε δέκα λεπτά. Ορίστε το μονοπάτι που πραγματικά δουλεύει.
Το Tailscale δίνει σε κάθε node μια σταθερή διεύθυνση 100.x.x.x ανεξάρτητα από NAT, Starlink CGNAT, ή δυναμική IP. Αν η συσκευή RouterOS σου τρέχει ένα container Tailscale (ή έχεις έναν jump host Linux συνδεδεμένο σε Tailscale στο LAN), μπορείς να φτάσεις το μονοπάτι εκτέλεσης script του router από οπουδήποτε στο tailnet σου.
Υπάρχουν δύο patterns. Διάλεξε βάσει του setup σου:
Pattern Α — RouterOS με container Tailscale: Το container έχει μια IP tailnet. Κάνεις SSH μέσα στο container, που μετά τρέχει ένα API call RouterOS ή απλά εκτελεί ένα προτοποθετημένο script. Απαιτεί το feature container του RouterOS (συσκευές ARM/x86).
Pattern Β — Απομακρυσμένο SSH απευθείας στο RouterOS μέσω Tailscale: Το SSH του RouterOS εκτίθεται μόνο στη διεύθυνση interface Tailscale. Κάνεις SSH μέσα και τρέχεις το script. Απλούστερο, δεν χρειάζεται container.
Πρώτα, κλείδωσε το SSH του RouterOS ώστε να ακούει μόνο στο interface που έχει ανατεθεί από Tailscale. Αυτή είναι η βάση ασφάλειας — αν το SSH δεν είναι προσβάσιμο από το WAN, ένα συμβιβασμένο μονοπάτι WoL δεν μπορεί να γίνει foothold.
[admin@MikroTik] > ip service set ssh address=100.64.0.0/10 # Το 100.64.0.0/10 καλύπτει ολόκληρο το εύρος CGNAT του Tailscale. # Ρύθμισέ το στο συγκεκριμένο subnet tailnet σου αν θες σφιχτότερο έλεγχο. # Όλες οι άλλες source IPs θα απορριφθούν στο επίπεδο υπηρεσίας. [admin@MikroTik] > ip service print Flags: X - disabled # NAME PORT ADDRESS CERTIFICATE 0 telnet 23 (disabled) 1 ftp 21 (disabled) 2 www 80 (disabled) 3 ssh 22 100.64.0.0/10 4 www-ssl 443 (disabled) 5 api 8728 (disabled) 6 winbox 8291 192.168.10.0/24 (mgmt VLAN only) 7 api-ssl 8729 (disabled) # Το Winbox μένει μόνο στο VLAN MGMT. Το SSH κλειδωμένο στο tailnet.
user@laptop:~$ ssh admin@100.x.x.router "/system script run wake-fileserver-vlan20" # Μία εντολή. Το SSH βγαίνει αφού τρέξει το script. # Δεν χρειάζεται interactive session. # Τύλιξέ το σε ένα shell alias ή ένα Makefile target για wakes με ένα πάτημα. # Ή interactively: user@laptop:~$ ssh admin@100.x.x.router [admin@MikroTik] > system script run wake-fileserver-vlan20
Το RouterOS δεν ξανατρέχει αυτόματα το Tailscale μετά από reboot εκτός αν έχεις μια καταχώρηση scheduler που τρέχει /container start [find name="tailscale"] στο startup. Αν ο router έκανε reboot τη νύχτα (διακοπή ρεύματος, firmware update) και το Tailscale δεν τρέχει, το μονοπάτι SSH σου δεν υπάρχει. Πρόσθεσε έναν scheduler startup ή χρησιμοποίησε μια δευτερεύουσα μέθοδο πρόσβασης out-of-band — Winbox πάνω από το LAN σαν fallback τουλάχιστον.
Μπορεί να δοκιμάσεις να τρέξεις wakeonlan AA:BB:CC:DD:EE:FF από ένα box Linux συνδεδεμένο σε Tailscale και να το κατευθύνεις στην IP tailnet του στόχου ή σε ένα broadcast. Αυτό αποτυγχάνει γιατί: (α) η συσκευή στόχος είναι off και δεν έχει παρουσία tailnet, και (β) ακόμα κι αν το κατευθύνεις στο broadcast του LAN, ο host Linux δεν έχει Layer-2 adjacency με το subnet του στόχου. Το magic packet πρέπει να σταλεί από κάτι με φυσική (ή bridged) πρόσβαση σε εκείνο το subnet — που είναι ακριβώς αυτό που έχει το RouterOS.
05
Ένα ανοιχτό relay WoL είναι ένα ανοιχτό vector power-on. Κλείδωσέ το πριν το εκμεταλλευτεί ένα VLAN επισκεπτών ή μια λάθος ρυθμισμένη συσκευή.
Από προεπιλογή, αν το forward chain σου είναι επιτρεπτικό, οποιοσδήποτε host σε οποιοδήποτε VLAN θα μπορούσε να φτιάξει ένα πακέτο UDP/9 σε μια διεύθυνση broadcast και να ανάψει συσκευές που δεν πρέπει να αγγίξει. Το μοντέλο θωράκισης είναι απλό: τα πακέτα WoL πρέπει να φτάνουν μόνο στο input chain του RouterOS από μια καθορισμένη πηγή management, και δεν πρέπει ποτέ να γίνονται forward ανάμεσα σε μη έμπιστα VLANs.
[admin@MikroTik] > ip firewall filter # 1. Κάνε drop WoL από VLANs guest / IoT — πριν από οποιονδήποτε κανόνα accept [admin@MikroTik] /ip/firewall/filter> add \ chain=input protocol=udp dst-port=9 \ in-interface-list=UNTRUSTED \ action=drop \ comment="Drop WoL from untrusted VLANs" # 2. Κάνε drop WoL στο forward chain — τα πακέτα δεν πρέπει ποτέ να περνούν, μόνο input [admin@MikroTik] /ip/firewall/filter> add \ chain=forward protocol=udp dst-port=9 \ action=drop \ comment="Drop WoL forward — use /tool wol relay instead" # 3. Δέξου WoL μόνο από VLAN MGMT στο input [admin@MikroTik] /ip/firewall/filter> add \ chain=input protocol=udp dst-port=9 \ in-interface=vlan10 \ src-address=192.168.10.0/24 \ action=accept \ comment="WoL from MGMT only" # Η σειρά κανόνων έχει σημασία. Κάνε drop το μη έμπιστο ΠΡΩΤΑ, μετά accept το MGMT. # Πρόσθεσέ τα ΠΑΝΩ από τον γενικό κανόνα drop-all σου στο τέλος του chain.
Περιόρισε την ακτίνα έκρηξης. Αν ένας επιτιθέμενος μπορεί να στείλει ένα magic packet, μπορεί να ανάψει συσκευές — αλλά ακόμα χρειάζεται credentials για να κάνει κάτι χρήσιμο μόλις η συσκευή είναι up. Η πραγματική έκθεσή σου είναι το παράθυρο ανάμεσα στο power-on και το πλήρες boot όπου υπηρεσίες ξεκινούν χωρίς authentication. Βεβαιώσου ότι οι servers σου απαιτούν authentication πριν δεχτούν οποιεσδήποτε συνδέσεις και ότι υπηρεσίες κατά το boot (SMB, RDP, SSH) δεν είναι εκτεθειμένες σε μη έμπιστα segments.
Οι interface lists είναι φίλος σου. Δημιούργησε μια interface list UNTRUSTED που περιέχει guest Wi-Fi, IoT, και οποιαδήποτε VLANs τρίτων. Κάνε drop UDP/9 από αυτή τη λίστα globally. Χρειάζεσαι μόνο έναν κανόνα, και η προσθήκη ενός νέου μη έμπιστου VLAN στη λίστα κληρονομεί αυτόματα την προστασία.
WoL πάνω από θύρα 0 / raw frames. Κάποια εργαλεία παρακάμπτουν εντελώς το UDP και στέλνουν το magic packet σαν ωμό frame Ethernet (EtherType 0x0842). Οι κανόνες filter του firewall RouterOS πιάνουν μόνο κίνηση IP. Αν είσαι σε switch CRS, βεβαιώσου ότι μη έμπιστες θύρες bridge δεν μπορούν να κάνουν inject raw frames στο bridge domain των servers χρησιμοποιώντας bridge port isolation ή private VLANs.
06
Θες να ξέρεις πότε ξυπνήθηκε μια συσκευή, ποιος το πυροδότησε, και αν πραγματικά ανέβηκε — το logging του RouterOS και απλά probes ping το καλύπτουν αυτό.
Πρόσθεσε μια ενέργεια logging στον κανόνα accept του firewall σου ώστε κάθε trigger WoL να αφήνει ίχνος στο log του RouterOS με timestamp και source IP.
[admin@MikroTik] > ip firewall filter set \ [find comment="WoL from MGMT only"] \ action=log log-prefix="WOL-TRIGGER" \ log=yes # Ή πρόσθεσε έναν ξεχωριστό κανόνα log ακριβώς πριν τον κανόνα accept: # chain=input, ίδιο match, action=log, log-prefix="WOL-TRIGGER" # Οι καταχωρήσεις log εμφανίζονται στο /log print — και στον server syslog σου αν είναι ρυθμισμένος. [admin@MikroTik] > log print where topics~"firewall" and message~"WOL-TRIGGER" may/02 14:33:01 firewall,info WOL-TRIGGER: in:vlan10 \ src-mac AA:BB:CC:11:22:33, proto UDP, \ 192.168.10.5:50234->192.168.10.255:9, len 102 # Το source MAC + IP σου λέει ακριβώς ποιος έστειλε το WoL.
Ένα script που στέλνει WoL και μετά κάνει ping τον στόχο μερικά δευτερόλεπτα αργότερα σου δίνει επιβεβαίωση — και μπορείς να κάνεις log ή email το αποτέλεσμα.
[admin@MikroTik] > system script add name="wake-and-verify-fileserver" source={ /tool wol interface=vlan20 mac=AA:BB:CC:DD:EE:FF :delay 45s :local result [/ping address=192.168.20.50 count=3 as-value] :if ($result->"received" > 0) do={ :log info "WOL-OK: fileserver 192.168.20.50 responded after wake" } else={ :log warning "WOL-FAIL: fileserver did not respond after 45s" } } # Το as-value επιστρέφει ένα dict σε ROS v7 — χρησιμοποίησε ->"received" για τον αριθμό πακέτων. # Τα 45s δίνουν στις περισσότερες συσκευές αρκετό χρόνο να κάνουν POST και να φτάσουν το network stack του OS. # Ρύθμισέ το για αργό hardware ή για prompts ξεκλειδώματος full-disk-encryption. # Για email alerts: πρόσθεσε /tool e-mail send στο block else (απαιτεί config SMTP).
Στείλε logs σε έναν server syslog. Το on-device log του RouterOS είναι volatile και περιορισμένο. Ρύθμισε το /system logging action να στέλνει σε απομακρυσμένο syslog (Graylog, Loki, ή ακόμα και ένα απλό instance rsyslog στον server management σου). Φίλτραρε για WOL-TRIGGER και κάνε alert σε οποιαδήποτε πηγή έξω από τις αναμενόμενες IPs management σου.
Απρόσμενο WoL είναι σήμα απειλής. Σε ένα περιβάλλον ξενοδοχείου ή SMB, ένα πακέτο WoL από μια απρόσμενη source IP — ειδικά από ένα VLAN επισκεπτών αν οι κανόνες firewall σου παρασυρθούν ποτέ — σημαίνει είτε λάθος ρύθμιση είτε σκόπιμο probe. Μεταχειρίσου απρόσμενα γεγονότα WoL όπως απρόσμενα port scans: ερεύνησε την πηγή αμέσως.
Συνδύασέ το με Netwatch για tracking κατάστασης. Το /tool netwatch παρακολουθεί την προσβασιμότητα ενός host και μπορεί να πυροδοτήσει scripts σε αλλαγή κατάστασης. Ρύθμισε μια καταχώρηση Netwatch για κάθε κρίσιμο server: όταν μεταβαίνει από down σε up, κάνε log το γεγονός με timestamp. Σταυρωμένο με logs WoL, παίρνεις ένα πλήρες audit trail του ποιος ξύπνησε τι και πότε ήρθε online.
[admin@MikroTik] > tool netwatch add \ host=192.168.20.50 \ interval=30s \ up-script="/log info \"NETWATCH: fileserver UP\"" \ down-script="/log warning \"NETWATCH: fileserver DOWN\"" # Κάνει log κάθε μετάβαση κατάστασης. Συσχέτισέ το με timestamps WOL-TRIGGER # στο /log print για να χτίσεις ένα πλήρες audit trail wake-to-online.
Βασικα Συμπερασματα
/tool wol στοχευμένο στο σωστό interface VLAN./tool wol interface= πρέπει να δείχνει στο interface VLAN, όχι στη φυσική θύρα ή το bridge. Αυτή είναι η πιο κοινή λάθος ρύθμιση. Αν τα πακέτα δεν φτάνουν, έλεγξε πρώτα το όνομα interface.100.64.0.0/10 τουλάχιστον πριν βασιστείς λειτουργικά σε αυτό το μονοπάτι.UNTRUSTED είναι πιο ασφαλής και ευκολότερος να συντηρηθεί από κανόνες ανά-VLAN. Πρόσθεσε νέα μη έμπιστα VLANs στη λίστα και η προστασία είναι αυτόματη.Σχεδιάζω και διαχειρίζομαι segmented δίκτυα για ιδιοκτησίες φιλοξενίας — VLANs, πολιτική firewall, απομακρυσμένο management, Starlink σαν μονοπάτι failover. Αν το δίκτυό σου είναι ακόμα ένα flat subnet, μια λάθος ρύθμιση είναι πιο κοντά απ' όσο νομίζεις.
Κλεισε ενα 30λεπτο Discovery Call →