Tailscale: permisos que se pueden explicar

Estar en la tailnet no alcanza

El primer prototipo suele conectar dos dispositivos y celebrar que se ven. Para operar un entorno con agentes, VPS y paneles internos hace falta una pregunta más precisa: ¿qué identidad puede iniciar una conexión a qué destino y en qué puerto?

Tailscale recomienda grants para expresar esos permisos. Cada grant define src, dst y capacidades de red (ip) o de aplicación (app). Las conexiones que no tengan una regla que las permita quedan denegadas; atención, porque una tailnet recién creada suele traer una política inicial allow all. Hay que revisar y reemplazar esa regla amplia antes de dar por hecho el mínimo privilegio. Grants · Política inicial y ACL

Dibujar la política antes del archivo

Supongamos una notebook, un host de desarrollo y una VPS. El objetivo es notebook → host por SSH, host → VPS por HTTPS, y ningún acceso de la notebook a la base de datos de la VPS. Esa matriz se puede revisar sin conocer la sintaxis de HuJSON.

Una forma esquemática de llevarla a grants sería:

{
  "tagOwners": {
    "tag:dev-host": ["autogroup:admin"],
    "tag:internal-api": ["autogroup:admin"]
  },
  "grants": [
    {
      "src": ["persona@ejemplo.com"],
      "dst": ["tag:dev-host"],
      "ip": ["tcp:22"]
    },
    {
      "src": ["tag:dev-host"],
      "dst": ["tag:internal-api"],
      "ip": ["tcp:443"]
    }
  ]
}

Es un ejemplo para adaptar: los nombres y la identidad son ficticios; los tags sólo tienen sentido si los dispositivos tienen esas etiquetas asignadas. Antes de aplicar una política real, revisá los grants y ACL existentes: una regla amplia que permanezca activa puede seguir habilitando tráfico. Las políticas permiten sumar accesos, no escribir una regla deny para restar los que otra ya concedió. Sintaxis de grants · Tags

El src por correo identifica al usuario, no exclusivamente a su notebook: también puede habilitar sus otros dispositivos con identidad de usuario. Para limitarlo a una sola máquina, usá un selector de dispositivo, como su IP de Tailscale o un alias hosts, y verificá el alcance en la vista previa. Selectores de grants

SSH tiene dos modos de operación

SSH habitual sobre Tailscale conserva sshd, usuarios y claves SSH del host; la tailnet aporta una ruta privada y el grant habilita el puerto. Tailscale SSH deja que Tailscale gestione autenticación y autorización SSH en nodos compatibles, con sus propias reglas ssh y opciones como check. Activar sólo el grant de TCP 22 no equivale a haber configurado Tailscale SSH. Tampoco sirve para hacer Tailscale SSH hacia una máquina que sólo está detrás de un subnet router. Tailscale SSH

Si ya existe un flujo SSH que funciona para Orca, el primer paso puede ser conservarlo y limitar la ruta. Una migración a Tailscale SSH merece su propia prueba de usuarios, sesiones y recuperación.

Probar que el límite existe

Primero usá Preview rules para inspeccionar los destinos que ve una identidad y agregá tests de política para las conexiones esperadas. Después probá desde un dispositivo real: SSH al host permitido y conexión al puerto restringido de un destino que esté encendido y escuchando. Un timeout hacia una máquina apagada no demuestra que un grant esté funcionando. Editar y previsualizar políticas

Para diagnosticar, tailscale ping --tsmp verifica conectividad antes de comprobar la política; tailscale ping --icmp verifica conectividad incluyendo las reglas. Si ambos pasan pero la aplicación falla, revisá el puerto, el servicio y sus permisos. Para el puerto concreto, probá el protocolo real: un ping no verifica que TCP 22 o 443 esté habilitado. Diagnóstico de políticas

El resultado que queremos poder escribir en una línea es: «esta identidad llega a este servicio por este puerto; a aquel otro no». Con esa política lista, el caso de un entorno con agentes muestra dónde ubicar cada conexión.