Varför Linux-Tailscale-klienten ignorerar annonserade subnettrutter

Du sitter på en Linux-bärbar dator, tailscale status listar de andra maskinerna, och NAS:en på 10.80.0.25 får fortfarande timeout. Tailnätet är friskt, subnettrutern är online, och ingenting i klientens utdata säger varför LAN:et bakom den är oåtkomligt. Genomgången nedan rör sig utåt från det symptomet: flaggan på den här klienten, sedan annonseringen på ruttern, sedan godkännandet, sedan policyn, och först därefter själva målet. Varje port misslyckas med samma timeout, så ordningen spelar större roll än kommandona.

Vad Linux-klienten vägrar att installera

Tailscale-klienter på Linux accepterar inte annonserade subnettrutter om du inte ber dem om det. Utan den inställningen går klienten med i tailnätet och når peer-adresser, medan varje prefix som ruttern annonserar förblir oanvänt. Standardvärdet är avsiktligt, och därför ser symptomet ut som en trasig router snarare än ett lokalt beslut.

Två olika saker kallas routning här, och bara en av dem är din. Ruttern annonserar ett prefix i tailnätet; din maskin avgör om det ska installeras. Ett fel i endera ger samma timeout, därför slösar gissningar bort en eftermiddag. Ta reda på vilken sida som vägrar innan du ändrar något.

Slå på ruttacceptans för den här maskinen

Ställ in preferensen på klienten och titta sedan på vad som ändrades i stället för att anta att kommandot verkade. Den nuvarande formen tillämpar inställningen utan att upprepa inloggningsflödet, vilket spelar roll när du är mitt i en session.

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

Tailscale installerar accepterade rutter i sin egen tabell på Linux, så ett prefix som dyker upp i tabell 52 är direkta bevis på att den här klienten installerade annonseringen. Om ditt intervall saknas i den tabellen, sluta: problemet är lokalt och ingen mängd arbete på ruttern ändrar det.

Äldre klienter erbjuder samma preferens som en flagga på inloggningskommandot, så sudo tailscale up --accept-routes är reservvalet när tailscale set saknas. Använd det i stället för att redigera rutter för hand, eftersom daemonen skriver om sin egen tabell och din ändring försvinner vid nästa återanslutning. Kontrollera versionen innan du kopierar ett kommando från ett äldre inlägg.

Kontrollera annonseringen och godkännandet separat

På subnettrutern måste prefixet annonseras, och kärnan måste vidarebefordra paket mellan gränssnitt. Annonsering utan vidarebefordran ger dig en godkänd rutt som tyst tappar trafik, och det är den vanligaste halvfärdiga konfigurationen.

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

Jämför det annonserade prefixet med den adress du faktiskt försöker nå, tecken för tecken. En router som annonserar 10.70.0.0/24 säger ingenting om en NAS på 10.80.0.25, och avvikelsen är osynlig i varje statusutdata eftersom båda talen ser lika rimliga ut. De flesta rapporterna om en trasig rutt slutar här. Rätta annonseringen innan du rör något längre ned.

Godkännandet är nästa port, och det är lätt att hoppa över när ruttern konfigurerades från ett skal. Annonseringen måste vara aktiverad för den enheten i administrationskonsolen innan andra maskiner får använda den. Att acceptera rutter på klienten godkänner ingenting och åsidosätter ingen åtkomstrregel.

Testa den privata adressen före värdnamnet

En lyckad anslutning till rutterns egen tailnätadress bevisar att tailnätet fungerar, vilket du redan visste. Det användbara testet är den tjänst du faktiskt behöver, först mot den privata adressen, så att ett DNS-fel inte kan uppträda som ett routningsfel.

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

Om adressen svarar och värdnamnet inte, har du ett namnupplösningsproblem och bör sluta behandla det som ett ruttproblem. Om ingen av dem svarar, gå en sektion tillbaka och bekräfta att annonseringen täcker adressen. De två felen ser identiska ut från applikationen och rättas på olika ställen.

En lokal kontroll är värd att göra innan du skyller på tailnätet. När ditt nuvarande LAN använder samma prefix som det avlägsna subnätet föredrar kärnan den direkt anslutna rutten, och trafiken lämnar aldrig maskinen; det är vad som händer när ett hem och ett kontor båda väljer 192.168.1.0/24.

Varför en klientflagga inte är en routerinställning

Det här är olika roller med olika krav, och att kopiera en klientflagga till en router är sättet en fungerande tailnet får en slinga. En maskin som annonserar rutter behöver vidarebefordran, brandväggsregler som tillåter den vidarebefordrade trafiken, och ett beslut om vilka prefix den annonserar. Inget av detta impliceras av --accept-routes.

Dokumentationen för subnettrutrar varnar för att slå på ruttacceptans på redundanta routrar som annonserar ett prefix, eftersom en standby-nod kan trycka ut trafik som redan är lokal genom den aktiva. Kör du ett HA-par, behandla det som en designbegränsning och inte en fotnot, och bestäm vilken nod som äger prefixet innan du godkänner det på båda. På en enda router läses samma varning som en påminnelse om att acceptans hör till klienterna, inte till maskinen som annonserar. Skriv ned vilken port som var stängd.

För en vanlig klient slutar sekvensen med applikationstestet som misslyckades i början. För ruttern, gå igenom vidarebefordran, annonsering, godkännande och brandvägg i den ordningen, eftersom den första som saknas ger exakt den timeout du började med.