Hvorfor Linux-Tailscale-klienten ignorerer annonserte subnett-ruter

Du sitter på en Linux-bærbar, tailscale status viser de andre maskinene, og NAS-en på 10.80.0.25 får fortsatt tidsavbrudd. Tailnettet er sunt, subnett-ruteren er på nett, og ingenting i klientens utdata sier hvorfor LAN-et bak den er utilgjengelig. Gjennomgangen nedenfor beveger seg utover fra det symptomet: flagget på denne klienten, så annonseringen på ruteren, så godkjenningen, så policyen, og først deretter selve målet. Hver port feiler med samme tidsavbrudd, så rekkefølgen betyr mer enn kommandoene.

Hva Linux-klienten nekter å installere

Tailscale-klienter på Linux aksepterer ikke annonserte subnett-ruter med mindre du ber dem om det. Uten den innstillingen blir klienten med i tailnettet og når peer-adresser, mens hvert prefiks ruteren annonserer forblir ubrukt. Standardverdien er bevisst, og derfor ser symptomet ut som en ødelagt ruter snarere enn en lokal beslutning.

To forskjellige ting kalles ruting her, og bare én av dem er din. Ruteren annonserer et prefiks i tailnettet; maskinen din bestemmer om det skal installeres. En feil i hvilken som helst av dem gir samme tidsavbrudd, og derfor kaster gjetting bort en ettermiddag. Finn ut hvilken side som nekter før du redigerer noe.

Slå på ruteaksept for denne maskinen

Sett innstillingen på klienten, og se deretter på hva som endret seg i stedet for å anta at kommandoen virket. Den nåværende formen bruker innstillingen uten å gjenta innloggingsflyten, noe som betyr noe når du er midt i en økt.

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

Tailscale installerer aksepterte ruter i sin egen tabell på Linux, så et prefiks som dukker opp i tabell 52 er direkte bevis på at denne klienten installerte annonseringen. Hvis området ditt mangler i den tabellen, stopp: problemet er lokalt, og ingen mengde arbeid på ruteren endrer det.

Eldre klienter eksponerer samme innstilling som et flagg på innloggingskommandoen, så sudo tailscale up --accept-routes er reservevalget når tailscale set mangler. Bruk det i stedet for å redigere ruter for hånd, fordi daemonen skriver om sin egen tabell, og endringen din forsvinner ved neste gjenoppkobling. Sjekk versjonen før du kopierer en kommando fra et eldre innlegg.

Kontroller annonseringen og godkjenningen hver for seg

På subnett-ruteren må prefikset annonseres, og kjernen må videresende pakker mellom grensesnitt. Annonsering uten videresending gir deg en godkjent rute som stille slipper trafikken, og det er det vanligste halvferdige oppsettet.

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

Sammenlign det annonserte prefikset med adressen du faktisk prøver å nå, tegn for tegn. En ruter som annonserer 10.70.0.0/24 sier ingenting om en NAS på 10.80.0.25, og avviket er usynlig i enhver statusutdata fordi begge tallene ser like plausible ut. De fleste rapportene om en ødelagt rute ender her. Rett annonseringen før du rører noe lenger ned.

Godkjenning er neste port, og den er lett å hoppe over når ruteren ble konfigurert fra en shell. Annonseringen må være aktivert for den enheten i administrasjonskonsollen før andre maskiner kan bruke den. Å akseptere ruter på klienten godkjenner ingenting og overstyrer ingen tilgangsregel.

Test den private adressen før vertsnavnet

En vellykket tilkobling til ruterens egen tailnet-adresse beviser at tailnettet virker, noe du allerede visste. Den nyttige testen er tjenesten du faktisk trenger, først mot den private adressen, slik at en DNS-feil ikke kan opptre som en rutingsfeil.

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

Hvis adressen svarer og vertsnavnet ikke, har du et navneoppløsningsproblem og bør slutte å behandle det som et ruteproblem. Hvis ingen av dem svarer, gå en seksjon tilbake og bekreft at annonseringen dekker adressen. De to feilene ser identiske ut fra applikasjonen og rettes på forskjellige steder.

Én lokal sjekk er verdt å gjøre før du klandrer tailnettet. Når ditt nåværende LAN bruker samme prefiks som det eksterne subnettet, foretrekker kjernen den direkte tilkoblede ruten, og trafikken forlater aldri maskinen; det er det som skjer når et hjem og et kontor begge velger 192.168.1.0/24.

Hvorfor et klientflagg ikke er en ruterinnstilling

Dette er forskjellige roller med forskjellige krav, og å kopiere et klientflagg over på en ruter er måten et fungerende tailnet får en løkke. En maskin som annonserer ruter trenger videresending, brannmurregler som tillater den videresendte trafikken, og en beslutning om hvilke prefikser den annonserer. Ingenting av dette er implisert av --accept-routes.

Dokumentasjonen for subnett-rutere advarer mot å slå på ruteaksept på redundante rutere som annonserer ett prefiks, siden en standby-node kan skyve trafikk som allerede er lokal ut gjennom den aktive. Hvis du kjører et HA-par, behandle det som en designbegrensning og ikke en fotnote, og bestem hvilken node som eier prefikset før du godkjenner det på begge. På en enkelt ruter leses samme advarsel som en påminnelse om at aksept hører til klientene, ikke til maskinen som annonserer. Skriv ned hvilken port som var lukket.

For en vanlig klient ender sekvensen med applikasjonstesten som feilet i starten. For ruteren, gå gjennom videresending, annonsering, godkjenning og brannmur i den rekkefølgen, fordi den første som mangler gir nøyaktig det tidsavbruddet du begynte med.