Por que o cliente de Tailscale para Linux ignora as rutas de subrede anunciadas

Estás nun portátil Linux, tailscale status lista as demais máquinas, e o NAS en 10.80.0.25 segue esgotando o tempo. A tailnet está san, o router de subrede está en liña, e nada na saída do cliente di por que a LAN que hai detrás é inalcanzable. O percorrido de abaixo avanza desde ese síntoma cara a fóra: a opción neste cliente, logo o anuncio no router, logo a aprobación, logo a política, e só entón o destino mesmo. Cada porta falla co mesmo tempo esgotado, así que a orde importa máis ca os comandos.

Que se nega a instalar o cliente de Linux

Os clientes de Tailscale en Linux non aceptan rutas de subrede anunciadas a menos que llo pidas. Sen ese axuste o cliente únese á tailnet e acada os enderezos dos pares, mentres que cada prefixo que anuncia o router queda sen usar. O valor por defecto é deliberado, e por iso o síntoma parece un router roto e non unha decisión local.

Aquí chámanse encamiñamento dúas cousas distintas, e só unha é túa. O router anuncia un prefixo na tailnet; a túa máquina decide se o instala. Un fallo en calquera das dúas produce o mesmo tempo esgotado, por iso adiviñar desperdicia unha tarde. Averigua que lado se nega antes de editar nada.

Activa a aceptación de rutas para esta máquina

Establece a preferencia no cliente, e despois mira que cambiou en lugar de supor que o comando surtiu efecto. A forma actual aplica o axuste sen repetir o fluxo de inicio de sesión, o que importa cando estás a medio camiño dunha sesión.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale instala as rutas aceptadas na súa propia táboa en Linux, así que un prefixo que aparece na táboa 52 é proba directa de que este cliente instalou o anuncio. Se o teu rango non está nesa táboa, detente: o problema é local e ningún traballo no router o cambiará.

Os clientes máis antigos expoñen a mesma preferencia como unha opción do comando de inicio de sesión, así que sudo tailscale up --accept-routes é a alternativa cando falta tailscale set. Úsaa en lugar de editar rutas a man, porque o demo reescribe a súa propia táboa e a túa edición desaparece na próxima reconexión. Comproba a versión antes de copiar un comando dun artigo antigo.

Comproba o anuncio e a aprobación por separado

No router de subrede o prefixo ten que anunciarse, e o núcleo ten que reenviar paquetes entre interfaces. Anunciar sen reenviar dálle unha ruta aprobada que descarta o tráfico en silencio, que é a configuración a medio rematar máis habitual.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Compara o prefixo anunciado co enderezo ao que realmente intentas chegar, carácter a carácter. Un router que anuncia 10.70.0.0/24 non di nada dun NAS en 10.80.0.25, e a discrepancia é invisible en calquera saída de estado porque ambos números parecen igual de plausibles. A maioría dos informes dunha ruta rota rematan aquí. Corrixe o anuncio antes de tocar nada máis abaixo.

A aprobación é a seguinte porta, e é fácil saltala cando o router se configurou desde unha shell. O anuncio ten que habilitarse para ese dispositivo na consola de administración antes de que outras máquinas poidan usalo. Aceptar rutas no cliente non aproba nada nin anula ningunha regra de acceso.

Proba o enderezo privado antes có nome de host

Unha conexión correcta ao enderezo tailnet do propio router demostra que a tailnet funciona, algo que xa sabías. A proba útil é o servizo que realmente necesitas, primeiro contra o enderezo privado, para que un fallo de DNS non se poida facer pasar por un fallo de encamiñamento.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Se o enderezo responde e o nome de host non, tes un problema de resolución de nomes e deberías deixar de tratalo como un problema de ruta. Se non responde ningún, volve unha sección atrás e confirma que o anuncio cobre o enderezo. Os dous fallos vense idénticos desde a aplicación e corríxense en lugares distintos.

Vale a pena unha comprobación local antes de culpar a tailnet. Cando a túa LAN actual usa o mesmo prefixo que a subrede remota, o núcleo prefire a ruta conectada directamente e o tráfico nunca sae da máquina; iso é o que pasa cando unha casa e unha oficina elixen ambas 192.168.1.0/24.

Por que unha opción do cliente non é un axuste do router

Son papeis distintos con requisitos distintos, e copiar unha opción de cliente nun router é como unha tailnet que funciona adquire un bucle. Unha máquina que anuncia rutas necesita reenvío, regras de cortafuegos que permitan o tráfico reenviado e unha decisión sobre que prefixos anuncia. Nada diso o implica --accept-routes.

A documentación dos routers de subrede advirte contra habilitar a aceptación de rutas en routers redundantes que anuncian un só prefixo, xa que un nodo en espera pode empurrar tráfico que xa é local a través do activo. Se tes un par de alta dispoñibilidade, trátao como unha restrición de deseño e non como unha nota ao pé, e decide que nodo posúe o prefixo antes de aprobalo nos dous. Nun só router a mesma advertencia lese como un recordatorio de que a aceptación corresponde aos clientes, non á máquina que anuncia. Anota que porta estaba pechada.

Para un cliente corrente a secuencia remata coa proba de aplicación que fallou ao principio. Para o router, revisa reenvío, anuncio, aprobación e cortafuegos nesa orde, porque o primeiro que falte produce exactamente o tempo esgotado co que empezaches.