Un host de Tailscale inaccesible: ¿enrutador de subred o nodo de salida?

Un host de Tailscale responde mientras otro se queda a oscuras, o todo funciona hasta que los sitios web públicos empiezan a informar del país equivocado. Ambas quejas llegan como «Tailscale está roto», y ambas suelen ser la construcción equivocada activada para el destino equivocado. Un enrutador de subred expone una red privada a la tailnet, mientras que un nodo de salida cambia por dónde sale el tráfico de internet. Ordena primero el destino que falla y luego elige el rol que lo cubre.

Empieza por el destino que ha fallado

Anota la dirección o el nombre que no funcionó y qué tipo de cosa es. Un dispositivo en una LAN privada detrás de otra sede, un servicio en tu propio segmento y un sitio web público son tres problemas de enrutamiento que comparten un solo cliente por casualidad. La distinción no es estética, porque las dos construcciones cubren conjuntos distintos de destinos. Activar una no hace nada por la otra, y esa es toda la fuente de la confusión.

Fíjate también en la familia de direcciones. Una subred anunciada solo como IPv4 deja los destinos IPv6 en la ruta local, lo que se lee como un fallo parcial hasta que alguien compara las dos tablas de enrutamiento. Anota qué ruta esperabas, para que la prueba posterior tenga algo que contradecir.

Llega a un dispositivo que nunca ejecuta Tailscale

El enrutador anuncia rangos concretos a la tailnet y luego reenvía paquetes entre la tailnet y el segmento privado, de modo que los dispositivos de ese segmento no necesitan su propio cliente. Llegar a un NAS de la oficina desde un portátil en casa es exactamente este caso. El enrutador es el único miembro de la tailnet en ese lado.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

El anuncio es solo la primera de tres condiciones. La ruta debe aprobarse para la tailnet, el cliente debe aceptar las rutas anunciadas, y una regla de acceso debe permitir la conexión. Esa cadena es la razón por la que el síntoma tantas veces es que el enrutador está activo y el NAS no. Un enrutador accesible demuestra que el túnel funciona; no demuestra nada sobre la aprobación, la aceptación del cliente ni la política.

Cada uno de esos tres fallos se ve distinto en la consola de administración. Compruébalos en orden en lugar de cambiar los tres a la vez, porque un segundo cambio oculta cuál era el que importaba.

Saca el tráfico público por otra máquina

Un nodo de salida enruta tu tráfico general de internet a través de sí mismo, que es el equivalente más cercano al túnel completo de otros productos VPN. También necesita tres consentimientos separados: el dispositivo anuncia el rol, un administrador lo permite y el cliente lo selecciona. Unirse a una tailnet no envía nada por otro miembro de forma predeterminada.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Seleccionar un nodo de salida no concede automáticamente acceso a su propia LAN. La opción de acceso a la LAN existe precisamente porque son permisos distintos, y dejarla desactivada es el valor predeterminado más seguro. Las rutas hacia otros recursos de Tailscale mantienen su propio tratamiento incluso mientras un nodo de salida está activo. Por eso un servicio alojado en una subred puede seguir funcionando mientras la ruta pública de internet ha cambiado.

Un nodo de salida también cambia cómo te ve internet, no solo lo rápido que parece ir. Espera que la geolocalización, los catálogos de streaming y los límites de velocidad sigan la dirección de la salida y no la tuya.

Lee la división en tres cuando solo falla un host

Una impresora en tu segmento, un NAS detrás de un enrutador de subred remoto y un sitio público son tres destinos con tres rutas distintas. Si falla exactamente uno de ellos, el defecto pertenece a la ruta de ese destino y no al cliente en conjunto. Para la impresora local mientras se usa un nodo de salida, el ajuste de acceso a la LAN es la respuesta habitual. Para el NAS remoto, comprueba el rango anunciado, su estado de aprobación y las reglas de acceso en ese orden. Para un sitio público, comprueba qué nodo de salida está seleccionado y si el cliente realmente lo ha aceptado.

Si la dirección funciona y el nombre no, deja de mirar las rutas. El DNS privado se configura por separado, y un nombre que resuelve a la dirección equivocada falla de una manera que parece idéntica a una ruta bloqueada. Prueba primero la dirección y luego el nombre, y los dos resultados te dicen qué capa abrir.

Confirma la ruta que crees que has construido

La verificación es una consulta de ruta más una comprobación de dirección, no un ping. La consulta dice qué interfaz usaría un destino, y la comprobación de dirección dice en qué rango vive realmente el destino. Un ping que funciona dice que el host está vivo en alguna parte, lo cual no es la pregunta. Ejecuta ambos antes de cambiar cualquier configuración.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Combínalo con la vista propia de la tailnet, que muestra si el peer está conectado directamente o retransmitido. Una ruta retransmitida sigue funcionando, y eso explica quejas de latencia que no tienen nada que ver con la ruta que estabas depurando. la documentación del enrutador de subred cubre el paso de aprobación si no te resulta familiar. Después anota qué construcción cubre qué destino en tu propia red, porque la próxima persona que añada una sede hará la misma pregunta.