Bienvenidos al blog del Capitán Malaspina y sus secuaces donde encontrarás reflexiones sobre ciencia, tecnologia, informática y otras cosas de pensar.

22 noviembre 2013

Errores Ocultos en Wake On Lan / Wake On Wan (rev.3)



Si a Don Quijote se le fundían los sesos, a todos nosotros alguna vez se nos han frito tratando de resolver un problema informático que nos traía de cabeza. Y si además veíamos que los demás conseguían con facilidad lo que a nosotros tanto nos costaba lograr, ya es que se nos carbonizaban (si cambiar la "r" de lugar, oigan). Éste que les cuento era el mío particular desde hace mucho, mucho, mucho tiempo, y no es un cuento aunque comience como si lo fuera ("A long, long time ago, there was a little psico-informatic man who had a problem with his computer ..."). Bueno, que me congratulo en poderles contar la solución, aunque me temo que a pocos de ustedes les venga a cuento. Les adelanto que el tema es algo complejo, pero no por ello deja de ser interesante, y les aseguro que hay mucha gente con este mismo problema que no han conseguido solucionarlo aún.

Empezando

 Les pondré en situación: Ustedes saben que es posible poner un ordenador en modo "supensión de energía" (S3) o también en "hibernación" (S1). En estos estados la máquina consume una cantidad ínfima de electricidad ahorrándonos un piquito en la factura de la luz. Para activarla basta mover el ratón o tocar una tecla. Entonces se produce un rápido arranque y en segundos volvemos a tener el ordenador operativo tal como lo dejamos la última vez sin que tengamos que esperar a que se cargue Windows o Linux o el S.O. que sea, ni lanzar el antivirus de nuevo ni esperar a que se lancen otros procesos y servicios. Realmente lo que hacemos es apagar el ordenador pero seguir alimentando eléctricamente la memoria, la cpu y los puertos ps/2 o usb para que detecten cambios puedan reactivar la máquina.

Esto que podemos hacer "in situ", también es posible hacerlo en remoto, desde otra ubicación distinta gracias a internet. Es bastante útil poder operar con ella a distancia  usando ssh, vnc, ftp, etc. (ejem, .. "etc" no es un protocolo de comunicaciones, es una abreviatura del latín "et cétera" que significa "y todo lo circundante"). Así no sería preciso tenerla encendida continuamente 24h/7d por si nos hiciera falta en algún momento, sino que la dejaríamos "en suspensión" y solamente la activaríamos cuando la necesitáramos, evitándonos el exceso de consumo eléctrico. La máquina volvería ella solita a su estado de suspensión tras pasar un tiempo sin actividad si la preparamos adecuadamente

Esa operación se conoce como WOL (Wake On Lan, si se hace desde dentro de la misma red local), o WOW (Wake On Wan si se hace desde internet), y se realiza enviando por la red un mensaje especial destinado al ordenador que queremos despertar llamado "Magic Packet" que contiene la dirección MAC de la tarjeta de red del equipo que tenemos en suspensión y queremos activar.

Esto tan bonito en la teoría no siempre funciona en la práctica. En particular a mí no me funcionaba y  los siguientes


Síntomas:


Tras entrar en estado de suspensión de energía (S1 o S3), el equipo podía ser reactivado enviándole un "Magic Packet" si no hacía mucho tiempo de la entrada en suspensión. Al pasar algo más de tiempo (pongamos un cuarto de hora) era imposible reactivarlo, ya fuera desde la propia lan o desde un equipo situado en internet. Al hacer una comprobación con el equipo activado con un detector de Magic Packets (un sniffer), éste me mostraba que los paquetes mágicos entraban con toda normalidad por la tarjeta de red, por lo que todo parecía estar bien configurado y no había motivo de fallo.

Éste es sin duda uno de los problemas que más quebraderos de cabeza ha proporcionado a los que han querido hacer despertar a su ordenador. El esforzado usuario lo ha configurado todo, absolutamente todo. Ha activado el APM en la BIOS y el "Wake On Ring" o "Wake On Lan" de su ordenador, ha dejado que Windows o Linux mantengan la tarjeta de red con un hilillo de corriente para que pueda responder a los paquetes mágicos, ha asignado en su router una IP fija a su tarjeta de red, ha hecho el "port-forwarding" correctamente en el router desviando los puertos UDP 7 y 9 hacia esa ip reservada, ha comprobado incluso que los paquetes entran teniendo el equipo encendido, ha probado en otros equipos con resultados dispares, pero no ha encontrado la solución al problema de por qué su equipo sigue en modo "Bella Durmiente", no hace caso de la "magia paquetera", y se niega a activarse aun cuando todo funciona correctamente. Le faltaba visitar la página de Capitán Malaspina.



