Waarom de Linux-Tailscale-client geadverteerde subnetroutes negeert

Je zit op een Linux-laptop, tailscale status somt de andere machines op, en de NAS op 10.80.0.25 loopt nog steeds in een time-out. Het tailnet is gezond, de subnetrouter is online, en niets in de uitvoer van de client zegt waarom het LAN erachter onbereikbaar is. De uitleg hieronder beweegt van dat symptoom naar buiten: de vlag op deze client, dan de advertentie op de router, dan de goedkeuring, dan het beleid, en pas daarna de bestemming zelf. Elke poort faalt met dezelfde time-out, dus de volgorde is belangrijker dan de commando's.

Wat de Linux-client weigert te installeren

Tailscale-clients op Linux accepteren geen geadverteerde subnetroutes tenzij je erom vraagt. Zonder die instelling wordt de client lid van het tailnet en bereikt hij peeradressen, terwijl elk prefix dat de router adverteert ongebruikt blijft. De standaardwaarde is bewust, en daarom lijkt het symptoom op een kapotte router en niet op een lokale beslissing.

Twee verschillende dingen heten hier routing, en slechts één ervan is van jou. De router adverteert een prefix in het tailnet; jouw machine beslist of die wordt geïnstalleerd. Een fout in een van beide geeft dezelfde time-out, daarom verspilt gissen een middag. Zoek uit welke kant weigert voordat je iets aanpast.

Zet routeacceptatie aan voor deze machine

Zet de voorkeur op de client en kijk dan wat er veranderd is in plaats van aan te nemen dat het commando werkte. De huidige vorm past de instelling toe zonder de inlogstroom te herhalen, wat uitmaakt als je midden in een sessie zit.

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

Tailscale installeert geaccepteerde routes in zijn eigen tabel op Linux, dus een prefix in tabel 52 is direct bewijs dat deze client de advertentie heeft geïnstalleerd. Ontbreekt jouw bereik in die tabel, stop dan: het probleem is lokaal en geen enkele hoeveelheid werk op de router verandert dat.

Oudere clients bieden dezelfde voorkeur als vlag op het inlogcommando, dus sudo tailscale up --accept-routes is de terugvaloptie wanneer tailscale set ontbreekt. Gebruik die in plaats van routes met de hand te bewerken, want de daemon herschrijft zijn eigen tabel en je wijziging verdwijnt bij de volgende herverbinding. Controleer de versie voordat je een commando uit een ouder bericht kopieert.

Controleer de advertentie en de goedkeuring apart

Op de subnetrouter moet het prefix geadverteerd worden, en de kernel moet pakketten tussen interfaces doorsturen. Adverteren zonder doorsturen geeft je een goedgekeurde route die verkeer stil laat vallen, en dat is de meest voorkomende half afgemaakte opstelling.

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

Vergelijk het geadverteerde prefix teken voor teken met het adres dat je werkelijk probeert te bereiken. Een router die 10.70.0.0/24 adverteert zegt niets over een NAS op 10.80.0.25, en de mismatch is onzichtbaar in elke statusuitvoer omdat beide getallen even plausibel lijken. De meeste meldingen van een kapotte route eindigen hier. Repareer de advertentie voordat je iets stroomafwaarts aanraakt.

Goedkeuring is de volgende poort, en die is makkelijk over te slaan wanneer de router vanaf een shell is geconfigureerd. De advertentie moet voor dat apparaat in de beheerconsole zijn ingeschakeld voordat andere machines hem mogen gebruiken. Routes accepteren op de client keurt niets goed en omzeilt geen toegangsregel.

Test het privéadres vóór de hostnaam

Een geslaagde verbinding met het eigen tailnetadres van de router bewijst dat het tailnet werkt, wat je al wist. De nuttige test is de dienst die je echt nodig hebt, eerst tegen het privéadres, zodat een DNS-fout zich niet kan voordoen als een routeringsfout.

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

Als het adres antwoordt en de hostnaam niet, heb je een naamresolutieprobleem en moet je ophouden het als een routeprobleem te behandelen. Als geen van beide antwoordt, ga een sectie terug en bevestig dat de advertentie het adres dekt. De twee fouten zien er vanuit de applicatie identiek uit en worden op verschillende plekken opgelost.

Eén lokale controle is de moeite waard voordat je het tailnet de schuld geeft. Wanneer je huidige LAN hetzelfde prefix gebruikt als het externe subnet, geeft de kernel de voorkeur aan de direct verbonden route en verlaat het verkeer de machine nooit; dat gebeurt wanneer een thuis en een kantoor beide 192.168.1.0/24 kiezen.

Waarom een clientvlag geen routerinstelling is

Dit zijn verschillende rollen met verschillende eisen, en een clientvlag naar een router kopiëren is hoe een werkend tailnet een lus krijgt. Een machine die routes adverteert heeft doorsturen nodig, firewallregels die het doorgestuurde verkeer toestaan, en een beslissing over welke prefixen hij adverteert. Niets daarvan wordt door --accept-routes geïmpliceerd.

De documentatie over subnetrouters waarschuwt om routeacceptatie niet aan te zetten op redundante routers die één prefix adverteren, omdat een stand-byknooppunt verkeer dat al lokaal is via het actieve knooppunt naar buiten kan duwen. Draai je een HA-paar, behandel dat dan als een ontwerpbeperking en niet als een voetnoot, en beslis welk knooppunt het prefix bezit voordat je het op beide goedkeurt. Op één router leest dezelfde waarschuwing als een herinnering dat acceptatie bij de clients hoort, niet bij de machine die adverteert. Schrijf op welke poort gesloten was.

Voor een gewone client eindigt de reeks met de applicatietest die in het begin faalde. Voor de router, loop doorsturen, advertentie, goedkeuring en firewall in die volgorde na, want de eerste die ontbreekt levert precies de time-out waarmee je begon.