Kial la Linux-Tailscale-kliento ignoras anoncitajn subretajn itinerojn

Vi estas sur Linux tekkomputilo, tailscale status listigas la aliajn maŝinojn, kaj la NAS ĉe 10.80.0.25 ankoraŭ finiĝas per tempolimo. La tailnet estas sana, la subreta enkursigilo estas enlinea, kaj nenio en la eligo de la kliento diras kial la LAN malantaŭ ĝi estas neatingebla. La priskribo sube moviĝas de tiu simptomo eksteren: la flago sur ĉi tiu kliento, poste la anonco sur la enkursigilo, poste aprobo, poste politiko, kaj nur poste la celo mem. Ĉiu pordego malsukcesas per la sama tempolimo, do la ordo gravas pli ol la komandoj.

Kion la Linux-kliento rifuzas instali

Tailscale-klientoj en Linux ne akceptas anoncitajn subretajn itinerojn krom se vi petas tion. Sen tiu agordo la kliento aliĝas al la tailnet kaj atingas adresojn de samtavolanoj, dum ĉiu prefikso kiun la enkursigilo anoncas restas neuzata. La defaŭlto estas intenca, kaj tial la simptomo aspektas kiel rompita enkursigilo anstataŭ loka decido.

Du malsamaj aferoj nomiĝas enkursigado ĉi tie, kaj nur unu el ili estas via. La enkursigilo anoncas prefikson en la tailnet; via maŝino decidas ĉu instali ĝin. Malsukceso en iu ajn el ili produktas la saman tempolimon, do divenado malŝparas posttagmezon. Trovu kiu flanko rifuzas antaŭ ol vi redaktos ion.

Ŝaltu itineran akcepton por ĉi tiu maŝino

Agordu la preferon sur la kliento, poste rigardu kio ŝanĝiĝis anstataŭ supozi ke la komando efikis. La nuna formo aplikas la agordon sen ripeti la ensalutan fluon, kio gravas kiam vi estas meze de sesio.

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

Tailscale instalas akceptitajn itinerojn en sia propra tabelo en Linux, do prefikso aperanta en tabelo 52 estas rekta pruvo ke ĉi tiu kliento instalas la anoncon. Se via gamo mankas en tiu tabelo, haltu: la problemo estas loka kaj nenia laboro sur la enkursigilo ŝanĝos ĝin.

Pli malnovaj klientoj montras la saman preferon kiel flagon de la ensaluta komando, do sudo tailscale up --accept-routes estas la rezerva opcio kiam tailscale set mankas. Uzu ĝin anstataŭ permane redakti itinerojn, ĉar la demono reskribas sian propran tabelon kaj via redakto malaperas ĉe la sekva rekonekto. Kontrolu la version antaŭ ol kopii komandon el pli malnova afiŝo.

Kontrolu la anoncon kaj la aprobon aparte

Sur la subreta enkursigilo la prefikso devas esti anoncita, kaj la kerno devas plusendi pakaĵojn inter interfacoj. Anonco sen plusendo donas al vi aprobitan itineron kiu silente faligas trafikon, kaj tio estas la plej ofta duonfinita agordo.

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

Komparu la anoncitan prefikson kun la adreso kiun vi efektive provas atingi, signon post signo. Enkursigilo kiu anoncas 10.70.0.0/24 diras nenion pri NAS ĉe 10.80.0.25, kaj la miskongruo estas nevidebla en ĉiu stata eligo ĉar ambaŭ nombroj aspektas same kredindaj. Plej multaj raportoj pri rompita itinero finiĝas ĉi tie. Riparu la anoncon antaŭ ol tuŝi ion ajn pli malsupre.

Aprobo estas la sekva pordego, kaj facile preterlasita kiam la enkursigilo estis agordita el ŝelo. La anonco devas esti ŝaltita por tiu aparato en la administra konzolo antaŭ ol aliaj maŝinoj rajtas uzi ĝin. Akcepti itinerojn sur la kliento aprobas nenion kaj superregas neniun alirregulon.

Testu la privatan adreson antaŭ la gastiganto-nomo

Sukcesa konekto al la propra tailnet-adreso de la enkursigilo pruvas ke la tailnet funkcias, kion vi jam sciis. La utila testo estas la servo kiun vi efektive bezonas, unue kontraŭ la privata adreso, por ke DNS-malsukceso ne povu sin ŝajnigi kiel enkursigada malsukceso.

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

Se la adreso respondas kaj la gastiganto-nomo ne, vi havas nomregan problemon kaj devus ĉesi trakti ĝin kiel itineran problemon. Se nek unu respondas, reiru sekcion kaj konfirmu ke la anonco kovras la adreson. La du malsukcesoj aspektas identaj el la aplikaĵo kaj ripariĝas en malsamaj lokoj.

Unu loka kontrolo indas antaŭ ol vi kulpigos la tailnet. Kiam via nuna LAN uzas la saman prefikson kiel la fora subreto, la kerno preferas la rekte konektitan itineron kaj la trafiko neniam forlasas la maŝinon; tio okazas kiam hejmo kaj oficejo ambaŭ elektas 192.168.1.0/24.

Kial klienta flago ne estas enkursiga agordo

Tiuj estas malsamaj roloj kun malsamaj postuloj, kaj kopii klientan flagon sur enkursigilon estas kiel funkcianta tailnet akiras buklon. Maŝino kiu anoncas itinerojn bezonas plusendadon, fajroŝirmilajn regulojn kiuj permesas la plusendatan trafikon, kaj decidon pri kiuj prefiksoj ĝi anoncas. Nenio el tio estas implicata de --accept-routes.

La dokumentaro pri subretaj enkursigiloj avertas kontraŭ ŝalti itineran akcepton sur redundaj enkursigiloj kiuj anoncas unu prefikson, ĉar rezerva nodo povas puŝi jam lokan trafikon eksteren tra la aktiva. Se vi funkciigas HA-paron, traktu tion kiel dezajnlimigon anstataŭ piednoton, kaj decidu kiu nodo posedas la prefikson antaŭ ol aprobi ĝin sur ambaŭ. Sur unuopa enkursigilo la sama averto legiĝas kiel memorigo ke akcepto apartenas al klientoj, ne al la maŝino kiu anoncas. Notu kiun pordegon oni fermis.

Por ordinara kliento la sinsekvo finiĝas per la aplikaĵa testo kiu malsukcesis komence. Por la enkursigilo, revizuu plusendadon, anoncon, aprobon kaj fajroŝirmilon en tiu ordo, ĉar la unua mankanta produktas ĝuste la tempolimon per kiu vi komencis.