Perché una rotta di sottorete Tailscale approvata va ancora in timeout

L’approvazione nella console di amministrazione sembra l’ultimo passo, e non lo è. Prima l’applicazione va in timeout, e solo dopo scoprite il router online e la rotta approvata. L’approvazione è un passo di distribuzione, non un permesso e non una garanzia di inoltro. Quattro fasi devono allinearsi prima che un pacchetto raggiunga un host dietro un router di sottorete, e ciascuna può riuscire mentre la successiva fallisce. Percorreteli in ordine e fermatevi alla prima fase che non regge.

Quattro fasi, un guasto

Il router annuncia il prefisso, la tailnet approva quell’annuncio, il client accetta la rotta ricevuta e la politica di accesso consente la connessione specifica. Sono quattro decisioni separate prese da tre componenti diversi. Una rotta approvata dice quindi solo che la rete ora fa parte della tabella di routing della tailnet.

La quarta fase è quella più spesso saltata, perché le prime tre producono uno stato visibile. Un’autorizzazione che copre l’indirizzo tailnet del router stesso non copre automaticamente una sottorete privata dietro di esso. Sono destinazioni diverse, e la politica viene valutata per destinazione.

Su Linux la terza fase ha anche un valore predefinito che sorprende: accettare le rotte di sottorete è facoltativo. Diversi client con interfaccia grafica accettano per impostazione predefinita le rotte annunciate, quindi una flotta mista può mostrare una macchina che fallisce mentre le altre funzionano.

Confermate l’impostazione sulla macchina che fallisce invece di supporre una piattaforma. La rotta non è mai stata il pezzo mancante sulle macchine che funzionano, quindi lasciate che siano loro a dimostrare che il lato tailnet è sano. La documentazione di Tailscale sui router di sottorete copre l’approvazione, l’accettazione delle rotte sul client e la fase di politica.

Controllate la rotta dove gira il client

Iniziate dal client che fallisce, non dal router. Confermate che la rotta sia presente e che l’impostazione del client consenta l’accettazione delle rotte.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Il primo comando mostra l’elenco dei peer e se il router di sottorete è raggiungibile, il secondo stampa le preferenze del client incluso il flag di accettazione delle rotte, e il terzo chiede al kernel quale interfaccia userebbe per un host reale sulla sottorete. Se quell’ultimo comando nomina l’interfaccia fisica invece dell’interfaccia Tailscale, la rotta non è mai entrata nella tabella. Una rotta assente è un problema lato client, non di approvazione. Correggetelo prima di guardare la politica.

Per accettare le rotte su Linux, riconnettetevi con il flag invece di supporre che sia impostato: tailscale up --accept-routes. Un client che è stato aggiunto con altri flag li mantiene finché non vengono modificati, quindi controllate l’impostazione attuale prima di aggiungerne un’altra. Rieseguire il primo comando dopo la modifica dovrebbe mostrare la rotta nella tabella.

Dimostrate l’inoltro e il percorso di ritorno

L’approvazione non configura il router per inoltrare i pacchetti e non organizza la risposta. Entrambe sono questioni a livello di host sul lato LAN del router. Provatele sul router, non sul client.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Il primo comando deve riportare 1, altrimenti il kernel scarterà il pacchetto inoltrato. Il secondo mostra se il mascheramento della rotta di sottorete riscrive la sorgente, che è il comportamento predefinito e di solito quello che volete. Il terzo mostra se la richiesta raggiunge la destinazione e se qualcosa torna; una richiesta senza risposta è un problema del percorso di ritorno, non di approvazione. Leggete i tre risultati insieme prima di modificarne uno.

Se il mascheramento è stato disattivato, la rete di destinazione ha bisogno di una rotta di ritorno verso gli indirizzi della tailnet, e ogni salto intermedio deve conoscerla. Riattivare il mascheramento è la correzione più rapida per un singolo servizio, al prezzo di nascondere l’indirizzo originale del client alla destinazione. Questo compromesso conta quando la destinazione registra gli indirizzi di origine per l’audit, quindi decidete consapevolmente invece di ribaltare il flag durante un incidente. Documentate quale scelta avete fatto, perché la persona successiva vedrà solo uno dei due comportamenti.

Leggete la regola di accesso per la risorsa

Con la rotta presente e l’inoltro dimostrato, il sospetto rimasto è la politica. Leggete l’autorizzazione che dovrebbe consentire la connessione e controllate la sua destinazione, non solo la sorgente. Anche l’identità del client deve corrispondere al selettore della politica, quindi rilevatela dalla stessa macchina che fallisce.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

L’output di stato identifica gli indirizzi del client stesso e i peer che vede, ed è a questo che deve corrispondere il selettore di origine della politica. tailscale ping dimostra il percorso tailnet fino al router di sottorete stesso; risolve nomi di peer e indirizzi tailnet, non host dentro una sottorete annunciata. Il terzo comando invia un normale eco ICMP attraverso la rotta di sottorete, quindi il risultato descrive la destinazione invece del router. Un rifiuto a livello tailnet di solito torna come rifiuto, mentre un pacchetto che parte e non torna mai va in timeout.

Un nome che fallisce è una questione diversa da un indirizzo che fallisce; risolvete l’host direttamente prima di dare la colpa alla rotta. Scrivete l’autorizzazione secondo il requisito reale della risorsa e non secondo tutta la sottorete. Aprire un’intera /24 perché un’applicazione funzioni è il modo in cui una richiesta stretta diventa un permesso ampio che poi nessuno osa rimuovere.

Se l’obiettivo era l’uscita su internet e non una sottorete privata, il componente corretto è un nodo di uscita, non un router di sottorete, e la politica e l’instradamento differiscono di conseguenza. Verificate quella decisione prima di ampliare un’autorizzazione. Un nodo di uscita cambia la rotta predefinita; un router di sottorete annuncia solo un prefisso.