Explicación :

Los Magic Packets

Como se ha dicho antes, para conseguir que un equipo despierte, se le manda un Magic Packet . El envío se hace por el puerto UDP 7 o UDP 9 a la red donde está conectado y como identificador del destinatario se indica la MAC de la tarjeta de red del equipo. El Magic Packet contiene la dirección de broadcast de la red "FF FF FF FF FF FF" seguido de 16 repeticiones de la dirección MAC del destinatario. ¿Cómo sabe el router hacia dónde ha de desviar el paquete?. Para ello existen un par de mecanismos.

La Nat
En primer lugar está la tabla NAT (Network Address Translation) que indica que los paquetes que se reciban a través de un puerto del router, sean desviados hacia otro puerto de otra IP. Si la tarjeta de red del ordenador que queremos levantar tiene asignada la IP "192.168.0.200" y los Magic Packets los enviamos por el puerto UDP9, la NAT tendría alguna regla parecida a:

External Port Start: UDP 9 End: UDP 9
Destination IP: 192.168.0.200
Internal Port Start: UDP 9 End: UDP 9

O sea: "todos los paquetes recibidos por los puertos del 9 al 9 serán redirigidos a los puertos del 9 al 9 del ordenador cuya IP es 192.168.0.200"

¿Y cual es el ordenador que tiene esa IP?

La ARP
En nuestra ayuda viene la caché ARP (Address Resolution Protocol) del router, que registra las direcciones MAC de las tarjetas de red y las IP que tienen asignadas. Si el ordenador (su tarjeta de red) tiene la dirección física MAC "00:AA:11:BB:22:CC", el router consultará la tabla ARP y sabrá que el paquete que va a la IP 192.168.0.200 tiene que ser remitido a la dirección física de la red  "00:AA:11:BB:22:CC". La tabla ARP es meramente una tabla que registra parejas de valores (IP, MAC) y otros datos asociados a ese emparejamiento.

Protocolo de Asignaciones de IP
Normalmente los routers incorporan un servidor DHCP (Dynamic Host Configuration Protocol) que se encarga de asignar las direcciones IP disponibles conforme se las van solicitando los dispositivos que se conectan a la red. La forma de asignación es por orden de llegada y de esta forma, al primero que lo solicita se le da la primera IP que haya libre.

El espacio de direcciones que tiene disponibles un router en la red es finito y puede acabarse. Por ello los routers tienen un mecanismo que libera direcciones IP ya asignadas cuando sus usuarios no las necesitan. Para conseguirlo hacen un barrido de vez en cuando a fin de comprobar qué equipos están conectados y cuáles no.  Basta un "ping" a cada IP registrada en la ARP para saber si hay respuesta de esa IP. Si no la hay es porque el equipo correspondiente está apagado (o suspensión de energía), y entonces el servidor DHCP elimina la entrada de esa IP en la tabla ARP, dejándola disponible para otro equipo que pueda solicitar acceso a la red.

Esto no suele ser un problema cuando sólo hay un equipo conectado al router, ya que siempre recibirá la misma IP. En cambio, cuando se trata de una red de varios equipos, podemos tener cualquier IP en el equipo al que queremos despertar. Imagine por ejemplo una red casera con dos ordenadores y un reproductor de contenidos en el salón conectados por cable ethernet, y mediante wifi un portátil, un par de smartphones, y un par de tablets. Según se encienda antes uno u otro le corresponderá una u otra IP y nada nos garantiza que el equipo a despertar tenga siempre la misma dirección. 

Regresando a nuestro caso, establecimos que los Magic Packets viajaran al puerto UDP 9 de la IP 192.168.0.200. Pero ¿Qué ocurre si, debido a este funcionamiento del DHCP, esa IP pertenece a otro equipo de la red? ¡Pues que el Magic Packet no llega a la MAC destino!. En realidad no llega a ningún sitio, porque para que WOL funcione, la MAC que contiene el paquete tiene que coincidir con la MAC del equipo destino.

