Hvers vegna samþykkt undirnetsleið Tailscale rennur samt út á tíma

Samþykki í stjórnborðinu lítur út eins og síðasta skrefið, og er það ekki. Fyrst rennur forritið út á tíma, og aðeins síðar finnur þú leiðarann á netinu og leiðina samþykkta. Samþykki er dreifingarskref, ekki leyfi og ekki ábyrgð á áframsendingu. Fjögur stig verða að falla saman áður en pakki nær hýsli bak við undirnetsleiðara, og hvert þeirra getur tekist á meðan það næsta mistekst. Farðu í gegnum þau í röð og stöðvaðu við fyrsta stigið sem stendur ekki.

Fjögur stig, ein mistök

Leiðarinn auglýsir forskeytið, tailnetið samþykkir þá auglýsingu, biðlarinn tekur við leiðinni sem hann fékk, og aðgangsstefnan leyfir tiltekna tenginguna. Þetta eru fjórar aðskildar ákvarðanir teknar af þremur mismunandi hlutum. Samþykkt leið segir því aðeins að netið sé nú hluti af leiðatöflu tailnetsins.

Fjórða stigið er það sem oftast er sleppt, því fyrstu þrjú gefa sýnilegt ástand. Heimild sem nær yfir eigið tailnet-heimilísi leiðarans nær ekki sjálfkrafa yfir einkarekstur undirnet bak við hann. Þetta eru mismunandi áfangastaðir, og stefnan er metin fyrir hvern áfangastað.

Á Linux hefur þriðja stigið líka sjálfgefið gildi sem kemur fólki á óvart: að taka við undirnetsleiðum er valfrjálst. Nokkrir biðlarar með grafísku viðmóti taka við auglýstum leiðum sjálfgefið, svo blandaður floti getur sýnt eina bilaða vél á meðan hinar virka.

Staðfestu stillinguna á biluðu vélinni í stað þess að gera ráð fyrir vettvangi. Leiðin var aldrei vantaði hlutinn á vélunum sem virka, svo leyfðu þeim að sanna að tailnet-hliðin sé heilbrigð. Skjöl Tailscale um undirnetsleiðara ná yfir samþykki, viðtöku leiða hjá biðlaranum og stefnustigið.

Athugaðu leiðina þar sem biðlarinn keyrir

Byrjaðu á biðlaranum sem bregst, ekki á leiðaranum. Staðfestu að leiðin sé til staðar og að stilling biðlarans leyfi yfirhöfuð að taka við leiðum.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Fyrsta skipunin sýnir jafningjalistann og hvort undirnetsleiðarinn er aðgengilegur, önnur prentar stillingar biðlarans þar á meðal fánann fyrir leiðarviðtöku, og þriðja spyr kjarnann hvaða tengi hann myndi nota fyrir raunverulegt hýsil á undirnetinu. Ef sú síðasta nefnir líkamlega tengið í stað Tailscale-tengisins kom leiðin aldrei í töfluna. Leið sem vantar er vandamál hjá biðlaranum, ekki samþykkisvandamál. Lagaðu það áður en þú lítur á stefnuna.

Til að taka við leiðum á Linux skaltu tengjast aftur með fánanum í stað þess að gera ráð fyrir að hann sé stilltur: tailscale up --accept-routes. Biðlari sem tengdist með öðrum fánum heldur þeim þar til þeim er breytt, svo athugaðu núverandi stillingu áður en þú bætir við annarri. Endurkeyrsla fyrstu skipunarinnar eftir breytinguna ætti að sýna leiðina í töflunni.

Sannaðu áframsendingu og afturleið

Samþykki stillir ekki leiðarann til að áframflytja pakka og útbýr ekki svarið. Bæði eru mál á hýsilstigi á LAN-hlið leiðarans. Prófaðu þau á leiðaranum, ekki á biðlaranum.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Fyrsta skipunin verður að tilkynna 1, annars hendir kjarninn áframflutta pakkanum. Önnur sýnir hvort grímun undirnetsleiðarinnar endurskrifi upprunann, sem er sjálfgefna hegðunin og venjulega það sem þú vilt. Þriðja sýnir hvort beiðnin nái áfangastað og hvort eitthvað komi til baka; beiðni án svars er vandamál afturleiðar, ekki samþykkis. Lestu niðurstöðurnar þrjár saman áður en þú breytir einhverri þeirra.

Ef grímumin hefur verið gerð óvirk þarf áfangastaðarnetið leið til baka að tailnet-heimilísunum, og hvert hopp á milli verður að vita það. Að kveikja aftur á grímunni er fljótlegasta lagfæringin fyrir eina þjónustu, en á kostnað þess að fela upprunalega biðlaraheimilísið frá áfangastaðnum. Sú skipti skipta máli þegar áfangastaðurinn skráir upprunaheimilísi fyrir endurskoðun, svo ákveddu það viljandi í stað þess að snúa fánanum í miðri atvikinu. Skjalfestu hvaða val þú tókst, því næsta manneskja sér aðeins aðra af tveimur hegðunum.

Lestu aðgangsregluna fyrir auðlindina

Þegar leiðin er til staðar og áframsending sönnuð er, er eftirstandandi grunsamlegi stefnan. Lestu heimildina sem á að leyfa tenginguna og athugaðu áfangastað hennar, ekki bara upprunann. Auðkenni biðlarans sjálfs verður líka að passa við veljanda stefnunnar, svo skráðu það frá sömu vél og bregst.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Stöðuúttakið greinir eigin heimilísi biðlarans og jafningjana sem hann sér, og það er það sem upprunaveljandi stefnunnar verður að passa við. tailscale ping sannar tailnet-slóðina að undirnetsleiðaranum sjálfum; það leysir jafningjanöfn og tailnet-heimilísi, ekki hýsla inni í auglýstu undirneti. Þriðja skipunin sendir venjulegt ICMP-endurómun um undirnetsleiðina, svo niðurstaðan lýsir áfangastaðnum frekar en leiðaranum. Synjun á tailnet-stigi kemur venjulega til baka sem synjun, á meðan pakki sem fer og kemur aldrei aftur rennur út á tíma.

Nafn sem bregst er önnur spurning en heimilísi sem bregst; leystu hýsilinn beint áður en þú kennir leiðinni um. Skrifaðu heimildina eftir raunverulegri þörf auðlindarinnar frekar en öllu undirnetinu. Að opna heilt /24 svo eitt forrit virki er leiðin sem þröng beiðni verður að breiðri heimild sem enginn þorir að fjarlægja síðar.

Ef markmiðið var útgangur á internetið en ekki einkarekstur undirnet, þá er rétta hlutinn útgangshnútur, ekki undirnetsleiðari, og stefnan og leiðsögnin eru frábrugðin í samræmi við það. Athugaðu þá ákvörðun áður en þú víkkar heimild. Útgangshnútur breytir sjálfgefnu leiðinni; undirnetsleiðari auglýsir aðeins forskeyti.