Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Linux Enterprise Server / Guide de déploiement / Configuration d'un serveur d'installation / Préparation de l'environnement de démarrage réseau
S'applique à SUSE Linux Enterprise Server 15 SP6

18 Préparation de l'environnement de démarrage réseau

Ce chapitre décrit la façon de configurer un serveur DHCP et un serveur TFTP fournissant l'infrastructure requise pour démarrer avec PXE.

SUSE® Linux Enterprise Server peut être installé par le biais d'un Preboot Execution Environment (PXE). Le matériel client a besoin de prendre en charge le démarrage via PXE. Le réseau doit être doté d'un serveur DHCP et d'un serveur TFTP fournissant les données requises aux clients. Ce chapitre vous guide dans la configuration des serveurs requis.

PXE démarre uniquement un kernel et initrd. Cela permet de démarrer dans un environnement d'installation ou dans des systèmes actifs. Pour configurer les sources d'installation, reportez-vous au Chapitre 17, Configuration d'une source d'installation réseau.

Cette section expose les tâches de configuration nécessaires pour les scénarios de démarrage complexes. Elle contient des exemples de configuration « prêts à l'emploi » pour le protocole DHCP, le démarrage PXE, le protocole TFTP et la fonction Wake on LAN.

Les exemples supposent que les serveurs DHCP, TFTP et NFS résident sur la même machine ayant pour adresse IP 192.168.1.1. Tous les services peuvent résider sur des ordinateurs différents sans problème. Veillez à modifier les adresses IP en fonction de vos besoins.

18.1 Configuration d'un serveur DHCP