Hacer una Reserva de IP
En nuestra ayuda viene de nuevo la caché ARP y el servidor DHCP, ya que nos permite "reservar" ciertas IP para determinados equipos de la red. Es como si fueran direcciones IP de tipo "VIP", que están reservadas sólo para determinados clientes (o sea, para determinadas MAC). Cada vez que el router recibe una solicitud de IP proveniente de la NIC (Network Interface Card, tarjeta de red) de un equipo que acaba de ponerse en marcha, el servidor DHCP del router comprueba la MAC de esa NIC en su lista de reservas. Si detecta que la MAC de la tarjeta coincide con alguna de las que tienen reservada una IP específica entonces le asigna esa IP en lugar de cualquier otra que esté disponible. Ninguna otra MAC de la red puede usar esa IP reservada. 


Para hacer tal reserva casi todos los routers disponen de una opción en su interface preparada para tal fin, de forma que al usuario de a pie le sea fácil realizar estas reservas de IP.

Con esto, el problema parece resuelto, ya que reservaríamos la IP 192.168.0.200 a nuestra dirección MAC 00:AA:11:BB:22:CC asegurándonos así que todos los paquetes que entren al router por el puerto UDP 9 serán reinyectados al puerto 9 de nuestro ordenador.

El camino que sigue el paquete mágico cuando el equipo está activado es, de forma abreviada y sencilla:
  1. El router recibe un Magic Packet por el puerto 9
  2. La NAT instruye al router a que reenvíe ese paquete al equipo cuya dirección IP es 192.168.0.200 usando el mismo número de puerto, el 9.
  3. Para hacerlo físicamente, el router necesita usar una dirección MAC, y por ello busca una coincidencia en la tabla ARP para esa  IP, averigüando que le corresponde la MAC  00:AA:11:BB:22:CC
  4. El router comprueba que la MAC del Magic Packet coincide con la MAC informada por la ARP y reenvía el paquete a esa dirección MAC
Pero ¿Qué ocurre si el equipo que tiene esa MAC está apagado o en suspensión?. 

Debido al barrido que hace el router para detectar equipos desconectados y liberar direcciones IP, pasado un tiempo tras la suspensión de nuestro equipo su IP es liberada y su MAC deja de estar presente en la caché ARP.

O sea, que la IP sigue estando reservada, pero al no estar activo el equipo, su MAC no aparece en la tabla ARP y el paquete es desechado por el router y no llega a su destino.

Este es el motivo por el que podemos "levantar" un equipo a los pocos minutos de haber entrado en suspensión, pero no podemos hacerlo cuando ha pasado más tiempo: su MAC ha desaparecido de la tabla ARP con el barrido de IP que ha hecho el router.

Entiendan ahora la desesperación del usuario cuando tras configurar todo el sistema comprueba que funciona y pasado un tiempo, sin que él haya tocado nada, deja de funcionar sin ningún signo externo que le haga intuir el origen del fallo.

El ejemplo más claro lo tenemos cuando el servicio de mensajería no puede entregarle un envío porque usted está durmiendo la siesta y no está pendiente del timbre. El mensajero sabe a dónde tiene que dirigirse por las señas del destinatario que hay en el envío, pero no puede entregáselo porque usted no contesta y éste le supone ausente. Si al menos hubiera tenido su número móvil podría haberle avisado. Bien pues su número móvil es su MAC, su dirección postal es su IP, y el mensajero es el router. Cuando la IP reservada no tiene una MAC preasignada, los paquetes no pueden entregarse cuando usted está durmiendo. Así de sencillo.

Solución: "Asignar" en lugar de "Reservar"

Por suerte, alguien antes que nosotros fue presa de la misma desesperación, halló el origen del problema y diseñó una solución efectiva: en lugar de "reservar" esa IP a esa MAC, diseñó un método para "asignar" permanentemente la IP con su MAC de forma que aunque el router hiciera el barrido de IP inactivas, respetara esa en particular y no la borrase de la caché ARP. Es lo que se conoce como crear una asignación estática en la caché ARP. 

