Tailscale tiene una virtud enorme: hace que una VPN deje de parecer una VPN. Instalas el cliente, autenticas el dispositivo y de repente puedes entrar en tus servidores desde fuera sin abrir puertos, sin pelearte con certificados raros y sin recordar por qué WireGuard puro siempre acaba pidiendo una libreta al lado.
El subnet router lleva esa comodidad un paso más allá. En vez de instalar Tailscale en cada equipo, eliges una máquina dentro de casa y le dices que anuncie una red entera. Desde fuera puedes llegar a dispositivos que ni siquiera tienen Tailscale instalado: impresoras, NAS, paneles internos, cámaras, servicios antiguos, equipos donde no quieres tocar nada.
Es una herramienta buenísima. También es una forma bastante eficaz de esconder una red doméstica mal pensada debajo de una alfombra tecnológica. Y eso en homelab pasa más de lo que nos gusta admitir.
Yo uso Tailscale con mucho cariño, pero intento no convertirlo en pegamento universal. Un subnet router debe simplificar acceso remoto. No debería ser la única razón por la que tu red tiene sentido.
Qué es un subnet router sin ponerse académico#
Un subnet router es un dispositivo dentro de tu red que actúa como puente entre tu tailnet y una subred local.
Imagina que en casa tienes una LAN doméstica normal. Tu portátil fuera de casa está en Tailscale. Si solo instalas Tailscale en algunos servidores, podrás entrar a esos servidores por su IP de Tailscale. Pero no podrás acceder directamente al panel del NAS, a una impresora o a una VM antigua que no tiene cliente.
Con un subnet router, una máquina de casa anuncia esa LAN a Tailscale. Tu portátil aprende que para llegar a los equipos internos debe pasar por ese router. La magia práctica es que desde una cafetería puedes abrir un panel interno como si estuvieras en casa.
Esto evita abrir puertos en el router del operador. También evita montar una VPN clásica para todo el tráfico. Y para un homelab doméstico es comodísimo, porque no todos los dispositivos permiten instalar un cliente moderno.
La parte importante es que ese dispositivo se convierte en una pieza crítica. Si cae, pierdes ese acceso. Si está mal colocado, puedes abrir demasiado. Si nadie documenta qué rutas anuncia, dentro de seis meses estarás preguntándote por qué algo solo funciona desde fuera cuando la luna está en cuarto menguante.
Cuándo me parece una gran idea#
El subnet router brilla cuando necesitas acceso remoto ocasional a servicios internos que no justifican cliente propio.
Un NAS es el ejemplo típico. Muchos NAS pueden correr Tailscale, pero no siempre quieres depender de su paquete, su versión o sus manías. Puedes anunciar la red desde una VM pequeña y llegar al panel del NAS cuando lo necesites.
También encaja con impresoras, interfaces de UPS, cámaras, dispositivos IoT o paneles de administración antiguos. No son cosas que quiera exponer a Internet. Tampoco quiero instalarles nada. Pero sí quiero poder entrar si estoy fuera y algo se ha quedado tonto.
Otro caso claro es el acceso de emergencia. Si estoy de viaje y necesito tocar el router interno, revisar Home Assistant, reiniciar una VM o entrar al panel de backups, Tailscale me da una ruta limpia. No tengo que abrir el puerto 443 a un reverse proxy con veinte servicios detrás solo para resolver un problema puntual.
También me gusta para redes familiares donde no quiero complicar la vida. Un dispositivo estable anuncia la LAN y el resto sigue igual. El portátil, el móvil o la tablet entran por Tailscale cuando hace falta. Para soporte remoto propio es una bendición.
Cuándo prefiero instalar Tailscale en el dispositivo#
No todo debería pasar por subnet router.
Si un servidor es importante y soporta Tailscale bien, muchas veces prefiero instalarle el cliente. Así tiene identidad propia dentro de la tailnet, reglas ACL específicas, nombre claro y menos dependencia de una ruta compartida.
Para servidores críticos, esa identidad ayuda. No es lo mismo decir “este portátil puede entrar al servidor de backups por su nombre de Tailscale” que permitir acceso a media LAN porque el subnet router la anuncia. Cuanto más específica es la regla, menos sustos.
También prefiero cliente directo cuando el dispositivo se mueve entre redes. Portátiles, mini PCs de laboratorio, equipos que a veces están en casa y a veces fuera. El subnet router sirve para una red concreta. El cliente directo sigue al equipo.
Y para servicios publicados a usuarios concretos, Tailscale directo suele ser más limpio. Puedes compartir una máquina, aplicar tags, usar ACLs y evitar que el usuario vea más red de la necesaria.
El subnet router es cómodo. La identidad por dispositivo es más precisa. En redes pequeñas, esa precisión puede parecer exagerada. En cuanto crece el homelab, empieza a agradecerse.
El riesgo: abrir más de lo que querías#
El peligro del subnet router no es que sea inseguro por defecto. El peligro es que resulta tan fácil que acabas anunciando demasiado.
Anunciar toda la LAN doméstica puede estar bien para uso personal. Pero si tienes VLANs, IoT, laboratorio, invitados, cámaras y servicios internos, cuidado. Una ruta amplia puede saltarse parte de la separación mental que creías tener.
La pregunta útil es: desde fuera, ¿necesito llegar a toda esta red o solo a tres servicios?
Si la respuesta real son tres servicios, quizá conviene instalar Tailscale en esos hosts o anunciar una subred más pequeña. Si anuncias todo por pereza, después dependes de ACLs y firewall para compensar una decisión demasiado generosa.
También hay que pensar en quién tiene acceso a la tailnet. Tu portátil personal no es el mismo riesgo que un dispositivo compartido, un móvil antiguo o una cuenta invitada. Si cualquier dispositivo autenticado puede llegar a toda la LAN, la VPN deja de ser una puerta concreta y se parece más a una llave maestra.
Yo prefiero empezar cerrado y abrir lo necesario. Es menos cómodo el primer día, pero da menos pereza moral después.
DNS: el pequeño lío que aparece siempre#
El subnet router te da ruta IP, pero no arregla mágicamente el DNS interno.
Si dentro de casa accedes a nas.local o proxmox.home, desde fuera puede que ese nombre no resuelva igual. Tailscale tiene MagicDNS para nombres de dispositivos dentro de la tailnet, pero eso no significa que tus nombres internos de la LAN vayan a funcionar como esperas.
Aquí hay varias opciones:
- Usar IPs internas para acceso puntual.
- Configurar DNS interno accesible desde Tailscale.
- Usar split DNS si tienes dominio interno.
- Dar nombres Tailscale a los hosts importantes.
La opción cutre de usar IPs funciona para emergencias, pero no escala bien. La opción de DNS interno es más limpia, pero añade dependencia. Si el DNS de casa cae y tú necesitas DNS para reparar, has cerrado la puerta con la llave dentro.
Mi preferencia es tener nombres claros para lo importante y un fallback simple. Si el acceso remoto depende de un DNS interno sofisticado, al menos quiero poder entrar por IP cuando todo está medio roto.
Dónde colocaría el subnet router#
No lo pondría en cualquier sitio.
El dispositivo ideal debería estar siempre encendido, conectado por cable, con IP fija o reserva DHCP, pocos cambios, sistema actualizado y una función clara. Una VM pequeña, un contenedor bien entendido o un mini servidor estable pueden valer. Un portátil que a veces duerme no vale. Un cacharro WiFi en una esquina tampoco me entusiasma.
Tampoco me gusta colocarlo en una máquina de laboratorio que reinicio sin pensar. Si cada prueba rompe el acceso remoto, el subnet router está en mal sitio.
Si la red tiene VLANs, pensaría bien qué interfaces ve esa máquina y qué rutas anuncia. No hace falta que el subnet router pueda tocarlo todo. De hecho, mejor que no pueda tocarlo todo si no hay motivo.
Para alta disponibilidad doméstica se puede montar más de un subnet router anunciando la misma ruta. Tailscale soporta ese tipo de configuración, pero no lo haría por deporte. Primero uno estable y documentado. Luego redundancia si de verdad dependes de ello.
Firewall local: no lo des por hecho#
Una cosa que se olvida: que Tailscale te lleve hasta la red no significa que los dispositivos locales acepten tráfico desde esa ruta.
Algunos firewalls locales bloquean subredes que no esperan. Algunas interfaces de administración solo escuchan en ciertas redes. Algunos servicios confían demasiado en que “si viene de LAN, está bien”. Al meter Tailscale por medio, conviene revisar qué origen ven los dispositivos y qué reglas aplican.
Aquí prefiero pruebas concretas:
- Puedo entrar al panel que necesito.
- No puedo entrar a redes que no debería.
- Desde un dispositivo invitado no veo servicios internos.
- Si apago el subnet router, el fallo es claro.
- Si cae DNS, aún tengo una ruta de emergencia.
No hace falta convertirlo en auditoría militar. Pero sí validar el comportamiento real. Las redes domésticas tienen una capacidad magnífica para parecer ordenadas hasta que haces una prueba básica.
Subnet router frente a abrir puertos#
Para mí, Tailscale gana casi siempre frente a abrir puertos para administración.
No quiero paneles internos expuestos a Internet salvo que haya una razón muy buena. Un reverse proxy con HTTPS está bien para servicios pensados para uso externo. No lo usaría para publicar el panel de administración del NAS, la interfaz de Proxmox, el router o aplicaciones que no necesitan audiencia.
El subnet router reduce superficie pública. Desde fuera, el servicio no existe para Internet. Solo existe para dispositivos autorizados en Tailscale. Eso ya baja mucho el ruido.
Pero ojo: no sustituye el buen diseño interno. Si alguien compromete un dispositivo de tu tailnet, lo que pueda alcanzar importa. Por eso vuelvo a lo mismo: rutas pequeñas, ACLs razonables, dispositivos actualizados y nada de anunciar redes enteras por pura comodidad si no hace falta.
Problemas que puede ocultar#
El subnet router puede convertirse en una venda elegante.
Si tu DNS interno está mal, entras por Tailscale y dices “bueno, así funciona”.
Si tus VLANs no tienen reglas claras, usas Tailscale como atajo.
Si no sabes qué servicios viven dónde, te acostumbras a entrar por IP desde fuera.
Si un servidor no tiene mantenimiento, lo dejas sin cliente y dependes del router de subred.
Todo eso funciona durante un tiempo. Luego llega el día raro y nadie entiende el camino del paquete.
No digo que haya que tener una red perfecta. En casa eso no existe. Pero sí conviene diferenciar entre “Tailscale me simplifica el acceso” y “Tailscale está compensando que no he ordenado la red”. La primera frase es buena. La segunda es una tarea pendiente con pinta de solución.
Mi configuración mental#
La forma en la que lo plantearía en una casa normal:
- Tailscale directo en servidores importantes.
- Subnet router para dispositivos que no pueden o no deben llevar cliente.
- ACLs separando usuarios, dispositivos personales y acceso administrativo.
- DNS interno simple, con fallback por IP.
- Documentación corta de rutas anunciadas.
- Un segundo subnet router solo si el acceso remoto es crítico.
También pondría etiquetas claras. No todo dispositivo de la tailnet debería tener el mismo poder. El móvil personal, el portátil principal, una tablet familiar y un servidor automatizado no son lo mismo.
Y revisaría las rutas cada cierto tiempo. Si anunciaste una subred para una prueba y ya no la necesitas, quítala. La acumulación silenciosa de permisos es una de esas cosas que no dan problemas hasta que los dan.
Cuándo no lo usaría#
No usaría un subnet router para compartir acceso amplio con terceros. Para eso prefiero compartir máquinas concretas o servicios concretos.
No lo usaría como sustituto de segmentación. Si IoT debería estar separado, que lo esté. No metas Tailscale para atravesar alegremente lo que separaste por una buena razón.
No lo usaría en una máquina inestable.
No lo usaría para publicar servicios a público general.
No lo usaría para evitar aprender lo mínimo de rutas, DNS y firewall. Tailscale simplifica mucho, pero si no entiendes nada de lo que está pasando, el día que falle parecerá magia negra con logo moderno.
Conclusión#
Un subnet router de Tailscale es una de las piezas más prácticas que puedes añadir a un homelab doméstico. Te da acceso remoto limpio, reduce puertos abiertos y permite entrar a dispositivos que nunca van a tener un cliente VPN decente.
Pero no debería ser una barra libre a toda la LAN. El buen uso está en anunciar lo necesario, documentar las rutas, aplicar ACLs y mantener una salida de emergencia cuando DNS o el propio router de subred fallen.
Mi opinión es bastante clara: Tailscale subnet router sí, pero con intención. Como herramienta de acceso remoto es fantástica. Como pegamento para una red confusa, acabará cobrándote intereses.
En casa quiero que la VPN me quite trabajo, no que me oculte problemas. Esa diferencia parece pequeña hasta que estás fuera, algo se rompe y necesitas entender la red en cinco minutos.