Hvorfor Linux-Tailscale-klienten overser annonserte subnett-ruter

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

Det Linux-klienten nekter å installere

Tailscale-klienter på Linux godtar ikke annonserte subnett-ruter uten at du ber om det. Uten denne innstillingen blir klienten med i tailnettet og når peer-adresser, mens hvert prefiks ruteren annonserer forblir ubrukt. Standardverdien er tilsiktet, og derfor ser symptomet ut som en defekt ruter og ikke som en lokal beslutning.

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

Aktiver ruteaksept for denne maskinen

Angi preferansen på klienten, og se deretter hva som endret seg i stedet for å anta at kommandoen virket. Den nåværende formen anvender 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 godtatte ruter i sin egen tabell på Linux, så et prefiks som dukker opp i tabell 52 er direkte bevis for 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 tilbyr samme preferanse 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 manuelt, 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.

Sjekk annonseringen og godkjenningen hver for seg

På subnett-ruteren må prefikset annonseres, og kjernen må videresende pakker mellom grensesnitt. Annonsering uten videresending gir en godkjent rute som stille dropper 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 virker like plausible. De fleste rapportene om en ødelagt rute ender her. Rett annonseringen før du berø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. Å godta ruter på klienten godkjenner ingenting og overstyrer ingen tilgangsregel.

Prøv den private adressen før vertsnavnet

En vellykket tilkobling til ruterens egen tailnet-adresse beviser at tailnettet fungerer, 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 like ut fra applikasjonen og rettes på forskjellige steder.

Én lokal sjekk er verdt å gjøre før du gir tailnettet skylden. 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 til 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 å aktivere ruteaksept på redundante rutere som annonserer ett prefiks, siden en standby-node kan skyve trafikk som allerede er lokal ut gjennom den aktive. Kjører du et HA-par, bør du behandle det som en designbegrensning og ikke en fotnote, og bestemme 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. Noter hvilken port som var lukket.

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