En nuestro símil sería como si el mensajero supiera su número de teléfono móvil: entonces le llamaría avisándole de la entrega del paquete, y usted se despertaría y abriría la puerta. Pero fíjese que en este caso el mensajero sí sabe dónde localizarlo, o sea, que conoce su IP y conoce su MAC de antemano, y la usa para poder entregarle el sobre: tendríamos que disponer de algún sistema donde guardar de forma permanente las asignaciones IP<->MAC

Por suerte para nosotros eso es fácil de solucionar. Es algo tan simple como entrar por telnet al router y hacer una asignación estática en la tabla ARP mediante el comando del mismo nombre (arp):

a) Primero, eliminamos la reserva e IP, si es que ya la teníamos hecha antes desde la interfaz web, ya que lo que queremos no es una "reserva", no una asignación estática:

               arp delete 192.168.0.200
b) Luego, reasignamos la IP desde la línea de comandos, consiguiendo -ahora sí- una asignación estática


               arp add -s 192.168.0.200 00:AA:11:BB:22:CC 

(La sintaxis dependerá del intérprete de Linux que el fabricante haya instalado en el router y de la implementación de arp que contenga. ¡Oh sí!, por supuesto aquí también está presente nuestro viejo amigo Torvalds, que ha conseguido que su nombre figure en millones de equipos)


¿Cómo saber si hemos hecho una reserva de IP o una asignación estática?. Pues mirando el campo "Flags" cuando solicitamos información de la ARP  (arp show).  En el router Comtrend AR5381u de Jazztel y en el Observa Telecom VH4032N de Vodafone una asignación estática se identifica con el flag 0x6:

&gt; arp show
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.128    0x1         0x6         bc:ae:c5:47:90:87     *        br0
192.168.1.129    0x1         0x0         34:15:9e:42:a5:31     *        br0

Pero estos valores pueden ser diferentes según el equipo que se trate y la implementación que hayan hecho del comando arp. En algunos equipos una entrada estática tiene como flag la letra "s" o la palabra “static”. Tendrá que comprobar en su equipo cómo se identifica una asignación estática. Le sugiero que conecte varios equipos al router y compruebe que solo uno de ellos tiene un flag distinto al de los demás: justo al que usted asignó una dirección IP estática.



Final (o el comienzo de más problemas)

En todo este artículo se supone que el router marca "D-kk" que les ha enviado su proveedor de internet es accesible por telnet o ssh. Puede ocurrir que estos protocolos de acceso estén cerrados al usuario normal  y no podamos hacer el proceso descrito antes con el comando arp (ejemplo: Vodafone los cierra ambos, telnet y ssh para evitar que se trastee con el aparatito). La solución es llamar al servicio técnico y solicitarles la asignación de una entrada estática en la tabla ARP del router. Muchos de los supuestos técnicos que les atenderán les dirán que eso se puede hacer desde la interfaz web. Tienen que contestarles que no, que por la interfaz web sólo se consigue una reserva, pero no una asignación estática, y que ésta hay que hacerla por telnet o ssh. Si se hace por la interfaz web, esa supuesta asignación se pierde a los pocos minutos de haber apagado la máquina y eso no nos vale. Les costará unos cuantos cuartillos de hora hacerse entender, y a lo peor unas docenas de llamadas telefónicas hasta dar con el técnico que lo sea de verdad, les entienda y lo haga bien, pero se puede hacer. 

Refinal

Creo sinceramente, que lo mejor es que se busquen ustedes un router neutro y prescindan del de su proveedor. En internet se pueden encontrar buenos router Linksys, Netgear y Asus por módicos precios que les aliviarán de todas estas visicitudes con los proveedores de internet. Tan sólo tendrán que dejar el aparato del ISP en modo bridge y usar su propio router para administrar su red. Por cierto, si son capaces de instalarles un firmware de la familia DD-WRT van a ganar mucha, pero que mucha funcionalidad.

Espero haberles despejado la duda y facilitarles ese tan ansiado sueño que no lograban conciliar por no poder encender remotamente el equipo.

Saludos, Pulsar.


P.D. Disculpen la tardanza en la escritura y publicación. La maldita crisis me tiene sorbidos los cerebros y no hago otra cosas que pensar en como escapar de ella. Esto de hoy ha sido propiamente dicho un "escapismo". Confiemos en que las cosas vuelvan a su cauce y nuestras mentes, libres de tribulaciones, vuelvan a relajarse divagando para encontrar nuevas soluciones.

Revisado el 10.05.2018
Pulsar Informaticks.