¿Qué debes verificar cuando Tailscale no puede conectarse a tu servidor doméstico?

Cuando Tailscale no puede alcanzar tu servidor doméstico, la falla no siempre está dentro de la red Tailscale. El servidor puede estar desconectado, el nombre del dispositivo puede no resolverse, una regla de acceso puede rechazar la conexión, el firewall del sistema operativo puede bloquear el servicio o la aplicación puede estar escuchando solo en localhost.

La forma más rápida de encontrar la causa es solucionar problemas por capas. Primero confirma que ambos nodos de Tailscale estén en línea. Luego prueba la IP cruda de Tailscale del servidor, separa la conectividad básica del nodo del acceso a la aplicación, y solo avanza a la configuración de enrutamiento de subred o solución de DERP cuando los síntomas realmente lo indiquen.

Comienza identificando qué capa está fallando

Un error común en la solución de problemas es tratar cada tiempo de espera como el mismo problema. Un servidor doméstico que parece desconectado en la tailnet es diferente de un servidor que responde al ping de Tailscale pero rechaza una conexión SSH o web.

Tailscale proporciona la ruta de red privada entre dispositivos, pero el servicio final depende del sistema operativo del servidor, firewall, puerto de escucha, configuración de la aplicación, red Docker y política de acceso. Arreglar la capa incorrecta puede crear problemas adicionales sin restaurar la conexión.

Antes de cambiar algo, anota el síntoma exacto. Verifica si el servidor aparece en línea, si su IP de Tailscale responde, si su nombre MagicDNS se resuelve y si el puerto específico de la aplicación acepta conexión.

Confirma que ambos nodos de Tailscale estén en línea

Comienza con los dos dispositivos involucrados en la conexión. La laptop o teléfono remoto debe estar conectado a la tailnet, y el servidor doméstico también debe estar en línea bajo la cuenta, etiqueta o identidad de dispositivo esperada.

En un servidor Linux, verifica el servicio Tailscale y ejecuta estado de tailscaleEn sistemas de escritorio, verifica que el cliente esté conectado y no en pausa, desconectado o esperando autenticación. Un servidor que no pudo iniciar Tailscale después de un reinicio no se puede arreglar cambiando DNS o puertos de la aplicación.

También verifique si el servidor aparece bajo el nombre de dispositivo esperado y la IP de Tailscale. Si el nodo está desconectado, solucione el servicio, el estado de inicio de sesión, el comportamiento de inicio del sistema o la versión del cliente antes de solucionar cualquier problema por encima de la capa de red.

Use la IP cruda de Tailscale antes de probar un nombre de host

Un nombre de host añade resolución DNS a la ruta de conexión. Si comienza con un nombre de servidor como servidor-casa o dispositivo-nas, no puede saber inmediatamente si la falla proviene de la red o de la resolución de nombres.

Encuentre la dirección IPv4 de Tailscale del servidor, normalmente en el rango 100.x.x.x, y pruebe esa dirección directamente. Cuando las rutas LAN, nodos de salida o subredes superpuestas complican la ruta, es especialmente útil probar la IP de Tailscale del dispositivo antes que su dirección LAN privada.

Si la IP cruda funciona pero el nombre de host no, la conectividad básica del nodo probablemente esté saludable. Pase a MagicDNS y la configuración DNS del cliente en lugar de reinstalar Tailscale o cambiar el router.

Si la IP funciona pero el nombre falla, verifique MagicDNS

MagicDNS permite que los dispositivos usen nombres legibles en lugar de recordar direcciones IP de Tailscale. Cuando funciona, un dispositivo llamado servidor-casa se puede alcanzar a través de ese nombre desde otro dispositivo en el mismo tailnet.

La función crea nombres automáticos de dispositivos dentro del tailnet, pero la resolución exitosa aún depende de que el dispositivo esté conectado y el cliente acepte la configuración DNS del tailnet. Los filtros DNS locales, herramientas de seguridad empresarial, resolvedores personalizados o registros en caché obsoletos pueden interferir.

Compare el nombre corto del host, el nombre completo del tailnet y la IP cruda de Tailscale. Si solo fallan los nombres, verifique si MagicDNS está habilitado, si la máquina fue renombrada y si otro producto DNS está sobrescribiendo la configuración del resolvedor.

Separe la conectividad de Tailscale de la conectividad de la aplicación

Una conexión exitosa de nodo a nodo no prueba que todos los servicios en el servidor sean accesibles. Puede que pueda hacer ping a la IP de Tailscale mientras SSH, Jellyfin, un panel de control, SMB o una interfaz web de Docker aún agotan el tiempo de espera.

