Hvorfor Linux-Tailscale-klienten ignorerer annoncerede subnetruter

Du sidder på en Linux-bærbar, tailscale status viser de andre maskiner, og NAS'en på 10.80.0.25 får stadig timeout. Tailnettet er sundt, subnetrouteren er online, og intet i klientens output siger hvorfor LAN'et bag den er utilgængeligt. Gennemgangen nedenfor bevæger sig udad fra det symptom: flaget på denne klient, så annonceringen på routeren, så godkendelse, så politik, og først derefter selve destinationen. Hver port fejler med samme timeout, så rækkefølgen betyder mere end kommandoerne.

Hvad Linux-klienten nægter at installere

Tailscale-klienter på Linux accepterer ikke annoncerede subnetruter, medmindre du beder dem om det. Uden den indstilling tilslutter klienten sig tailnettet og når peer-adresser, mens hvert præfiks routeren annoncerer forbliver ubrugt. Standardværdien er bevidst, og det er derfor symptomet ligner en defekt router snarere end en lokal beslutning.

To forskellige ting kaldes routing her, og kun den ene er din. Routeren annoncerer et præfiks i tailnettet; din maskine afgør, om det skal installeres. En fejl i begge giver samme timeout, og derfor spilder gætteri en eftermiddag. Find ud af, hvilken side der nægter, før du redigerer noget.

Slå ruteaccept til for denne maskine

Sæt præferencen på klienten, og se derefter hvad der ændrede sig, i stedet for at antage at kommandoen virkede. Den nuværende form anvender indstillingen uden at gentage loginflowet, hvilket betyder noget, når du er midt i en session.

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

Tailscale installerer accepterede ruter i sin egen tabel på Linux, så et præfiks, der optræder i tabel 52, er direkte bevis på, at denne klient har installeret annonceringen. Hvis dit område mangler i tabellen, så stop: problemet er lokalt, og ingen mængde arbejde på routeren ændrer det.

Ældre klienter eksponerer samme præference som et flag på login-kommandoen, så sudo tailscale up --accept-routes er reservevalget, når tailscale set mangler. Brug det i stedet for at redigere ruter i hånden, fordi daemonen omskriver sin egen tabel, og din ændring forsvinder ved næste genopkobling. Tjek versionen, før du kopierer en kommando fra et ældre indlæg.

Kontrollér annonceringen og godkendelsen hver for sig

På subnetrouteren skal præfikset annonceres, og kernen skal videresende pakker mellem grænseflader. Annoncering uden videresendelse giver dig en godkendt rute, der lydløst dropper trafik, hvilket er det mest almindelige halvfærdige setup.

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

Sammenlign det annoncerede præfiks med den adresse, du faktisk prøver at nå, tegn for tegn. En router, der annoncerer 10.70.0.0/24, siger intet om en NAS på 10.80.0.25, og uoverensstemmelsen er usynlig i ethvert statusoutput, fordi begge tal ser lige plausible ud. De fleste rapporter om en brudt rute ender her. Ret annonceringen, før du rører noget længere nede.

Godkendelse er den næste port, og den er let at springe over, når routeren blev konfigureret fra en shell. Annonceringen skal være aktiveret for den enhed i administrationskonsollen, før andre maskiner må bruge den. At acceptere ruter på klienten godkender intet og tilsidesætter ingen adgangsregel.

Test den private adresse før værtsnavnet

En vellykket forbindelse til routerens egen tailnet-adresse beviser, at tailnettet virker, hvilket du allerede vidste. Den nyttige test er den tjeneste, du faktisk har brug for, først mod den private adresse, så en DNS-fejl ikke kan optræde som en routingfejl.

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 værtsnavnet ikke gør, har du et navneopløsningsproblem og bør holde op med at behandle det som et ruteproblem. Hvis ingen af dem svarer, gå et afsnit tilbage og bekræft, at annonceringen dækker adressen. De to fejl ser identiske ud fra applikationen og rettes på forskellige steder.

Én lokal kontrol er værd at lave, før du bebrejder tailnettet. Når dit nuværende LAN bruger samme præfiks som det fjerne subnet, foretrækker kernen den direkte forbundne rute, og trafikken forlader aldrig maskinen; det er, hvad der sker, når et hjem og et kontor begge vælger 192.168.1.0/24.

Hvorfor et klientflag ikke er en routerindstilling

Det er forskellige roller med forskellige krav, og at kopiere et klientflag over på en router er måden, en fungerende tailnet får en løkke på. En maskine, der annoncerer ruter, har brug for videresendelse, firewallregler der tillader den videresendte trafik, og en beslutning om, hvilke præfikser den annoncerer. Intet af det er implicit i --accept-routes.

Dokumentationen for subnetroutere advarer mod at slå ruteaccept til på redundante routere, der annoncerer ét præfiks, da en standby-node kan skubbe trafik, der allerede er lokal, ud gennem den aktive. Hvis du kører et HA-par, så behandl det som en designbegrænsning, ikke en fodnote, og beslut, hvilken node der ejer præfikset, før du godkender det på begge. På en enkelt router læses samme advarsel som en påmindelse om, at accept hører til klienterne, ikke til maskinen, der annoncerer. Skriv ned, hvilken port der var lukket.

For en almindelig klient slutter sekvensen med applikationstesten, der fejlede i starten. For routeren skal du gennemgå videresendelse, annoncering, godkendelse og firewall i den rækkefølge, fordi den første, der mangler, giver præcis den timeout, du startede med.