Un host Tailscale irraggiungibile: router di sottorete o nodo di uscita?

Un host Tailscale risponde mentre un altro resta al buio, oppure tutto funziona finché i siti web pubblici iniziano a segnalare il paese sbagliato. Entrambe le lamentele arrivano come «Tailscale è rotto», ed entrambe sono di solito la costruzione sbagliata attivata per la destinazione sbagliata. Un router di sottorete espone una rete privata alla tailnet, mentre un nodo di uscita cambia da dove esce il traffico internet. Ordina prima la destinazione che fallisce, poi scegli il ruolo che la copre.

Parti dalla destinazione che ha fallito

Annota l'indirizzo o il nome che non ha funzionato e che tipo di cosa è. Un dispositivo su una LAN privata dietro un'altra sede, un servizio sul tuo segmento e un sito web pubblico sono tre problemi di routing che condividono un solo client per caso. La distinzione non è estetica, perché le due costruzioni coprono insiemi diversi di destinazioni. Attivarne una non fa nulla per l'altra, e questa è tutta la fonte della confusione.

Considera anche la famiglia di indirizzi. Una sottorete annunciata solo come IPv4 lascia le destinazioni IPv6 sul percorso locale, cosa che si legge come un guasto parziale finché qualcuno non confronta le due tabelle di routing. Annota quale percorso ti aspettavi, così il test avrà poi qualcosa da contraddire.

Raggiungi un dispositivo che non esegue mai Tailscale

Il router annuncia intervalli specifici alla tailnet, poi inoltra i pacchetti tra la tailnet e il segmento privato, quindi i dispositivi di quel segmento non hanno bisogno di un proprio client. Raggiungere un NAS in ufficio da un portatile a casa è esattamente questo caso. Il router è l'unico membro della tailnet su quel lato.

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

L'annuncio è solo la prima di tre condizioni. La rotta deve essere approvata per la tailnet, il client deve accettare le rotte annunciate, e una regola di accesso deve consentire la connessione. È questa catena il motivo per cui il sintomo è così spesso che il router è attivo e il NAS no. Un router raggiungibile dimostra che il tunnel funziona; non dimostra nulla su approvazione, accettazione del client o criterio.

Ognuno di questi tre guasti si presenta diversamente nella console di amministrazione. Controllali in ordine invece di cambiarli tutti e tre insieme, perché un secondo cambiamento nasconde quale contava.

Fai uscire il traffico pubblico da un'altra macchina

Un nodo di uscita instrada il tuo traffico internet generale attraverso se stesso, che è l'equivalente più vicino al tunnel completo di altri prodotti VPN. Anche lui richiede tre consensi separati: il dispositivo annuncia il ruolo, un amministratore lo consente e il client lo seleziona. Unirsi a una tailnet non invia nulla attraverso un altro membro per impostazione predefinita.

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

Selezionare un nodo di uscita non concede automaticamente l'accesso alla sua LAN. L'opzione di accesso alla LAN esiste proprio perché sono permessi diversi, e lasciarla disattivata è l'impostazione predefinita più sicura. Le rotte verso altre risorse Tailscale mantengono la propria gestione anche mentre un nodo di uscita è attivo. Per questo un servizio ospitato in una sottorete può continuare a funzionare mentre il percorso internet pubblico è cambiato.

Un nodo di uscita cambia anche come internet ti vede, non solo quanto sembra veloce. Aspettati che geolocalizzazione, cataloghi di streaming e limiti di velocità seguano l'indirizzo dell'uscita e non il tuo.

Leggi la divisione in tre quando fallisce un solo host

Una stampante sul tuo segmento, un NAS dietro un router di sottorete remoto e un sito pubblico sono tre destinazioni con tre percorsi diversi. Se esattamente una di esse fallisce, il difetto appartiene al percorso di quella destinazione e non al client nel suo insieme. Per la stampante locale mentre è in uso un nodo di uscita, l'impostazione di accesso alla LAN è la risposta abituale. Per il NAS remoto, controlla l'intervallo annunciato, il suo stato di approvazione e le regole di accesso in quest'ordine. Per un sito pubblico, controlla quale nodo di uscita è selezionato e se il client lo ha davvero accettato.

Se l'indirizzo funziona e il nome no, smetti di guardare le rotte. Il DNS privato si configura separatamente, e un nome che risolve all'indirizzo sbagliato fallisce in un modo che sembra identico a una rotta bloccata. Prova prima l'indirizzo, poi il nome, e i due risultati ti dicono quale livello aprire.

Conferma il percorso che credi di aver costruito

La verifica è una ricerca di rotta più un controllo dell'indirizzo, non un ping. La ricerca dice quale interfaccia userebbe una destinazione, e il controllo dell'indirizzo dice in quale intervallo vive davvero la destinazione. Un ping che riesce dice che l'host è vivo da qualche parte, il che non è la domanda. Esegui entrambi prima di cambiare qualsiasi configurazione.

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

Abbinalo alla vista della tailnet stessa, che mostra se il peer è connesso direttamente o inoltrato. Un percorso inoltrato funziona comunque, e questo spiega lamentele di latenza che non hanno nulla a che fare con la rotta che stavi depurando. La documentazione del router di sottorete copre il passo di approvazione se non ti è familiare. Poi annota quale costruzione copre quale destinazione nella tua rete, perché la prossima persona che aggiungerà una sede farà la stessa domanda.