Eso generalmente significa que la ruta de Tailscale existe pero la capa de aplicación está rechazando o falta la conexión. El servicio puede estar detenido, escuchando en otro puerto, vinculado a la interfaz incorrecta, bloqueado por el firewall del servidor o no publicado desde su contenedor.

Pruebe el destino exacto que necesita, como 100.x.x.x:22 para SSH o http://100.x.x.x:8080 para un servicio web. Si el nodo responde pero el puerto no, deje de solucionar problemas de MagicDNS y DERP hasta que se verifique el servicio del lado del servidor.

Verifique si el servicio está escuchando en la interfaz correcta

Una aplicación puede funcionar normalmente en el servidor doméstico y aún así ser inaccesible desde cualquier otro dispositivo. Esto ocurre cuando el servicio solo escucha en 127.0.0.1, que acepta conexiones desde el propio servidor pero no a través de sus interfaces LAN o Tailscale.

Un servicio que escucha en 0.0.0.0 aceptar tráfico IPv4 en todas las interfaces disponibles, mientras que un servicio también puede estar vinculado explícitamente a la dirección LAN o Tailscale del servidor. La elección correcta depende de si el servicio debe ser accesible desde la LAN, tailnet o solo a través de un proxy inverso local.

No cambie automáticamente todos los servicios para 0.0.0.0. Confirme primero la ruta de acceso prevista, luego use reglas de firewall y autenticación de aplicaciones para limitar quién puede acceder al puerto.

El firewall del servidor puede estar bloqueando el tráfico de Tailscale

Un servicio puede funcionar a través de la IP LAN del servidor doméstico pero fallar a través de su IP Tailscale porque el sistema operativo trata la interfaz Tailscale como una ruta de red separada. Las reglas LAN no siempre se aplican al tráfico que llega a través de tailscale0.

Los sistemas Linux pueden usar UFW, firewalld, iptables o nftables. Windows puede clasificar el adaptador Tailscale de manera diferente a la LAN doméstica. Los firewalls de red más amplios también pueden impedir conexiones UDP directas y forzar el tráfico a rutas retransmitidas. La verificación relevante es si su firewall permite la ruta de conexión Tailscale prevista.

No desactive todo el firewall como solución permanente. Permita solo el puerto del servicio requerido desde la interfaz Tailscale, direcciones Tailscale seleccionadas o una política tailnet adecuada. Luego vuelva a probar la aplicación directamente.

Revise las políticas de acceso, concesiones, etiquetas e identidad del dispositivo

Si un dispositivo Tailscale puede acceder al servidor doméstico mientras otro no, la diferencia puede ser una política intencional y no una falla de red. El acceso puede depender del usuario, dispositivo de origen, etiqueta de destino, protocolo y puerto.

Un servidor etiquetado para acceso a infraestructura puede no aceptar tráfico desde un dispositivo personal a menos que la política permita esa combinación. Una regla que permite SSH no necesariamente permite el panel web en otro puerto, y un dispositivo compartido puede tener permisos diferentes a un dispositivo propiedad del mismo usuario.

Revise la identidad de origen, la identidad de destino, las etiquetas del servidor y el puerto solicitado juntos. Una regla amplia temporal puede ayudar a aislar un problema de política, pero reemplácela por la regla correcta más específica después de las pruebas.

Un servidor doméstico directo no necesita un enrutador de subred

Si Tailscale está instalado directamente en el servidor doméstico, use la propia IP de Tailscale del servidor o el nombre MagicDNS. No se requiere un enrutador de subred para acceder a esa máquina.

Los routers de subred resuelven un problema diferente: proporcionan acceso a dispositivos que no ejecutan Tailscale, como una impresora, cámara, NAS antiguo, dispositivo inteligente del hogar u otra máquina en la LAN doméstica.

Agregar enrutamiento de subred a un problema simple de nodo directo crea más puntos donde la conexión puede fallar. Primero pruebe que el cliente Tailscale en el servidor doméstico sea accesible. Solo solucione problemas de rutas LAN anunciadas cuando el destino real esté detrás de ese servidor.

El enrutamiento de subred requiere una cadena de enrutamiento completa

Cuando el destino es un dispositivo LAN sin Tailscale, el router de subred debe hacer más que aparecer en línea. Tiene que recibir tráfico del tailnet, reenviarlo a la LAN doméstica y permitir que la respuesta regrese.

Una configuración funcional normalmente requiere reenvío de IP en el dispositivo de enrutamiento, rutas de subred anunciadas, aprobación de rutas, controles de acceso coincidentes y aceptación de rutas en el cliente cuando sea necesario. El propósito es anunciar una subred privada a través de una puerta de enlace para que los dispositivos tailnet puedan alcanzar máquinas que no ejecutan el cliente.

