4 · Seguridad·6 min de lectura

La cuenta que Google apagó

8 sep 2026SeguridadInfraestructuraIdentidad

«Tu cuenta se ha inhabilitado. Parece que esta cuenta se ha creado o usado con otras para infringir las políticas de Google.»

Esa cuenta era la dueña única del tailnet de Tailscale por el que una empresa entra a su servidor. Y la consola de administración de ese tailnet solo acepta iniciar sesión con Google.

La red no se cayó. Se quedó sin quien la mandara.

Lo que pasa cuando el dueño desaparece#

Todo lo que ya estaba configurado siguió funcionando: el servidor en línea, las conexiones activas, los accesos compartidos. Lo que dejó de ser posible fue administrar:

  • No se puede agregar a nadie.
  • No se puede quitar a nadie. El día que alguien deje la empresa, su acceso se queda.
  • No se pueden cambiar reglas ni agregar equipos.

No los tumba. Los congela, que a mediano plazo es peor porque no se nota hasta que hace falta.

Los intentos que no funcionaron#

Iniciar sesión con otro proveedor usando el mismo correo. Tailscale trata cada proveedor de identidad como una cuenta distinta, aunque la dirección sea idéntica. Entras a un tailnet nuevo y vacío, no al tuyo.

Cambiar el proveedor de identidad. La función existe — y exige ser Owner y estar dentro. La llave para arreglar la cerradura estaba dentro de la casa.

La cookie de sesión del navegador. Si alguien había abierto la consola antes, la sesión podía seguir viva y saltarse a Google. Pidió iniciar sesión.

Y en el intento, se perdió el servidor#

Al intentar cerrar sesión de Tailscale en el servidor para volver a entrar con otra cuenta, la llave del nodo caducó y el equipo salió de la red privada. Verificado desde fuera:

salida
servidor       offline, last seen 12m ago
ssh 100.x.x.x  Operation timed out
tailscale ping → peer's node key has expired
Las tres formas de alcanzar el servidor, y las tres fallando. La última es la que importa: la llave del equipo caducó, así que el servidor ya no puede volver a identificarse solo. Dejó de ser un problema de conexión y pasó a ser uno de identidad.

Lo único que permitió entrar a repararlo fueron las dos salidas alternas: AnyDesk instalado como servicio, y el escritorio remoto publicado en un puerto. Ambas probadas meses antes, precisamente para un día así.

Qué hicimos#

Un tailnet nuevo, con identidad dedicada. Cuenta de Microsoft creada solo para eso — no el correo público de la empresa, no una cuenta de Google. Y no bajo el dominio de la empresa: el tailnet viejo estaba registrado con ese dominio y Tailscale habría intentado meternos al bloqueado.

El servidor remontado por la salida de emergencia:

salida
tailscale up --reset --authkey=... --advertise-tags=tag:servidor --unattended
El comando que vuelve a inscribir el servidor en la red, con una llave nueva. Se tuvo que teclear físicamente frente al servidor, porque la vía para entrar de forma remota era justamente la que se había caído.

El \--unattended\ importa: hace que el equipo se conecte solo al arrancar, sin que nadie inicie sesión.

Caducación desactivada en el nodo. Eso es exactamente lo que falló: por omisión la llave caduca a los 180 días, y cuando caduca hay que renovarla desde una consola a la que quizá ya no puedas entrar.

Y un segundo administrador el mismo día. Aquí hay que ser preciso, porque nosotros nos equivocamos primero: Tailscale tiene un solo Owner y no admite dos. Lo que sí admite son varios Admin, y un Admin puede hacer todo en la consola — invitar, revocar, generar llaves. Con eso alcanza, porque lo que mató el día no fue la falta de un segundo dueño: fue que nadie podía entrar.

Dos cosas que no vimos venir#

La letra chica: Tailscale no deja transferir la propiedad si el tailnet usa un dominio compartido como \outlook.com\. Nuestra cuenta nueva es exactamente eso. Se compensa con varios Admin y blindando la cuenta dueña, pero hay que saberlo.

Y un dedazo casi cuesta caro: la primera invitación de administrador salió a un dominio con dos letras cambiadas. Ese dominio no existe y no pasó nada. Si alguien lo tuviera, le habríamos dado acceso de administrador a la red del cliente.

La causa de fondo#

Usaron el correo público de contacto —el que sale impreso en las cotizaciones, el que recibe spam, el que sirve para registrarse en cualquier cosa— como identidad de infraestructura.

Ese correo tiene un trabajo: que los clientes escriban. Ser dueño de la red no es ese trabajo.

Y la lección no es elegir un proveedor más confiable. Cualquiera puede apagar una cuenta mañana, sin explicar y sin apelación efectiva. Google, Microsoft, el que sea. Lo que hay que garantizar es que ninguna cuenta sea la única llave, y que la salida de emergencia esté instalada como servicio y probada antes de necesitarla.

Nosotros lo aprendimos el mismo día por partida doble: la segunda cuenta que Google deshabilitó era la nuestra.