Despertar un PC de casa dormido por VPN: de dónde viene el paquete

Te conectas, el router responde y el equipo de escritorio sigue a oscuras. El túnel está bien; el paquete que habría despertado la máquina nunca llegó al segmento donde esta escucha. Si recorres el camino hacia atrás desde el router, ves dónde muere.

Tres dispositivos tienen tres trabajos. Confundirlos es la razón habitual por la que un intento de despertar da vueltas para siempre.

Empieza en el cliente remoto y sigue el camino

Desde una red de hotel te conectas al router de casa, que es el único extremo siempre activo de la imagen. Una petición de despertar escrita en tu portátil se convierte en tráfico de túnel normal, dirigido al destino que hayas nombrado. Ese destino decide todo lo que sigue.

Si la enviaste a la dirección LAN del router de casa en el puerto del magic packet, el router puede aceptar el datagrama y no emitir nunca una trama en el segmento de casa, porque allí nada escucha ese puerto. Si la difundes dentro del túnel, se detiene en la interfaz del túnel. Un túnel enrutado no es una extensión de capa 2 del cableado de la casa. Sigue el camino salto a salto y el callejón sin salida se vuelve obvio.

La comprobación que lo resuelve necesita un comando desde el lado remoto y otro desde el lado de casa. Envía la petición y luego observa el segmento de casa en busca de la trama.

Mueve el emisor al segmento de casa

El router puede hacer el despertar él mismo una vez que te has autenticado por el túnel. OpenWrt documenta un servicio Wake-on-LAN que se ejecuta en el dispositivo y emite la trama localmente, que es exactamente la forma necesaria: autenticación remota fuera, difusión local dentro.

Ese arreglo también mantiene la función de despertar fuera de internet público. No se expone nada nuevo a internet, porque el disparador viaja por la VPN en la que ya confías. La alternativa, un servicio de despertar con puerto reenviado, cambia una pequeña comodidad por un extremo abierto a internet que cualquiera puede sondear.

La dependencia circular merece nombrarse sin rodeos. Un cliente VPN instalado en el escritorio no puede despertar ese escritorio, porque el proceso del cliente necesita la máquina en marcha. Mantén el punto de entrada remoto en el router o en otra caja siempre activa, y deja que el escritorio sea solo un objetivo.

Confirma el objetivo antes de culpar al túnel

Esta parte la decide el hardware, no la VPN, y el estado de energía la decide primero. El adaptador tiene que admitir el despertar, el firmware tiene que dejar el adaptador alimentado en reposo y el sistema operativo tiene que estar configurado para permitirlo. Una máquina suspendida es un caso distinto de una apagada, y ambas difieren de una máquina con la alimentación cortada en la pared. Resuelve ese estado antes de recorrer el resto de la lista.

Lee la dirección de hardware del adaptador que realmente recibirá la trama. Un escritorio con Ethernet y Wi-Fi suele tener dos direcciones, y puede que solo una sea capaz de despertar. El despertar inalámbrico es una capacidad aparte con sus propios requisitos de firmware, así que un despertar por Ethernet que funciona no dice nada sobre despertar por Wi-Fi.

Demuestra primero el camino local. Envía el magic packet desde otro dispositivo en el mismo conmutador y observa cómo arranca la máquina. Si eso falla, ninguna cantidad de depuración del túnel ayudará, y el fallo está en el firmware, en los ajustes del adaptador o en el estado de energía.

Tras reanudar, conéctate al servicio que querías

Despertar no es acceso remoto. Cuando la máquina se reanuda, todavía tiene que arrancar sus servicios, obtener una dirección y aceptar la sesión que de verdad necesitas. Dale tiempo para llegar a ese estado antes de concluir que el despertar ha fallado.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

La línea arp es la útil. Una entrada que pasa de incompleta a una dirección de hardware real significa que la máquina se reanudó y respondió; una petición que nunca se resuelve apunta de vuelta al paso de despertar, no al servicio que intentabas alcanzar.

Separa las etapas en tus notas: despertar, arranque, servicio. Un fallo en la segunda etapa parece idéntico a un fallo en la primera desde una ventana de chat, y solo la evidencia local los distingue.