Tailnet · setup y uso del staff

🗄️ PÁGINA ARCHIVADA (obsoleta desde 2026-05-25, s85). Tailscale fue retirado y sustituido por NetBird. Esta página se conserva solo como histórico — no la sigas para configurar accesos. Guía vigente: claude-method/guides/NETBIRD_SETUP.md + runbooks [[runbook—infra—netbird-proxies]] y [[runbook—infra—hetzner-firewall-solo-netbird]]. Inventario de servidores: memoria infra_servers.md.

Quién: todo el staff de CreaRackSL (Edu, Dani, Txell). Cualquiera con laptop del proyecto. Por qué: el tailnet CreaRackSL@ es la red privada cifrada que conecta todo el staff con los servers de infraestructura (PROD, STAGE) sin exponer puertos al internet público. Todo el acceso operativo a infra pasa por aquí. Cuándo lo necesitas: cuando recibes laptop nuevo del proyecto, cuando tengas que ssh/curl/conectar a un server CreaRack, cuando haya algún problema de conectividad.

¿Qué es el tailnet de CreaRackSL?

Una red privada virtual basada en Tailscale (capa sobre WireGuard). Todos los nodos autenticados con la cuenta CreaRackSL@ se ven entre sí por IPs internas (rango 100.64.0.0/10) y nombres DNS (MagicDNS), sin que esos puertos estén expuestos al internet público. El tráfico va cifrado punta a punta, peer-to-peer cuando se puede.

Ventajas operativas:

• ssh por nombre desde cualquier sitio: ssh root@crearack-prod (sin IPs, sin VPN clásica, sin lista blanca de IPs)
• VictoriaMetrics, PostgreSQL y panel Dokploy accesibles desde tu laptop sin tunneling
• Cero superficie de ataque pública: el :22 SSH ya no necesita estar abierto al mundo
• Cambias de cafetería, casa o cliente y sigue funcionando — la IP pública desde la que sales no importa

Inventario de nodos (sesión 53 · 08-05-2026)

Tailnet name: taildbda17.ts.net (para FQDN MagicDNS).

Setup en laptop nueva del staff (Dani, Txell, Edu cuando reciba el suyo)

1. Pre-requisito · invitación al tailnet

Edu (admin del tailnet) tiene que invitarte primero desde el panel admin Tailscale → Users → Invite users con tu email. Recibirás email de invitación.

2. Instalar Tailscale en la laptop

Descargar e instalar el cliente oficial:

• Windows / macOS / Linux: tailscale.com/download
• En Windows el instalador queda en system tray.

3. Login con tu cuenta GitHub personal (Member del Org)

Tras instalar, el cliente abre navegador para auth.

• Login provider: GitHub
• Cuenta: tu cuenta GitHub personal como Member del Org CreaRackSL (Esquembri / dfuentes-esfericlabs / tfuentes-esfericlabs). Desde la migración a Organization (s74) el tailnet autoriza por pertenencia al Org, no por una cuenta compartida del proyecto.
• Aceptar permisos

4. Verificar conectividad

En PowerShell o terminal:

# Listar nodos del tailnet (deberías ver tu hostname + crearack-prod + crearack-staging + el resto)
tailscale status

# Ver tu IP Tailscale asignada
tailscale ip -4

# Ping a un server
ping crearack-prod

Si no resuelve por nombre, comprobar que MagicDNS esté activo (panel admin Tailscale → DNS → MagicDNS).

5. SSH al server

ssh root@crearack-prod
ssh root@crearack-staging

La primera vez te pedirá aceptar la host key — di que sí. La SSH key de la laptop tiene que estar autorizada en authorized_keys del server (Edu las añade cuando invita).

6. (Cuando se active Tailnet Lock) co-firmar tu nodo

Cuando Edu active Tailnet Lock, generarás tu signing key y firmarás los nodos existentes:

tailscale lock init                  # genera tu signing key personal
# Edu añade tu public key a Tailnet Lock desde panel admin
tailscale lock sign <node-id>        # co-firmar nodos existentes para que sigan siendo trusted

Detalles cuando llegue el momento.

Servicios accesibles desde el tailnet (PROD)

Todos los servicios del PROD también están en STAGE con crearack-staging:

• crearack-staging:3000 Dokploy panel STAGE (mismo pero con BD de testing)
• crearack-staging:8428 VictoriaMetrics STAGE
• crearack-staging:5432 PostgreSQL STAGE

Cómo está configurado el tailnet

MagicDNS

Activo. Resuelve crearack-prod → 100.126.106.56 automáticamente. No hace falta tocar /etc/hosts ni recordar IPs.

ACLs (Access Controls)

JSON guardado en panel admin Tailscale → Access controls. Resumen funcional:

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:*"]}
  ],
  "ssh": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server"], "users": ["root"]}
  ]
}

Significado en cristiano:

• Solo los admins del tailnet (Edu) pueden aplicar tag:server a una máquina nueva
• Cualquier miembro del tailnet (autogroup:member) puede acceder a cualquier puerto de los servers tagged
• Cualquier miembro del tailnet puede ssh como root a esos servers