Un serveur DHCP fournit des assignations d'adresses IP dynamiques (Section 18.1.1, « Assignation d'adresse dynamique ») et statiques (Section 18.1.2, « Assignation d'adresses IP statiques ») à vos clients réseau. Il annonce les serveurs, les routes et les domaines. Pour les serveurs TFTP, DHCP fournit également les fichiers de kernel et initrd. Les fichiers qui sont chargés dépendent de l'architecture de la machine cible et de l'utilisation éventuelle du démarrage BIOS ou UEFI hérité. Les clients transmettent leur type d'architecture dans leur demande DHCP. Suivant ces informations, le serveur DHCP décide quels fichiers le client doit télécharger pour le démarrage.

Avertissement
Avertissement : échec de l'installation PXE et AutoYaST

À partir de SUSE Linux Enterprise 15,0, il existe des situations spéciales dans lesquelles le démarrage PXE et les installations AutoYaST échouent. Pour plus d'informations et pour connaître la solution, reportez-vous à la Section 18.1.3, « Échecs de l'installation PXE et AutoYaST ».

18.1.1 Assignation d'adresse dynamique

L'exemple suivant montre comment configurer un serveur DHCP qui assigne des adresses IP aux clients de façon dynamique, et qui annonce les serveurs, les routeurs, les domaines et les fichiers de démarrage.

  1. Connectez-vous en tant qu'utilisateur root à la machine qui héberge le serveur DHCP.

  2. Activez le serveur DHCP en exécutant la commande systemctl enable dhcpd.

  3. Ajoutez les lignes suivantes à la configuration de sous-réseau du fichier de configuration du serveur DHCP, situé dans /etc/dhcpd.conf :

    # The following lines are optional
    option domain-name "my.lab";
    option domain-name-servers 192.168.1.1;
    option routers 192.168.1.1;
    option ntp-servers 192.168.1.1;
    ddns-update-style none;
    default-lease-time 3600;
    
    # The following lines are required
    option arch code 93 = unsigned integer 16; # RFC4578
    subnet 192.168.1.0 netmask 255.255.255.0 {
     next-server 192.168.1.1;
     range 192.168.1.100 192.168.1.199;
     default-lease-time 3600;
     max-lease-time 3600;
     if option arch = 00:07 or option arch = 00:09 {
       filename "/EFI/x86/grub.efi";
     }
     else if option arch = 00:0b {
       filename "/EFI/aarch64/bootaa64.efi";
     }
     else  {
       filename "/BIOS/x86/pxelinux.0";
     }
    }

    Cet exemple de configuration utilise le sous-réseau 192.168.1.0/24 avec DHCP, DNS et la passerelle sur le serveur avec l'adresse IP 192.168.1.1. Assurez-vous que toutes les adresses IP sont modifiées en fonction de votre topologie de réseau. Pour plus d'informations sur les options disponibles dansdhcpd.conf, reportez-vous à la page de manuel dhcpd.conf.

  4. Redémarrez le serveur DHCP en exécutant la commande systemctl restart dhcpd.

18.1.2 Assignation d'adresses IP statiques

Un serveur DHCP peut également assigner des adresses IP statiques et des noms d'hôte à des clients du réseau. Un cas d'utilisation consiste à assigner des adresses statiques à des serveurs. Un autre cas d'utilisation implique de limiter les clients qui peuvent rejoindre le réseau à ceux disposant d'une adresse IP statique, et de ne fournir aucune réserve d'adresses dynamiques.

Modifiez la configuration DHCP ci-dessus conformément à l'exemple suivant :

group {
 host test {
   hardware ethernet MAC_ADDRESS;
   fixed-address IP_ADDRESS;
   }
}

L'instruction d'hôte assigne un nom d'hôte à la cible d'installation. Pour lier le nom d'hôte et l'adresse IP à un hôte spécifique, vous devez indiquer l'adresse matérielle (MAC) du client. Remplacez toutes les variables utilisées dans cet exemple par les valeurs réelles qui correspondent à votre environnement, puis enregistrez les modifications et redémarrez le serveur DHCP.

18.1.3 Échecs de l'installation PXE et AutoYaST

À partir de SUSE Linux entreprise 15.0 et d'ISC DHCP 4.3.x, des situations spéciales peuvent entraîner un échec du démarrage de PXE et des installations AutoYaST. Si votre serveur DHCP ne possède pas de réserve d'adresses IP dynamiques disponibles, mais n'autorise que des adresses statiques prédéfinies par client, et que les clients envoient des identificateurs de client RFC 4361, les installations PXE/AutoYaST ne fonctionneront pas. (Si le système n'autorise que des adresses assignées à des clients réseau spécifiques et ne fournit pas de réserve d'adresses dynamiques, les machines aléatoires ne peuvent pas se connecter au réseau).

Lorsqu'un nouveau système démarre dans PXE, il envoie une requête au serveur DHCP et s'identifie à l'aide d'un identificateur de client constitué du type de matériel et de l'adresse MAC de l'interface réseau. Il s'agit d'un client-id(ID client) RFC 2132. Le serveur DHCP propose alors l'adresse IP assignée. Ensuite, le kernel d'installation est chargé et envoie une autre requête DHCP, mais ce client-id est différent et est envoyé au format RFC 4361. Le serveur DHCP ne reconnaît pas qu'il s'agit du même client et recherche une adresse IP dynamique disponible, alors qu'il n'y en a pas, de sorte que l'installation s'arrête.

La solution consiste à configurer les clients pour qu'ils envoient des ID de client au format RFC 2132. Pour envoyer un client-id RFC 2132 au cours de l'installation, utilisez linuxrc afin de transmettre la commande ifcfg suivante :

ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67,
DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67

Le client-id DHCPv4 RFC 2132 traditionnellement utilisé sur Ethernet est constitué du type de matériel (01 pour Ethernet) et suivi de l'adresse matérielle (adresse MAC), par exemple :

01:52:54:00:02:c2:67

Le client-id DHCPv4 RFC 4361 tente de corriger le problème d'identification d'une machine qui compte plusieurs interfaces réseau. Le nouveau client-id DHCPv4 présente le même format que le client-id DHCPv6. Il commence par le préfixe 0xff (plutôt que par le type de matériel), suivi de l'IAID (Interface-address Association ID, ID d'association d'adresse d'interface qui décrit l'interface sur la machine) DHCPv6, puis du DUID ( Unique Identifier, identificateur unique DHCP) DHCPv6 qui identifie de manière unique la machine.

Selon le DUID basé sur le type et l'adresse de matériel susmentionnés, le nouveau client-id DHCPv4 RFC 4361 serait :

  • En utilisant les derniers octets de l'adresse MAC en tant qu'IAID : ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

  • Lorsque l'IAID est juste un nombre incrémenté : ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

Le champ xx:xx:xx:xx de l'horodatage DUID-LLT (DUID-Link-Layer Timestamp) correspond à un tampon horaire de création. Une couche de liaison de données DUID-LL (DUID-Link-Layer, par exemple 00:03:00:01:$MAC) n'a pas de tampon horaire.

Pour plus d'informations sur l'utilisation de linuxrc, reportez-vous au manuel AutoYaST Guide (Guide d'AutoYaST). Consultez également man 4 initrd et la documentation pour les options dhcp4 "create-cid", dhcp6 "default-duid" dans man 5 wicked-config, wicked duid --help et wicked iaid --help.

18.2 Configuration d'un serveur TFTP

La procédure suivante explique comment préparer le serveur de façon à ce que les machines clientes dotées de UEFI et BIOS puissent démarrer à distance à l'aide des fichiers exportés par TFTP.

18.2.1 Installation d'un serveur TFTP

Pour installer un serveur TFTP, procédez comme suit :

  1. Installez le paquetage tftp.

    > sudo zypper in tftp
  2. Révisez la configuration tftpd dans /etc/sysconfig/tftp et ajoutez ou modifiez les options selon vos besoins. Pour plus d'informations, reportez-vous au man 8 tftpd. Le daemon TFTP fonctionne sans modifier la configuration. Le répertoire racine par défaut des fichiers est /srv/tftpboot.

  3. Assurez-vous que tftpd est lancé au moment du démarrage, puis redémarrez-le pour lire la nouvelle configuration.

    > sudo systemctl enable tftp.socket
    > sudo systemctl restart tftp.socket

18.2.2 Installation des fichiers de démarrage

SUSE Linux Enterprise Server fournit les fichiers requis pour un démarrage via PXE sur des machines BIOS ou UEFI. Les architectures matérielles suivantes sont prises en charge :

  • AMD64/Intel 64

  • AArch64

  • POWER

  • IBM Z

Les fichiers nécessaires au démarrage à partir d'une architecture matérielle spécifique sont inclus dans un paquetage de RPM. Installez-le sur la machine exécutant le serveur TFTP :

> sudo zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE

Remplacez OS_VERSION par la version de votre installation SUSE Linux Enterprise Server, par exemple, SLE-15-SP3-x86_64, et ARCHITECTURE par l'architecture de votre système, par exemple x86_64. Le texte obtenu ressemble à ceci : tftpboot-installation-SLE-15-SP3-x86_64. Exécutez zypper se tftpboot pour rechercher toutes les versions et architectures disponibles.

Les fichiers seront installés dans /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE. Vous pouvez également copier les fichiers des autres versions et architectures de SUSE Linux Enterprise Server dans le répertoire /srv/tftpboot.

Astuce
Astuce : diversité des architectures desservies

L'architecture matérielle client et serveur peut varier. Par exemple, vous pouvez exécuter un serveur TFTP AMD64/Intel 64 et fournir un environnement de démarrage pour les machines client AArch64 en installant le paquetage tftpboot-installation-SLE-15-SP3-aarch64.

Note
Note : répertoire /srv/tftpboot/ existant

Si le répertoire /srv/tftpboot/ existe déjà sur votre machine, tous les fichiers vont être installés à l'emplacement /usr/share/tftpboot-installation/. C'est le cas si vous mettez à niveau votre serveur PXE à partir d'une version précédente de SLES.

Pour résoudre ce problème, copiez les fichiers manuellement à partir de /usr/share/tftpboot-installation/ vers /srv/tftpboot/. Vous pouvez également supprimer /srv/tftpboot/ et réinstaller le paquetage tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE.

18.2.3 Configuration de PXELINUX

Ouvrez le fichier /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default dans un éditeur. Remplacez le chemin d'accès du paramètre install selon votre configuration, comme décrit dans le Chapitre 17, Configuration d'une source d'installation réseau. Remplacez également TFTP_SERVER (SERVEUR_TFTP) par l'adresse IP du serveur TFTP. Pour obtenir une vue d'ensemble des options de configuration PXELINUX, reportez-vous à la Section 18.3, « Options de configuration PXELINUX ».

default linux

# install
label linux
  ipappend 2
  kernel boot/ARCHITECTURE/loader/linux
  append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH

display  message
implicit 1
prompt  1
timeout  50

Pour plus de détails sur les paramètres de démarrage qui sont utilisés sur la ligne append, reportez-vous à la Section 8.3, « Liste des paramètres de démarrage importants ».

Si nécessaire, modifiez /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message pour afficher un message dans le menu de démarrage.

18.2.4 Préparation du démarrage PXE pour EFI avec GRUB2

Normalement, les fichiers de configuration GRUB2 ne nécessitent aucune modification. Toutefois, les paramètres par défaut n'incluent pas de ressource réseau pour le système d'installation. Pour effectuer une installation complète de SUSE Linux Enterprise Server via le réseau, vous devez spécifier le paramètre install dans l'instruction linuxefi du fichier /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg. Reportez-vous à la Section 8.3.3, « Spécification de la source d'installation » pour plus d'informations sur le paramètre install.

18.3 Options de configuration PXELINUX

Les options répertoriées à cet endroit constituent un sous-ensemble de toutes les options disponibles pour le fichier de configuration PXELINUX.

APPEND OPTIONS

Ajoute une ou plusieurs options à la ligne de commande du kernel. Celles-ci sont ajoutées pour les démarrages automatique et manuel. Les options sont ajoutées en tout début de ligne de commande du kernel ; en règle générale, elles peuvent être remplacées par les options de kernel entrées de manière explicite.

APPEND -

N'ajoute rien. APPEND suivi d'un seul tiret, utilisé comme argument dans une section LABEL peut servir à remplacer un APPEND global.

DEFAULT KERNEL_OPTIONS...

Définit la ligne de commande de kernel par défaut. Lorsque PXELINUX démarre automatiquement, il exécute les entrées spécifiées, en ajoutant à la fin l'option auto.

Si aucun fichier de configuration n'existe ou si aucune entrée DEFAULT n'est définie dans le fichier de configuration, la valeur par défaut est le nom de kernel « linux » sans la moindre option.

IFAPPEND FLAG

Ajoute une option spécifique à la ligne de commande du kernel en fonction de la valeur FLAG. L'option IFAPPEND est disponible uniquement sur PXELINUX. FLAG attend une valeur, décrite dans le Tableau 18.1, « Options de ligne de commande de kernel générées et ajoutées en provenance de IFAPPEND » :

Tableau 18.1 : Options de ligne de commande de kernel générées et ajoutées en provenance de IFAPPEND

Argument

Ligne de commande de kernel générée/Description

1

ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK

Les marques de réservation sont remplacées en fonction de l'entrée du serveur de démarrage PXE ou DHCP/BOOTP.

Notez que cette option ne remplace par l'exécution d'un client DHCP sur le système démarré. En l'absence de renouvellements réguliers, le bail obtenu par le BIOS PXE arrive à expiration, ce qui permet au serveur DHCP de réutiliser l'adresse IP.

2

BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE

Cette option se révèle particulièrement utile pour éviter les timeouts lorsque le serveur d'installation sonde les interfaces LAN les unes après les autres jusqu'à ce qu'il obtienne une réponse d'un serveur DHCP. Cette option permet à un programme initrd de déterminer l'interface à partir de laquelle le système a démarré. linuxrc lit cette option et utilise cette interface réseau.

4

SYSUUID=SYSTEM_UUID

Ajoute des UUID en hexadécimales minuscules ; voir /usr/share/doc/packages/syslinux/pxelinux.txt.

LABEL LABEL KERNEL IMAGE APPEND OPTIONS...

Indique que si LABEL est entré comme étant le kernel à démarrer, PXELINUX doit démarrer à la place IMAGE et les options APPEND spécifiées doivent être utilisées. Elles remplacent celles qui sont spécifiées dans la section globale du fichier avant la première commande LABEL. La valeur par défaut de la variable IMAGE est identique à celle de LABEL ; si aucune option APPEND n'est fournie, l'entrée globale (le cas échéant) est utilisée par défaut. Vous pouvez utiliser jusqu'à 128 entrées LABEL.

PXELINUX utilise la syntaxe suivante :

label MYLABEL
  kernel MYKERNEL
  append MYOPTIONS

Les libellés sont tronqués comme s'il s'agissait de noms de fichiers et ils doivent être uniques après cette opération. Par exemple, les deux libellés « v2.6.30 » et « v2.6.31 » ne pourraient pas être différenciés sous PXELINUX car, une fois tronqués, ils portent tous deux le même nom de fichier DOS.

Le kernel ne doit pas nécessairement être un kernel Linux. Il peut également s'agir d'un secteur de démarrage ou d'un fichier COMBOOT.

LOCALBOOT TYPE

Sous PXELINUX, si vous remplacez une option KERNEL par LOCALBOOT 0, vous appelez ce libellé précis et entraînez le démarrage du disque local et non du kernel.

Argument

Description

0

Effectue un démarrage normal.

4

Effectue un démarrage local avec le pilote UNDI (Universal Network Driver Interface - Interface de pilote réseau universelle) qui réside toujours en mémoire.

5

Effectue un démarrage local avec l'intégralité de la pile PXE, y compris le pilote UNDI, qui réside toujours en mémoire.

Aucune autre valeur n'est définie. Si vous ne savez pas à quoi correspondent les piles UNDI et PXE, indiquez 0.

TIMEOUT TIME-OUT

Indique la durée d'attente (en 1/10e de seconde) dans l'invite de démarrage, avant que le démarrage automatique soit lancé. Le timeout est annulé dès que l'utilisateur commence à saisir des données ; le système considère que l'utilisateur va terminer la commande initiée. Un timeout de zéro désactive entièrement le timeout (il s'agit également de la valeur par défaut). La valeur maximale de timeout est 35 996 (un peu moins d'une heure).

PROMPT flag_val

Si l'option flag_val a pour valeur 0, l'invite de démarrage apparaît uniquement si vous appuyez sur la touche Maj ou Alt, ou si la fonction Verr. maj ou Arrêt défil est définie (comportement par défaut). Si flag_val a la valeur 1, l'invite de démarrage s'affiche toujours.

F2  FILENAME
F1  FILENAME
..etc..
F9  FILENAME
F10 FILENAME

Affiche le fichier indiqué à l'écran lorsque vous appuyez sur une touche de fonction à l'invite de démarrage. Cette option peut être utilisée pour implémenter l'aide en ligne sur le pré-lancement (normalement pour les options de ligne de commande du kernel). Afin d'assurer une compatibilité avec les versions antérieures, vous pouvez également utiliser la touche 10 à la place de F0F. Il n'y a actuellement aucun moyen de lier les noms de fichiers aux touches F11 et F12.

18.4 Préparation du système cible pour le démarrage PXE

Préparez le BIOS du système pour le démarrage de l'environnement PXE en incluant l'option PXE dans l'ordre de démarrage du BIOS.

Avertissement
Avertissement : ordre de démarrage du BIOS

Ne placez pas l'option PXE avant le paramètre de démarrage du disque dur dans le BIOS. Le système essaierait sinon de se réinstaller chaque fois que vous le démarrez.

18.5 Utilisation de la fonction Wake-on-LAN pour les réveils à distance

Wake-on-LAN (WOL) est une norme Ethernet permettant de réveiller à distance un ordinateur en lui envoyant un signal de réveil sur un réseau. Ce signal est appelé « paquet magique ». Installez WOL sur les machines clientes pour activer les réveils à distance et sur chaque machine que vous souhaitez utiliser pour envoyer le signal de réveil. Le paquet magique est diffusé sur le port UDP 9 à l'adresse MAC de l'interface réseau sur la machine cliente.

Lorsque les ordinateurs sont arrêtés, ils ne sont généralement pas complètement éteints, mais restent en mode faible consommation. Lorsque l'interface réseau prend en charge WOL, elle écoute le signal de réveil par paquet magique lorsque la machine est éteinte. Vous pouvez envoyer le paquet magique manuellement ou planifier des réveils dans un travail cron sur la machine d'envoi.

18.5.1 Conditions préalables

WOL fonctionne avec les cartes Ethernet filaires et sans fil qui le prennent en charge.

Vous devrez peut-être activer WOL dans le BIOS/UEFI de votre système.

Vérifiez vos paramètres BIOS/UEFI pour le démarrage PXE et assurez-vous qu'il est désactivé pour éviter les réinstallations accidentelles.

Ajustez votre pare-feu pour autoriser le trafic sur le port UDP 9.

18.5.2 Vérification de la prise en charge de l'Ethernet filaire

Exécutez la commande suivante pour contrôler si une interface Ethernet filaire prend en charge WOL :

> sudo ethtool eth0 | grep -i wake-on
Supports Wake-on: pumbg
Wake-on: g

L'exemple de sortie montre que eth0 prend en charge WOL, indiqué par le drapeau g sur la ligne Supports Wake-on (Prend en charge Wake-on). Wake-on: g indique que WOL est déjà activé, de sorte que cette interface est prête à recevoir des signaux de réveil. Si WOL n'est pas activé, activez-le avec cette commande:

> sudo ethtool -s eth0 wol g

18.5.3 Vérification de la prise en charge de l'interface sans fil

Wakeup-over-Wi-Fi (WoWLAN), nécessite une interface réseau sans fil prenant en charge cette fonctionnalité. Pour vérifier si c'est le cas, effectuez un test avec la commande iw, fournie par le paquetage iw :

> sudo zypper in iw

Recherchez le nom de votre périphérique :

> sudo iw dev
phy#0
        Interface wlan2
                ifindex 3
                wdev 0x1
                addr 9c:ef:d5:fe:01:7c
                ssid accesspoint
                type managed
                channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
                txpower 20.00 dBm

Dans cet exemple, le nom du périphérique à utiliser pour vérifier la prise en charge de WoWLAN est phy#0. Cet exemple montre qu'il n'est pas pris en charge :

> sudo iw phy#0 wowlan show
command failed: Operation not supported (-95)

Cet exemple montre une interface qui prend en charge WoWLAN, mais pour laquelle cette fonction n'est pas activée :

> sudo iw phy#0 wowlan show
WoWLAN is disabled

Activez-la :

> sudo iw phy#0 wowlan enable magic-packet
WoWLAN is enabled:
* wake up on magic packet

18.5.4 Installation et test de WOL

Pour utiliser WOL, installez le paquetage wol sur le client et les machines d'envoi :

> sudo zypper in wol

Installez le paquetage wol-udev-rules sur vos machines clientes. Ce paquetage installe une règle udev qui active automatiquement WOL au démarrage.

Obtenez l'adresse MAC de l'interface réseau sur la machine cliente :

> sudo ip addr show eth0|grep ether
link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff

Dans l'exemple de sortie, 7c:ef:a5:fe:06:7c est l'adresse MAC.

Arrêtez votre machine cliente et envoyez-lui un signal de réveil depuis un autre ordinateur sur le même sous-réseau :

> wol 7c:ef:a5:fe:06:7c

Si votre machine cible et votre deuxième périphérique se trouvent sur le même réseau mais dans des sous-réseaux différents, spécifiez l'adresse de diffusion de votre machine cible :

> wol -i 192.168.0.63 7c:ef:a5:fe:06:7c

Étant donné que WOL repose sur des domaines de diffusion, la machine d'envoi doit se trouver sur le même réseau, même si elle peut se trouver dans un segment de réseau différent.

Il est possible d'envoyer le paquet magique à partir d'un autre réseau. Une méthode consiste à utiliser le transfert de port, si votre routeur prend en charge le transfert de port vers une adresse de diffusion. Une méthode plus sécurisée consiste à se connecter à un hôte à l'intérieur de votre réseau via SSH et à envoyer le paquet magique à partir de là.