Perché il client Tailscale su Linux ignora le rotte di sottorete annunciate

Sei su un portatile Linux, tailscale status elenca le altre macchine, e il NAS su 10.80.0.25 va ancora in timeout. Il tailnet è sano, il router di sottorete è in linea, e nulla nell'output del client dice perché la LAN dietro di esso sia irraggiungibile. Il percorso qui sotto parte da quel sintomo verso l'esterno: il flag su questo client, poi l'annuncio sul router, poi l'approvazione, poi la policy, e solo allora la destinazione stessa. Ogni cancello fallisce con lo stesso timeout, quindi l'ordine conta più dei comandi.

Cosa il client Linux rifiuta di installare

I client Tailscale su Linux non accettano le rotte di sottorete annunciate a meno che tu non lo chieda. Senza quell'impostazione il client si unisce al tailnet e raggiunge gli indirizzi dei pari, mentre ogni prefisso annunciato dal router resta inutilizzato. Il valore predefinito è deliberato, ed è per questo che il sintomo sembra un router guasto e non una decisione locale.

Due cose diverse si chiamano instradamento qui, e solo una è tua. Il router annuncia un prefisso nel tailnet; la tua macchina decide se installarlo. Un guasto in uno dei due produce lo stesso timeout, per questo indovinare spreca un pomeriggio. Scopri quale lato rifiuta prima di modificare qualcosa.

Attiva l'accettazione delle rotte per questa macchina

Imposta la preferenza sul client, poi guarda cosa è cambiato invece di dare per scontato che il comando abbia funzionato. La forma attuale applica l'impostazione senza ripetere il flusso di accesso, il che conta quando sei a metà di una sessione.

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

Tailscale installa le rotte accettate nella propria tabella su Linux, quindi un prefisso che compare nella tabella 52 è prova diretta che questo client ha installato l'annuncio. Se il tuo intervallo manca da quella tabella, fermati: il problema è locale e nessun lavoro sul router lo cambierà.

I client più vecchi espongono la stessa preferenza come flag del comando di accesso, quindi sudo tailscale up --accept-routes è l'alternativa quando manca tailscale set. Usala invece di modificare le rotte a mano, perché il demone riscrive la propria tabella e la tua modifica sparisce alla riconnessione successiva. Controlla la versione prima di copiare un comando da un articolo vecchio.

Controlla l'annuncio e l'approvazione separatamente

Sul router di sottorete il prefisso deve essere annunciato, e il kernel deve inoltrare i pacchetti tra le interfacce. Annunciare senza inoltrare ti dà una rotta approvata che scarta il traffico in silenzio, ed è la configurazione a metà più comune.

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

Confronta il prefisso annunciato con l'indirizzo che stai davvero cercando di raggiungere, carattere per carattere. Un router che annuncia 10.70.0.0/24 non dice nulla di un NAS su 10.80.0.25, e la discrepanza è invisibile in ogni output di stato perché entrambi i numeri sembrano ugualmente plausibili. La maggior parte delle segnalazioni di una rotta rotta finisce qui. Correggi l'annuncio prima di toccare qualcosa più a valle.

L'approvazione è il cancello successivo, ed è facile saltarla quando il router è stato configurato da una shell. L'annuncio deve essere abilitato per quel dispositivo nella console di amministrazione prima che altre macchine possano usarlo. Accettare rotte sul client non approva nulla e non scavalca alcuna regola di accesso.

Prova l'indirizzo privato prima del nome host

Una connessione riuscita all'indirizzo tailnet del router stesso dimostra che il tailnet funziona, cosa che già sapevi. Il test utile è il servizio che ti serve davvero, prima verso l'indirizzo privato, così un guasto DNS non può mascherarsi da guasto di instradamento.

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 l'indirizzo risponde e il nome host no, hai un problema di risoluzione dei nomi e dovresti smettere di trattarlo come un problema di rotta. Se nessuno dei due risponde, torna indietro di una sezione e conferma che l'annuncio copra l'indirizzo. I due guasti sembrano identici dall'applicazione e si correggono in punti diversi.

Vale la pena fare un controllo locale prima di dare la colpa al tailnet. Quando la LAN attuale usa lo stesso prefisso della sottorete remota, il kernel preferisce la rotta connessa direttamente e il traffico non lascia mai la macchina; è quello che succede quando una casa e un ufficio scelgono entrambi 192.168.1.0/24.

Perché un flag del client non è un'impostazione del router

Sono ruoli diversi con requisiti diversi, e copiare un flag del client su un router è il modo in cui un tailnet funzionante si procura un loop. Una macchina che annuncia rotte ha bisogno dell'inoltro, di regole del firewall che permettano il traffico inoltrato e di una decisione su quali prefissi annuncia. Nulla di tutto ciò è implicato da --accept-routes.

La documentazione dei router di sottorete sconsiglia di abilitare l'accettazione delle rotte su router ridondanti che annunciano un solo prefisso, perché un nodo di standby può spingere traffico già locale attraverso quello attivo. Se gestisci una coppia HA, trattalo come un vincolo di progettazione e non come una nota a piè di pagina, e decidi quale nodo possiede il prefisso prima di approvarlo su entrambi. Su un singolo router lo stesso avviso si legge come un promemoria che l'accettazione spetta ai client, non alla macchina che annuncia. Annota quale cancello era chiuso.

Per un client ordinario la sequenza termina con il test applicativo fallito all'inizio. Per il router, esamina inoltro, annuncio, approvazione e firewall in quest'ordine, perché il primo mancante produce esattamente il timeout con cui hai iniziato.