Si el equipo crece con miembros que NO deben tener acceso completo a infra (ej. un becario), se cambia autogroup:member por un group:staff específico con la lista de emails autorizados.

Tailnet Lock

⏳ Diferido a la sesión donde lleguen los laptops nuevos del staff. Co-firmar los nodos requiere que cada miembro tenga su signing key local — más sentido aplicarlo con el equipo completo y los equipos nuevos en uso.

Cuando se active, los nodos nuevos requerirán firma criptográfica de un nodo existente para entrar al tailnet, incluso si la cuenta GitHub CreaRackSL@ se compromete.

Servicios docker → tailnet (proxy socat)

Los servicios que viven en docker network (VictoriaMetrics, PostgreSQL) NO están directamente en el tailnet. Se exponen vía un proxy socat en el host que escucha en la IP tailscale0 y forwardea al container.

Implementación: 2 systemd units por server (tailnet-vm.service y tailnet-pg.service) en /etc/systemd/system/. Cada unit ejecuta un script /usr/local/bin/tailnet-proxy-{vm,pg}.sh que resuelve la IP del container con docker inspect al arrancar y lanza socat bindeado a la IP tailnet.

Footgun: si Dokploy redeploya el stack y los containers cambian IP, hay que systemctl restart tailnet-vm tailnet-pg para que socat re-resuelva. Posibilidad de mejora: ExecStartPre con check periódico vía systemd timer si la IP del container cambia frecuentemente.

Dokploy :3000 desde tailnet

Regla en iptables -L DOCKER-USER:

ACCEPT 6 -- 100.64.0.0/10  0.0.0.0/0  tcp dpt:3000  /* tailnet access dokploy panel */

Esta regla está en línea 1 (antes del DROP genérico de IPs no autorizadas). Persistida con netfilter-persistent save en PROD y STAGE. Sobrevive a reboots.

Troubleshooting

ssh root@crearack-prod da timeout

Verificar:

1. tailscale status → ¿aparece tu nodo? Si no, login en cliente.
2. tailscale status → ¿aparece crearack-prod? Si no, problema en server (ver punto 4).
3. ping crearack-prod → ¿responde? Si no, problema MagicDNS o ACL.
4. Si todo lo anterior responde pero ssh timeout: comprobar ACL en panel admin → ¿tu device tiene acceso a tag:server?

curl http://crearack-prod:8428 falla

Comprobar en el server:

ssh root@crearack-prod "systemctl is-active tailnet-vm.service"
ssh root@crearack-prod "ss -tlnp | grep 8428"

Si el unit está inactive, restart: systemctl restart tailnet-vm.service. Si la IP del container cambió tras un redeploy de Dokploy, eso lo arreglará.

Dokploy login da “Invalid origin”

Footgun s53 documentado: Dokploy v0.28+ usa Better Auth, que valida Origin contra user.trustedOrigins. Por defecto solo acepta http://<serverIp>:3000 (la IP pública). Cuando accedes vía tailnet (http://crearack-prod:3000), el origin no matchea y el login es rechazado.

Solución: ejecutar el script idempotente del repo CreaRack-Pro que pobla user.trustedOrigins con tailnet + IP pública:

ssh root@crearack-prod "bash -s" < scripts/infra/dokploy-fix-trusted-origins.sh
ssh root@crearack-staging "bash -s" < scripts/infra/dokploy-fix-trusted-origins.sh

Estado configurado tras s53:

• PROD: {http://crearack-prod:3000, http://116.203.31.166:3000}
• STAGE: {http://crearack-staging:3000, http://178.104.131.173:3000}

Better Auth lee el array en cada request (no cachea), efecto inmediato sin restart.

Detalle en memoria local Edu: footguns_dokploy_trusted_origins.md.

Dokploy panel no carga desde tailnet (regla iptables)

Verificar regla iptables:

ssh root@crearack-prod "iptables -L DOCKER-USER -n --line-numbers | grep 100.64"

Si no aparece, la regla se perdió en un docker restart (no debería con netfilter-persistent pero ha pasado). Re-aplicar:

iptables -I DOCKER-USER 1 -p tcp -s 100.64.0.0/10 --dport 3000 -j ACCEPT -m comment --comment "tailnet access dokploy panel"
netfilter-persistent save

Quiero quitar acceso a alguien del tailnet

Panel admin → Machines → buscar device → menú ... → Remove. Eso revoca al device de inmediato. Si la persona tenía varios devices, repetir para cada uno.

Si la persona tiene cuenta de usuario y ya no debe estar en CreaRack: Users → buscar email → Remove user. Eso elimina al usuario y todos sus devices.

Referencias

• Panel admin Tailscale: https://login.tailscale.com/admin
• Tailscale ACLs docs
• Tailscale MagicDNS
• Tailnet Lock

Véase también

• [[workspace—onboarding—onboarding-edu]] — onboarding Edu
• [[workspace—onboarding—onboarding-dani]] — onboarding Dani
• [[workspace—onboarding—onboarding-txell]] — onboarding Txell
• [[workspace—guias—team-processes]] — políticas y procesos del equipo
• [[crearack-tech—guides—security-guide]] — guía de seguridad CreaRack