La trampa de los dos tailnets: una clave antigua que editó la red equivocada
Los clientes llegan a su Mac alquilado por Tailscale. Guardamos la regla de acceso SSH en la política del tailnet y la gestionamos desde código. Cuando empieza un alquiler, se añade la dirección del cliente. Cuando termina, se quita. Es un sistema pequeño y aburrido. Hasta que nos dijo que todos los clientes habían perdido el acceso, y mentía.
Lo que dijo la herramienta
Una comprobación rutinaria anunció que la regla SSH de clientes estaba vacía. Según ella, tres clientes de pago ya no podían conectarse. Es un mensaje de alarma máxima para un negocio cuyo producto es el acceso a una máquina.
La regla no estaba vacía. Estábamos leyendo otro tailnet.
Dos redes, un alias
La cuenta tenía dos tailnets. Uno contiene la flota: los Mac alquilados, el hub y todo lo compartido con clientes. El otro era una red personal antigua que quedó de la puesta en marcha, con una máquina muerta y un portátil.
La API de Tailscale te deja nombrar un tailnet o pasar -, que significa "el tailnet al que pertenezca la clave que llama". Nuestro código pasaba -. Eso va bien hasta que hay dos claves. Las claves son cadenas imposibles de distinguir, así que - sigue sin avisar a la que esté en el entorno. Una clave antigua se había colado en un archivo de configuración.
Lo peligroso fue la escritura
Una lectura que miente te hace perder una tarde. Una escritura que miente provoca un incidente. La misma herramienta tiene un modo de reparación que ajusta la regla de acceso a los clientes actuales. Ejecutado contra el tailnet equivocado, escribió fielmente tres direcciones de correo de clientes reales en la política de la red antigua, donde no servían para nada.
Ningún cliente se vio afectado de verdad, porque el tailnet de la flota no se tocó y estuvo correcto todo el tiempo. Pero durante unos minutos la automatización estuvo editando el control de acceso de la red equivocada y anunciando que todo había ido bien.
La solución: nombrar la red
Dejamos de pasar -. Ahora el código nombra el tailnet de la flota de forma explícita. Una clave que no lo ve falla de forma ruidosa en lugar de desviarse hacia lo que sí puede ver.
Ahora cada ejecución muestra el tailnet con el que ha hablado. Si esa línea no es la flota, los resultados de debajo no significan nada, y lo sabes antes de actuar.
La lección general
Un valor por defecto cómodo que significa "lo que sea a lo que apunte esta credencial" es una trampa en cuanto tienes más de una credencial. Convierte una clave equivocada, que debería ser un error, en una redirección silenciosa. Todo lo que escribe debería nombrar su destino. Así, usar la credencial equivocada falla en lugar de funcionar en un sitio que no querías.
Tiene la misma forma que los otros fallos silenciosos que contamos en comprobaciones que no pueden fallar. La herramienta estaba segura. La herramienta se equivocaba. Y nada de lo que mostraba te lo habría dicho, hasta que nombró la red que estaba editando.
Preguntas
- ¿Cómo elige una clave de API de Tailscale qué tailnet edita?
- La clave pertenece a un tailnet, y el nombre de tailnet '-' de la API significa 'el tailnet al que pertenezca esta clave'. Dos claves de dos tailnets parecen idénticas, así que '-' sigue a la clave sin avisar.
- ¿Cómo se distinguen dos tailnets de forma segura?
- Nunca a ojo. Compara qué dispositivos puede listar cada clave. La clave correcta ve tu flota. La equivocada ve lo que sea que tenga esa cuenta.
- ¿Deberían las herramientas usar el alias de tailnet '-'?
- No para nada que escriba. Nombra el tailnet de forma explícita, para que una clave de la red equivocada falle con un 404 en lugar de editar en silencio la ACL equivocada.
Haz tus propias cuentas con la calculadora o alquila un runner.