Acceso vía NetBird y PowerShell Direct

Las VMs de sr250 corren el agente NetBird y son alcanzables por <host>.netbird.cloud (o su IP NetBird) desde cualquier peer de la malla, sin necesidad de VPN adicional ni de exponer el puerto 22 a internet. Cuando un peer no está disponible por NetBird — agente caído, o una VM que nunca se agregó como peer — sr250 sirve de puente porque es el host físico de Hyper-V de todas ellas.

PowerShell Direct como plan B

Invoke-Command -VMName "<nombre-vm-hyperv>" -Credential $cred desde sr250 llega a cualquier VM que esté encendida a través del VMBus del hypervisor, sin pasar por la red en absoluto. Funciona aunque el agente NetBird de la VM esté detenido, aunque el firewall bloquee todo, o aunque la VM no tenga un peer NetBird registrado — es la única vía de acceso a vm-test, que no corre NetBird.

Nota: el nombre de VM en Hyper-V no siempre coincide con el hostname NetBird/Windows de la VM — ej. la VM RDS_Server en Hyper-V corresponde al host vm-rds, y la VM “Servidor de pruebas VM-TEST” tiene hostname de Windows MV-TEST (invertido). Get-VM en sr250 da el nombre real de Hyper-V a usar en -VMName.

SSH ProxyJump a la subred interna del vSwitch

Todas las VMs comparten la subred 10.10.20.0/24 del vSwitch de Hyper-V. Para probar autenticación SSH real de punta a punta en una VM que no responde por NetBird (a diferencia de PowerShell Direct, que solo permite manipular archivos), sr250 sirve como jump host hacia esa IP interna:

ssh -J Administrador@eri-sr250.netbird.cloud Administrador@10.10.20.X

En la config de SSH esto se resuelve con ProxyJump eri-sr250 en el bloque del host destino — ver el alias vm-test en ~/.ssh/config, la única VM que depende de este mecanismo porque no tiene peer NetBird propio.

Incidente — servicio Netbird detenido en vm-biotime y vm-mpro

El 2026-08-02 se encontró que ambas VMs no respondían por NetBird pese a estar encendidas y con red funcional — el servicio Netbird (Windows) estaba en estado Stopped a pesar de tener StartType: Automatic.

Revisando el Event Log (System) de vm-mpro con Get-WinEvent, el origen fue un reset abrupto de la VM el día anterior (2026-08-01, ~13:51–13:52): varios servicios sin relación entre sí — OpenSSH SSH Server, SQL Server Launchpad, SQL Server PolyBase y Netbird — se reportaron como “terminados de manera inesperada” (evento 7034) dentro de la misma ventana de segundos, seguido de un ciclo de apagado/arranque del sistema operativo (Microsoft-Windows-Kernel-General, eventos 13/12) a las 13:52. El evento Kernel-Power 41 asociado trae todos los parámetros de bugcheck en cero, lo cual es consistente con un reset externo de la VM (a nivel Hyper-V) y no con un crash real de Windows (un BSOD genuino trae un código de bugcheck distinto de cero). vm-biotime tuvo el mismo patrón casi al mismo tiempo (reinicio ~13:43), lo que sugiere un evento que afectó a ambas VMs a la vez, no algo específico de una sola — no se identificó la causa raíz de ese reset (no se revisaron los logs de VMMS del lado del host sr250 para este incidente).

Netbird no es el único servicio que se vio afectado por el reset, pero sí el único que no se recuperó solo: OpenSSH SSH Server volvió a arrancar limpio en el siguiente boot (es el comportamiento normal de un servicio Automatic en un boot limpio), mientras que el intento de arranque de Netbird inmediatamente después del reset (evento 7009, timeout de 30000 ms) falló y el servicio se quedó en Stopped sin ningún reintento posterior — se mantuvo así casi 24 horas hasta que se reinició manualmente. Netbird no tiene configuradas acciones de recuperación (reintentar al fallar) en el servicio de Windows, a diferencia de componentes como SQL Server PolyBase que sí las traen por default.

Fix aplicado: Start-Service Netbird en ambas VMs vía PowerShell Direct. Pendiente evaluar si vale la pena configurar acciones de recuperación en el servicio (sc.exe failure Netbird ... o el equivalente en Servicios de Windows) para que un futuro reset no deje el agente caído indefinidamente.

vm-dev como routing peer — reemplaza depender de los peers individuales

Hallazgo 2026-08-10: sr250, vm-rds, vm-contpaq, vm-mpro y vm-biotime nunca se migraron a la cuenta nueva de NetBird (la migración del 2026-08-09 documentada en NetBird cubrió solo los hosts de la cuenta personal — pop-os, vm-playground, vm-main, vm-backup, vm-personal). Sus peers siguen registrados en la cuenta vieja, así que no aparecen en absoluto en netbird status desde ningún host ya migrado a la cuenta nueva — no es que estén desconectados, es que ese peer no existe en la cuenta que se está consultando. Esto invalidaba en silencio los alias _ip del ~/.ssh/config de la flota (eri-sr250_ip, vm-contpaq_ip, vm-rds_ip, vm-biotime_ip, vm-mpro_ip), que apuntaban a IPs 100.124.x.x de esa cuenta vieja — daban timeout, no connection refused.

vm-dev (Ubuntu, 10.10.20.10) se dio de alta directo en la cuenta nueva y se configuró como routing peer de toda la subred del vSwitch, 10.10.20.0/24 — con eso, cualquier peer de la cuenta nueva (pop-os, vm-personal, etc.) puede llegar por IP a cualquier host de esa subred sin importar en qué cuenta de NetBird esté registrado su propio agente. Es la misma mecánica que ya usa pop-os para exponer la LAN de casa (ver NetBird § routing peer), aplicada aquí al vSwitch de Hyper-V.

Con esa ruta disponible, un barrido de ping a 10.10.20.0/24 desde pop-os (ya con el routing peer activo) confirmó las IPs locales reales de tres de los cinco hosts de la cuenta vieja:

• eri-sr250 → 10.10.20.207
• vm-contpaq → 10.10.20.6
• vm-rds → 10.10.20.5

vm-biotime y vm-mpro no respondieron a ese barrido — ni siquiera a nivel de ping, que no depende de NetBird ni de SSH. Puede ser el mismo patrón que el incidente de abajo (servicio Netbird caído tras un reset) o simplemente que estén apagadas; no se confirmó la causa. El ~/.ssh/config de la flota se actualizó para usar estas IPs locales directo como HostName de eri-sr250/vm-contpaq/vm-rds, quitando los _ip viejos; vm-biotime/vm-mpro se dejaron con su alias DNS de NetBird tal cual, con nota de que no se pudieron confirmar. Detalle de la reorganización completa del config en SSH config de la flota.

vm-test (10.10.20.55) sigue con ProxyJump eri-sr250 en el config — probablemente ya redundante ahora que vm-dev rutea toda la subred directo, pero no se cambió esta vuelta. Ojo si se prueba: su servidor SSH ofrece únicamente cifrados obsoletos (diffie-hellman-group1-sha1, diffie-hellman-group14-sha1), que un cliente OpenSSH moderno rechaza por default sin importar la ruta de red.

Véase también

• SSH por llave pública en las VMs de sr250 — el trabajo durante el cual se detectó que estas dos VMs no respondían por NetBird.
• NetBird — migración de cuenta del 2026-08-09 y el patrón de routing peer que usa vm-dev aquí.
• SSH config de la flota — dónde queda registrado el alias vm-dev y el resto de esta subred en ~/.ssh/config.