Si la ruta es visible pero el tráfico falla, revise cada etapa por separado. Confirme que la subred correcta fue anunciada, verifique que fue aprobada, inspeccione el firewall de reenvío y asegúrese de que el dispositivo LAN tenga una ruta de retorno válida.

Las subredes privadas superpuestas pueden enviar el tráfico por el camino equivocado

Muchas redes domésticas, de oficina y de hotel reutilizan direcciones como 192.168.1.0/24. Si su Wi-Fi actual y su subred doméstica usan el mismo rango, el sistema operativo puede tratar el destino como local en lugar de enviarlo a través de Tailscale.

Esto crea un síntoma confuso: la IP directa de Tailscale del servidor funciona, pero su IP de la LAN doméstica no. La solicitud puede estar yendo a la red actual en lugar del router de la subred remota.

Utilice la IP de Tailscale del destino siempre que sea posible. Si es necesario el acceso a subredes, considere cambiar una LAN a un rango privado menos común o aplicar un diseño de enrutamiento que maneje deliberadamente las redes superpuestas.

Un Nodo de Salida Puede Cambiar el Acceso a la LAN Actual

Si el dispositivo cliente usa un nodo de salida de Tailscale, su selección de ruta difiere de una conexión tailnet normal. El acceso a dispositivos LAN cercanos puede estar bloqueado a menos que se permita explícitamente el acceso a la red local.

Esto importa al solucionar problemas desde una laptop conectada a Wi-Fi de hotel, oficina o casa mientras también usas un nodo de salida. Un fallo para alcanzar una dirección LAN privada puede provenir del comportamiento del nodo de salida más que del servidor doméstico.

Prueba sin el nodo de salida, o habilita el acceso LAN solo cuando confíes en la red local. No habilites acceso local amplio automáticamente en Wi-Fi público desconocido.

Docker Añade Otro Límite de Puerto e Interfaz

Un servicio del host como SSH puede funcionar a través de Tailscale mientras que una aplicación Docker en el mismo servidor falla. Eso usualmente apunta a la red del contenedor más que a la conectividad del nodo.

Verifica si el contenedor está en ejecución, si la aplicación escucha dentro del contenedor y si su puerto está publicado en el host. Un mapeo de Compose como 8080:80 expone el puerto 80 del contenedor a través del puerto 8080 del host, mientras que un puerto vinculado solo a 127.0.0.1 puede permanecer inaccesible a través de la IP de Tailscale.

También verifica las rutas de proxy inverso, la red del host, las reglas de firewall de Docker y si la aplicación misma permite conexiones desde direcciones fuera de la LAN. Prueba el puerto del host directamente antes de depurar dominios o certificados de nivel superior.

DERP Usualmente Explica la Lentitud Más Que el Fallo Completo

Tailscale intenta crear conexiones directas entre dispositivos. Cuando el comportamiento NAT o las restricciones del firewall lo impiden, puede usar una ruta de relevo en su lugar.

DERP proporciona un relevo cifrado de respaldo cuando falla la conectividad directa. El relevo reenvía tráfico ya cifrado y puede conectar dispositivos a través de combinaciones difíciles de IPv4, IPv6, NAT y firewall.

Una ruta DERP a menudo funciona con más latencia o menor rendimiento, por lo que es un fuerte sospechoso cuando SSH se siente lento o las transferencias de archivos son lentas. Si la conexión no funciona en absoluto, primero verifica el estado del nodo, la política de acceso, el firewall local, el puerto de la aplicación y la dirección de enlace.

Usa Diagnósticos de Conexión Antes de Cambiar el Router

Comandos como tailscale ping ayuda a separar una ruta de nodo de una ruta de aplicación. Un resultado exitoso demuestra más que una pestaña del navegador fallida porque prueba la conectividad sin depender del puerto, proxy o certificado de la aplicación.

tailscale netcheck puede ayudar a mostrar la disponibilidad de UDP, el comportamiento NAT, la conectividad IPv4 o IPv6 y las regiones de retransmisión cercanas. Estos resultados son más útiles cuando la conexión funciona solo a través de un relé o cambia entre redes.

No comiences añadiendo reenvío de puertos públicos al router doméstico. Tailscale está diseñado para funcionar sin exponer directamente los puertos de la aplicación del servidor doméstico a internet. Los cambios en el router deben responder a un problema de ruta confirmado, no reemplazar los pasos diagnósticos anteriores.

Reinicia y Actualiza Solo Después de Saber Qué Capa Falla

Reiniciar Tailscale puede restaurar un demonio fallido o un estado de cliente obsoleto, pero reinicios repetidos no son un diagnóstico. Si la misma falla regresa después de cada reinicio, el problema subyacente probablemente sea la configuración de inicio, la política de cortafuegos, el enrutamiento o el enlace de la aplicación.

