Waarom die Linux-Tailscale-kliënt aangekondigde subnetroetes ignoreer

Jy is op 'n Linux-skootrekenaar, tailscale status lys die ander masjiene, en die NAS by 10.80.0.25 keer steeds met 'n tydsverloop terug. Die tailnet is gesond, die subnetroeteerder is aanlyn, en niks in die kliënt se uitset sê waarom die LAN agter hom onbereikbaar is nie. Die uiteensetting hieronder beweeg van daardie simptoom na buite: die vlag op hierdie kliënt, dan die aankondiging op die roeteerder, dan goedkeuring, dan beleid, en eers dan die bestemming self. Elke hek faal met dieselfde tydsverloop, so die volgorde maak meer saak as die opdragte.

Wat die Linux-kliënt weier om te installeer

Tailscale-kliënte op Linux aanvaar nie aangekondigde subnetroetes nie tensy jy hulle dit vra. Sonder daardie instelling sluit die kliënt by die tailnet aan en bereik eweknie-adresse, terwyl elke voorvoegsel wat die roeteerder aankondig ongebruik bly. Die verstek is doelbewus, en dit is waarom die simptoom soos 'n stukkende roeteerder eerder as 'n plaaslike besluit lyk.

Twee afsonderlike dinge word hier roetering genoem, en net een daarvan is joune. Die roeteerder kondig 'n voorvoegsel in die tailnet aan; jou masjien besluit of dit dit installeer. 'n Fout in enigeen lewer dieselfde tydsverloop, en daarom mors raaiwerk 'n middag. Vind uit watter kant weier voordat jy enigiets wysig.

Skakel roete-aanvaarding vir hierdie masjien aan

Stel die voorkeur op die kliënt, en kyk dan wat verander het in plaas daarvan om aan te neem die opdrag het gewerk. Die huidige vorm pas die instelling toe sonder om die aanmeldvloei te herhaal, wat saak maak wanneer jy midde-in 'n sessie is.

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

Tailscale installeer aanvaarde roetes in sy eie tabel op Linux, so 'n voorvoegsel wat in tabel 52 verskyn, is direkte bewys dat hierdie kliënt die aankondiging geïnstalleer het. As jou reeks nie in daardie tabel is nie, stop: die probleem is plaaslik en geen hoeveelheid werk op die roeteerder sal dit verander nie.

Ouer kliënte bied dieselfde voorkeur as 'n vlag op die aanmeldopdrag, so sudo tailscale up --accept-routes is die terugval wanneer tailscale set ontbreek. Gebruik dit eerder as om roetes met die hand te wysig, want die daemon herskryf sy eie tabel en jou wysiging verdwyn by die volgende herverbinding. Kontroleer die weergawe voordat jy 'n opdrag uit 'n ouer pos kopieer.

Kontroleer die aankondiging en die goedkeuring afsonderlik

Op die subnetroeteerder moet die voorvoegsel aangekondig word, en die kern moet pakkette tussen koppelvlakke aanstuur. Aankondiging sonder aansturing gee jou 'n goedgekeurde roete wat verkeer stilweg laat val, wat die mees algemene halfvoltooide opstelling is.

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

Vergelyk die aangekondigde voorvoegsel met die adres wat jy werklik probeer bereik, karakter vir karakter. 'n Roeteerder wat 10.70.0.0/24 aankondig, sê niks oor 'n NAS by 10.80.0.25 nie, en die wanverhouding is onsigbaar in elke statusuitset omdat albei getalle ewe waarskynlik lyk. Die meeste verslae van 'n stukkende roete eindig hier. Maak die aankondiging reg voordat jy iets stroomaf aanraak.

Goedkeuring is die volgende hek, en dit is maklik om oor te slaan wanneer die roeteerder vanaf 'n dop geconfigureer is. Die aankondiging moet vir daardie toestel in die administrasiekonsole geaktiveer word voordat ander masjiene dit mag gebruik. Om roetes op die kliënt te aanvaar, keur niks goed nie en oorheers geen toegangsreël nie.

Toets die private adres voor die gasheernaam

'n Suksesvolle verbinding na die roeteerder se eie tailnet-adres bewys die tailnet werk, wat jy reeds geweet het. Die nuttige toets is die diens wat jy werklik nodig het, teen die private adres eerste, sodat 'n DNS-fout nie as 'n roeteringsfout kan voordoen nie.

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

As die adres antwoord en die gasheernaam nie, het jy 'n naamresolusieprobleem en moet jy ophou om dit as 'n roeteprobleem te behandel. As nie een antwoord nie, gaan 'n afdeling terug en bevestig die aankondiging dek die adres. Die twee foute lyk identies vanuit die toepassing en word op verskillende plekke reggemaak.

Een plaaslike kontrole is die moeite werd voordat jy die tailnet blameer. Wanneer jou huidige LAN dieselfde voorvoegsel as die afgeleë subnet gebruik, verkies die kern die direk gekoppelde roete en die verkeer verlaat nooit die masjien nie, wat gebeur wanneer 'n huis en 'n kantoor albei 192.168.1.0/24 gekies het.

Waarom 'n kliëntvlag nie 'n routerinstelling is nie

Dit is verskillende rolle met verskillende vereistes, en om 'n kliëntvlag op 'n roeteerder te kopieer, is hoe 'n werkende tailnet 'n lus kry. 'n Masjien wat roetes aankondig, het aansturing nodig, firewallreëls wat die aangestuurde verkeer toelaat, en 'n besluit oor watter voorvoegsels dit aankondig. Niks daarvan word deur --accept-routes geïmpliseer nie.

Die dokumentasie oor subnetroeteerders waarsku teen die aktivering van roete-aanvaarding op oortollige roeteerders wat een voorvoegsel aankondig, aangesien 'n bystandknooppunt verkeer wat reeds plaaslik is deur die aktiewe een kan uitstoot. As jy 'n HA-paar bedryf, behandel dit as 'n ontwerpbeperking eerder as 'n voetnoot, en besluit watter knooppunt die voorvoegsel besit voordat jy dit op albei goedkeur. Op 'n enkele roeteerder lees dieselfde waarskuwing as 'n herinnering dat aanvaarding by kliënte hoort, nie by die masjien wat die aankondiging doen nie. Skryf neer watter hek gesluit is.

Vir 'n gewone kliënt eindig die reeks met die toepassingstoets wat aan die begin misluk het. Vir die roeteerder, hersien aansturing, aankondiging, goedkeuring en firewall in daardie volgorde, want die eerste een wat ontbreek, lewer presies die tydsverloop waarmee jy begin het.