Hace unos días publiqué mi guía base de Tailscale. Ahí contaba por qué dejé de pelearme con WireGuard puro para el acceso diario al homelab. Esa parte sigue siendo cierta. Instalar Tailscale sigue siendo ridículamente fácil. Lo que ya no me parece tan sencillo es diseñarlo bien cuando tu red deja de ser cuatro cacharros y empieza a parecer una pequeña jungla.
Ese es el punto en el que casi todas las guías se quedan cortas. Te enseñan a hacer tailscale up, ves el dispositivo en el panel y te vienes arriba. Luego pasan dos semanas, quieres acceder a un switch que no puede instalar el cliente, quieres sacar internet por casa cuando estás de viaje, o decides que igual no te hace gracia que todos los nodos hablen con todos. Ahí empieza el trabajo real.
Hoy tengo claro algo que hace un año no tenía tan claro: en Tailscale no basta con instalar agentes. Hay que decidir qué papel juega cada máquina. Si no haces ese ejercicio, acabas usando un exit node para algo que pedía un subnet router, o anunciando media red local cuando en realidad solo querías llegar a una impresora.
Si partes desde cero, lee primero la guía anterior. Si ya tienes Tailscale corriendo y quieres dejar de improvisar, esta es la conversación interesante.
la pregunta correcta no es “cómo lo instalo”#
La pregunta correcta es otra: “qué necesita cada dispositivo”.
En mi cabeza, Tailscale tiene tres modos prácticos de uso.
El primero es el bueno casi siempre: instalar el cliente directo en la máquina final. Si el dispositivo puede correr Tailscale y tienes control sobre él, esa suele ser la mejor opción. Tienes identidad propia, políticas más limpias, menos magia rara y mejor trazabilidad.
El segundo es el subnet router. Según la propia documentación de Tailscale, sirve para extender la tailnet a equipos que no pueden o no deben llevar el cliente instalado. Piensa en una impresora, una cámara IP, un NAS viejo, un switch gestionable o incluso una VPC completa. El router anuncia una subred y hace de puente entre la red Tailscale y esa red clásica de toda la vida. Un detalle curioso, y útil si manejas muchos cacharros, es que los dispositivos que van detrás de un subnet router no cuentan contra el límite de dispositivos del plan.
El tercero es el exit node. Aquí ya no estás dando acceso a una subred privada concreta, sino diciendo “todo mi tráfico público sale por aquí”. Es el modo VPN clásico. Lo uso cuando estoy fuera de casa, cuando piso una WiFi pública o cuando necesito navegar como si estuviera en mi conexión habitual.
Los tres encajan en el mismo producto, pero no resuelven el mismo problema. Ahí está la gracia y también la trampa.
mi regla número uno: cliente directo siempre que pueda#
Cada vez que una máquina puede llevar Tailscale encima, intento ponerlo ahí y no en un salto intermedio. Me da igual que sea una VM, un mini PC, un portátil o un servidor Linux muy modesto. Si lo soporta, prefiero cliente directo.
¿Por qué soy tan pesado con esto?
Porque el cliente directo me da varias cosas que luego echo de menos cuando tiro de rutas anunciadas.
La primera es identidad propia. No es lo mismo que todo parezca venir desde un router intermedio a que cada servidor tenga su propio nombre, su propia etiqueta y sus propias reglas. Cuando un nodo se conecta con cliente directo, sé exactamente quién es y qué debería poder tocar.
La segunda es rendimiento. Un salto menos es un problema menos. Cuanto más tráfico haces pasar por un nodo puente, más fácil es crear un cuello de botella sin querer. Para cuatro peticiones web te da igual. Para copias de seguridad, sincronizaciones grandes o acceso frecuente a paneles de administración, ya no me da tan igual.
La tercera es sencillez operativa. Cuando una máquina tiene el cliente, puedo usar MagicDNS, Tailscale SSH, etiquetas, ACLs o grants de forma mucho más natural. No estoy intentando recordar si esa IP pertenece al servidor final o al router que la anuncia.
La excepción son los dispositivos tontos o delicados. Ahí entran impresoras, BMCs, IPMI, cámaras, algunos switches, appliances raros y todo aquello donde meter software extra es imposible o mala idea. En esos casos, el subnet router es una bendición. Pero lo trato como excepción, no como plan por defecto.
También hay otra excepción útil: redes enteras que no quiero tocar máquina por máquina. En laboratorios viejos, redes de clientes, VPCs temporales o segmentos llenos de equipos legacy, anunciar rutas tiene mucho sentido. Ahorras tiempo y no rompes nada.
cuándo uso subnet routers y cuándo no#
Aquí es donde más he afinado mi criterio. Durante bastante tiempo anunciaba rutas porque podía, no porque debiera. Mala costumbre.
Ahora uso subnet routers en cuatro escenarios muy concretos.
El primero es acceso a infraestructura que no ejecuta clientes. BMCs, paneles de switches, impresoras y algún NAS veterano entran aquí de cabeza.
El segundo es acceso a una red completa que quiero tratar como bloque. Por ejemplo, un segmento de laboratorio o una VPC donde no me compensa instalar Tailscale en cada máquina.
El tercero es transición. Si estoy migrando una red hacia Tailscale poco a poco, el subnet router me permite dar conectividad hoy y decidir mañana qué nodos merecen cliente propio.
El cuarto es conveniencia administrativa. Hay veces que la opción correcta en teoría es cliente directo, pero el coste de desplegarlo en veinte máquinas para algo puntual no compensa. En ese caso tiro de ruta anunciada y santas pascuas.
La forma básica de levantar uno es conocida:
| |
Y si ese router también tiene que aceptar rutas externas:
| |
La documentación oficial deja claro algo importante: el subnet router respeta las políticas de acceso de Tailscale. Eso está muy bien, pero no significa que todo vaya a salir fino por arte de magia. La primera cagada típica es anunciar más rango del necesario. Si solo quieres llegar a una red concreta, anuncia esa red. No anuncies un /16 porque te da pereza pensarlo.
La segunda cagada típica es meter dos routers anunciando la misma ruta sin tener claro cuál debe usarse. Se puede hacer y tiene sentido en alta disponibilidad, pero no si lo haces por accidente. Cuando pasa, el día que algo responde raro te puedes tirar una hora jurando en arameo.
La tercera es tocar SNAT sin saber bien para qué. Por defecto, Tailscale hace SNAT en el subnet router. Eso significa que el dispositivo que está detrás ve el tráfico como si viniera del propio router. A veces eso es justo lo que quieres porque simplifica el retorno. Otras veces quieres preservar la IP de origen y te pones creativo con --snat-subnet-routes=false. Yo solo lo toco cuando tengo un motivo concreto. Si no, prefiero quedarme con el comportamiento por defecto y dormir mejor.
Una manía que me ha funcionado es asignar un router por propósito, no uno gigante para todo. Si tengo un segmento de red de gestión y otro de servicios internos, prefiero separarlos. Me obliga a pensar qué acceso necesito y hace mucho más simple leer la política después.
exit node no significa “más Tailscale”#
Otro error muy habitual es tratar el exit node como si fuera la versión premium del subnet router. No lo es.
El subnet router te da acceso a una red privada. El exit node cambia por dónde sale tu tráfico público. Son dos cosas distintas.
Cuando activo un exit node, estoy diciendo que mi portátil o mi móvil van a navegar por internet como si estuvieran detrás de esa máquina. Esto me viene de lujo cuando viajo, cuando trabajo desde una red dudosa o cuando quiero entrar a un servicio que se pone tiquismiquis con la geografía.
La propia documentación de Tailscale lo plantea así y además deja otra nota útil: el exit node captura el tráfico que no esté ya dirigido a un subnet router o a otro conector de aplicación. Dicho de forma simple, el exit node es la autopista de salida, no la llave de tu LAN.
Yo no lo dejo activado permanentemente en casa. Lo probé un tiempo y me cansé rápido. Añades latencia, conviertes una máquina en punto crítico para todo tu tráfico y a veces te lías con servicios locales que quieres seguir viendo por la red donde estás conectado. Si estás sentado en tu sofá con una conexión fiable, pasar toda tu navegación por un exit node de tu propio homelab me parece innecesario.
Donde sí brilla es fuera de casa. Ahí sí lo uso. Portátil en hotel, móvil en una red abierta, pruebas desde otra ubicación, banca online que se enfada si detecta un país distinto. Para eso va perfecto.
Hay un ajuste que conviene recordar porque ahorra disgustos: el acceso a la red local mientras usas exit node. Si no lo habilitas, a veces te preguntas por qué has perdido visibilidad de la impresora o del Chromecast que tienes al lado. Puedes activarlo desde el cliente o con:
| |
Este pequeño detalle me ha ahorrado más de una bronca interna. La primera vez piensas que Tailscale se ha roto. No, simplemente está haciendo exactamente lo que le pediste.
donde de verdad gana Tailscale: políticas claras#
Si solo instalas clientes y nunca tocas políticas, Tailscale sigue siendo útil. Pero en cuanto tu red crece un poco, dejar el “allow all” por defecto es como dejar la puerta del trastero abierta porque hoy no hay nadie mirando.
La documentación actual empuja bastante hacia grants como sintaxis nueva. Las ACLs clásicas siguen funcionando y no van a desaparecer mañana, pero ya no reciben las funciones nuevas. Mi consejo aquí es simple: si empiezas una política hoy, piensa en grants. Si ya tienes ACLs bien montadas, tampoco hace falta tirarlas a la basura por postureo.
Yo sigo hablando de ACLs porque es el lenguaje con el que mucha gente conoce Tailscale, pero lo importante no es la palabra, sino la disciplina.
Mi disciplina es esta: las reglas se escriben por función, no por capricho.
No me gusta depender de nombres de dispositivos tipo server1, server2 y server3. Eso envejece fatal. Prefiero etiquetas. tag:infra, tag:labs, tag:backup, tag:admin. Así la política refleja qué hace una máquina, no cómo la llamé una noche con sueño.
Un ejemplo sencillo:
| |
No es espectacular, pero sí legible. El día que vuelvo a esa política dentro de seis meses sé qué pretendía hacer. Para mí eso vale oro.
También intento meter pruebas en el archivo de política cuando la red empieza a ser seria. Suena excesivo hasta que rompes el acceso a producción a la una de la mañana por un JSON mal tocado. En ese momento te das cuenta de que cinco minutos escribiendo tests eran una ganga.
Hay otra función menos conocida y bastante útil si mueves rutas o exit nodes de forma recurrente: autoApprovers. Tailscale la documenta para que ciertas rutas o nodos puedan aprobarse automáticamente según quién los anuncie. No es imprescindible para un homelab pequeño, pero si rotas máquinas o quieres algo más limpio en escenarios de alta disponibilidad, evita bastante clic absurdo en el panel.
los errores que ya me he comido para que tú no tengas que hacerlo#
El primero fue pensar que un subnet router era una solución elegante para todo. No lo es. Es práctico, sí. Elegante, depende.
El segundo fue dejar durante demasiado tiempo el acceso por defecto abierto entre demasiadas máquinas. No pasó nada grave, pero cuando revisé la política vi conexiones posibles que no aportaban nada. Mucho acceso sobrante es igual a mucha superficie innecesaria.
El tercero fue intentar resolver problemas de DNS a golpe de más VPN. A veces el fallo no es de Tailscale. A veces simplemente no estás resolviendo bien los nombres de tu red interna y llevas una hora culpando al pobre túnel.
El cuarto fue confiar en nombres improvisados. Cuando empiezas, todo parece manejable. Luego aparecen servidores temporales que dejan de ser temporales, laboratorios que se quedan a vivir y portátiles con nombres heredados de otra época. Si no etiquetas por función, el archivo de políticas se convierte en arqueología.
El quinto fue usar exit node cuando realmente solo necesitaba acceso a dos servicios internos. Eso mete más complejidad, más latencia y más puntos de fallo. Si lo único que quieres es abrir el panel de Proxmox o entrar al NAS, no necesitas rutear todo tu internet por casa.
la arquitectura que mejor me está funcionando#
Después de varias vueltas, he acabado con una estructura bastante simple.
Los servidores importantes llevan cliente directo.
Los portátiles y el móvil también.
Las redes con equipos que no pueden llevar cliente entran por subnet routers dedicados.
Tengo al menos un exit node listo para viajes o redes públicas, pero no lo dejo como ruta permanente por defecto.
Las políticas se basan en etiquetas y grupos, no en ocurrencias.
MagicDNS está activado porque recordar IPs en 2026 me parece una forma bastante triste de gastar neuronas.
Y cuando una red o un servicio me piden algo raro, intento hacerme primero esta pregunta: “estoy intentando arreglar con Tailscale un problema que en realidad es de DNS, de segmentación o de permisos?”. La mitad de las veces la respuesta es sí.
mi opinión después de usarlo en serio#
Sigo pensando que Tailscale es de las mejores piezas de software que puedes meter en un homelab. No porque haga magia, sino porque te quita la fricción justa para que puedas pensar en la arquitectura en vez de en la fontanería.
Pero también creo que cuanto más fácil parece, más fácil es montarlo regular.
Mi resumen corto sería este: cliente directo siempre que puedas, subnet router cuando tenga sentido de verdad, exit node solo cuando quieras sacar tráfico público por otro sitio, y políticas por función desde el principio. Si haces eso, Tailscale escala sorprendentemente bien sin volverse un monstruo difícil de leer.
Y si no lo haces, también funciona. Hasta que un día deja de hacerlo, claro. Ahí ya toca abrir el panel, mirar rutas, revisar reglas y aceptar que la red no estaba tan “simple” como te contabas.
Eso también es homelab.