Confirma que el servidor doméstico inicia Tailscale sin un inicio de sesión interactivo en el escritorio y permanece conectado después del reinicio. También compara las versiones del cliente si un dispositivo se comporta diferente al resto de la tailnet.

Después de una actualización o reinicio, repite las mismas pruebas en el mismo orden: estado del nodo, IP cruda, nombre de host, ping de Tailscale y puerto de la aplicación. Una secuencia de pruebas consistente muestra qué capa realmente cambió.

Sigue un Orden de Solución de Problemas

La ruta más rápida es avanzar desde el nodo de Tailscale hacia la aplicación. No modifiques DNS, rutas de subred, reglas de cortafuegos y la red de Docker al mismo tiempo.

Primero confirma que ambos nodos estén en línea. Luego prueba la IP cruda de Tailscale, seguida del nombre MagicDNS. Prueba la ruta del nodo, luego el puerto de la aplicación. Solo después de esas comprobaciones debes investigar el cortafuegos del servidor, la dirección de enlace, la política de acceso, el mapeo de Docker o el enrutamiento de subred.

Este orden evita que un servicio detenido simple se convierta en un proyecto complicado de enrutamiento. Cada prueba debe responder una pregunta antes de pasar a la siguiente capa.

Conclusión Final

Cuando Tailscale no puede alcanzar tu servidor doméstico, comienza con la distinción más simple: ¿pueden comunicarse los dos nodos de Tailscale y puede la aplicación aceptar tráfico? Confirma que ambos nodos estén en línea, prueba la IP cruda de Tailscale y luego prueba el nombre MagicDNS y el puerto exacto del servicio.

Si la ruta del nodo funciona pero la aplicación no, enfócate en el firewall del servidor, la interfaz de escucha, la configuración de la aplicación, el mapeo de puertos Docker y la política de acceso. Si el destino no ejecuta Tailscale, entonces avanza a la configuración del router de subred, aprobación de rutas, reenvío de IP y verificación de subredes superpuestas.

Las rutas de retransmisión DERP suelen explicar un rendimiento más lento en lugar de una falla completa. Una prueba consistente capa por capa es más efectiva que reinstalar Tailscale, deshabilitar el firewall o agregar reenvío de puertos públicos sin saber dónde se detiene la conexión.

Preguntas frecuentes

¿Por qué puedo hacer ping a mi servidor Tailscale pero no abrir su interfaz web?

La conexión nodo a nodo funciona, pero el servicio web puede estar detenido, escuchando en otro puerto, vinculado solo a localhost, bloqueado por el firewall del servidor o no publicado desde su contenedor Docker.

¿Por qué funciona la IP de Tailscale pero no el nombre del servidor?

Esto apunta a un problema con MagicDNS u otra configuración DNS. Verifica si MagicDNS está habilitado, si el nombre de la máquina cambió y si otro resolvedor DNS está sobrescribiendo la configuración de Tailscale.

¿Necesito un router de subred para acceder a mi servidor doméstico?

No cuando Tailscale está instalado directamente en ese servidor. Usa su IP de Tailscale o el nombre MagicDNS. Se necesita un router de subred para alcanzar otros dispositivos LAN que no ejecutan Tailscale.

¿Puede un firewall bloquear Tailscale incluso cuando el nodo está en línea?

Sí. El cliente Tailscale puede conectarse a la tailnet mientras el firewall del sistema operativo sigue bloqueando SSH, web, SMB u otro puerto de aplicación que llega a través de la interfaz Tailscale.

¿Significa una conexión DERP que Tailscale está roto?

No. DERP es una solución cifrada de respaldo cuando no se puede establecer una conexión directa. Puede añadir latencia o reducir el rendimiento, pero aún así proporciona conectividad entre los dispositivos.

¿Por qué puedo alcanzar el servidor pero no otro dispositivo en mi LAN doméstica?

El servidor es un nodo Tailscale directo, mientras que el otro dispositivo necesita un router de subred. Verifica el reenvío de IP, las rutas anunciadas, la aprobación de rutas, las reglas de acceso y la ruta de retorno del dispositivo LAN.

¿Pueden las subredes domésticas y remotas superpuestas romper el acceso a Tailscale?

Sí. Si ambas ubicaciones usan la misma subred privada, el cliente puede enviar tráfico a su LAN actual en lugar de a la ruta de la subred remota. Prefiere la IP de Tailscale del destino o cambia el rango de direcciones de una de las redes.

¿Debo abrir puertos en mi router para arreglar Tailscale?

Normalmente no. Primero confirma el estado del nodo, el comportamiento del firewall, la vinculación de la aplicación, la política de acceso y si la conexión es directa o retransmitida. Reenviar públicamente el puerto de la aplicación no es un sustituto para encontrar la falla real de Tailscale.