Kvifor Linux-Tailscale-klienten ignorerer annonserte subnett-ruter

Du sit på ei Linux-berbar datamaskin, tailscale status listar dei andre maskinene, og NAS-en på 10.80.0.25 får framleis tidsavbrot. Tailnettet er sunt, subnett-rutaren er på nett, og ingenting i utdataa frå klienten seier kvifor LAN-et bak han er utilgjengeleg. Gjennomgangen nedanfor flyttar seg utover frå det symptomet: flagget på denne klienten, så annonseringa på rutaren, så godkjenninga, så policyen, og først deretter sjølve målet. Kvar port feilar med same tidsavbrot, så rekkjefølgja tyder meir enn kommandoane.

Kva Linux-klienten nektar å installere

Tailscale-klientar på Linux godtek ikkje annonserte subnett-ruter med mindre du ber dei om det. Utan den innstillinga blir klienten med i tailnettet og når peer-adresser, medan kvart prefiks rutaren annonserer blir ståande ubrukt. Standardverdien er medvite vald, og difor ser symptomet ut som ein øydelagd ruter snarare enn ei lokal avgjerd.

To ulike ting blir kalla ruting her, og berre éin av dei er din. Rutaren annonserer eit prefiks i tailnettet; maskina di avgjer om det skal installerast. Ein feil i kva som helst av dei gir same tidsavbrot, og difor kastar gjetting bort ein ettermiddag. Finn ut kva side som nektar før du endrar noko.

Slå på ruteaksept for denne maskina

Set innstillinga på klienten, og sjå deretter kva som endra seg i staden for å gå ut frå at kommandoen verka. Den noverande forma brukar innstillinga utan å gjenta innloggingsflyten, noko som tyder noko når du er midt i ei økt.

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

Tailscale installerer godtekne ruter i sin eigen tabell på Linux, så eit prefiks som dukkar opp i tabell 52 er direkte prov på at denne klienten installerte annonseringa. Viss området ditt manglar i den tabellen, stopp: problemet er lokalt, og inga mengd arbeid på rutaren endrar det.

Eldre klientar eksponerer same innstillinga som eit flagg på innloggingskommandoen, så sudo tailscale up --accept-routes er reservevalet når tailscale set manglar. Bruk det i staden for å redigere ruter for hand, fordi daemonen skriv om sin eigen tabell, og endringa di forsvinn ved neste attkopling. Sjekk versjonen før du kopierer ein kommando frå eit eldre innlegg.

Kontroller annonseringa og godkjenninga kvar for seg

På subnett-rutaren må prefikset annonserast, og kjernen må vidaresende pakkar mellom grensesnitt. Annonsering utan vidaresending gir deg ei godkjend rute som stille slepp trafikken, og det er det vanlegaste halvferdige oppsettet.

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

Samanlikn det annonserte prefikset med adressa du faktisk prøver å nå, teikn for teikn. Ein ruter som annonserer 10.70.0.0/24 seier ingenting om ein NAS på 10.80.0.25, og avviket er usynleg i kvar statusutdata fordi begge tala ser like truverdige ut. Dei fleste rapportane om ei øydelagd rute endar her. Rett annonseringa før du rører noko lenger nede.

Godkjenning er neste port, og ho er lett å hoppe over når rutaren vart konfigurert frå ein shell. Annonseringa må vere slått på for den eininga i administrasjonskonsollen før andre maskiner kan bruke ho. Å godta ruter på klienten godkjenner ingenting og overstyrer inga tilgangsregel.

Test den private adressa før vertsnamnet

Ei vellukka tilkopling til rutaren si eiga tailnet-adresse provar at tailnettet verkar, noko du alt visste. Den nyttige testen er tenesta du faktisk treng, først mot den private adressa, slik at ein DNS-feil ikkje kan opptre som ein 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

Viss adressa svarar og vertsnamnet ikkje, har du eit namneoppløysingsproblem og bør slutte å handsame det som eit ruteproblem. Viss ingen av dei svarar, gå ein seksjon tilbake og stadfest at annonseringa dekkjer adressa. Dei to feila ser identiske ut frå applikasjonen og blir retta på ulike stader.

Éin lokal sjekk er verd å gjere før du klandrar tailnettet. Når det noverande LAN-et ditt brukar same prefiks som det eksterne subnettet, føretrekk kjernen den direkte tilkopla ruta, og trafikken forlèt aldri maskina; det er det som skjer når eit heim og eit kontor båe vel 192.168.1.0/24.

Kvifor eit klientflagg ikkje er ei ruterinnstilling

Dette er ulike roller med ulike krav, og å kopiere eit klientflagg over på ein ruter er måten eit fungerande tailnet får ei løkke. Ei maskin som annonserer ruter treng vidaresending, brannmurreglar som tillèt den vidaresende trafikken, og ei avgjerd om kva prefiks ho annonserer. Ingenting av dette er implisert av --accept-routes.

Dokumentasjonen for subnett-rutarar åtvarar mot å slå på ruteaksept på redundante rutarar som annonserer eitt prefiks, sidan ein standby-node kan skyve trafikk som alt er lokal ut gjennom den aktive. Køyrer du eit HA-par, handsam det som ei designavgrensing og ikkje ei fotnote, og avgjer kva node som eig prefikset før du godkjenner det på båe. På ein enkel ruter blir same åtvaringa lesen som ei påminning om at aksept høyrer til klientane, ikkje til maskina som annonserer. Skriv ned kva port som var lukka.

For ein vanleg klient endar sekvensen med applikasjonstesten som feila i starten. For rutaren, gå gjennom vidaresending, annonsering, godkjenning og brannmur i den rekkjefølgja, fordi den første som manglar gir nøyaktig det tidsavbrotet du byrja med.