Jinsi ya kusanidi Tailscale subnet router kwenye VPS

Kazi ya Tailscale subnet router

Tailscale subnet router ni mashine moja inayotangaza masafa yote ya anwani za IP za ndani kwenye tailnet yako, ili kila kifaa kwenye tailnet kiweze kufikia anwani katika masafa hayo ingawa hakuna kifaa chochote hapo kinachoendesha Tailscale. Tailnet yako ni mtandao wako binafsi wa Tailscale: seti ya vifaa vilivyoingia kwenye akaunti au shirika moja. Exit node ni kipengele ambacho watu hukichanganya na hicho, na hufanya kazi iliyo kinyume chake. Hupitisha trafiki yote ya kifaa kupitia VPS, hivyo VPS inakuwa njia ya kifaa hicho kuelekea kwenye mtandao wa umma wa Internet.

Kila sentensi ina wazo moja. Subnet router hufanya mtandao mmoja wa ndani uweze kufikika kutoka kwenye tailnet. Exit node hubadilisha mahali ambapo trafiki yako ya umma hutokea. Ikiwa unachotaka ni hicho cha pili, soma jinsi ya kuendesha Tailscale exit node kwenye VPS badala yake. Hizo ni flag tofauti, na VPS moja inaweza kufanya yote mawili kwa wakati mmoja, lakini hutatua matatizo tofauti na hushindwa kufanya kazi kwa njia tofauti.

Wakati VPS inapohitaji subnet router

Kisa cha kawaida ni mtandao wa ndani ambao mtoa huduma wako ameshakupa. VPS yako ina anwani ya umma na interface ya pili kwenye sehemu ya mtandao wa ndani, na seva nyingine kwenye sehemu hiyo hazina anwani ya umma hata kidogo: database kwenye 10.0.0.20, au target ya backup kwenye 10.0.0.30. Weka Tailscale kwenye VPS moja, tangaza 10.0.0.0/24, na laptop yako itafikia anwani hizo za ndani moja kwa moja. Hakuna kingine kinachobadilika kwenye sehemu hiyo, na database bado haina anwani ya umma. Ikiwa kitu pekee unachohitaji kutoka kwenye sehemu hiyo ni programu moja ya wavuti kwenye port moja, kutangaza range nzima ni kazi kubwa kuliko inavyohitajika, na Tailscale serve huweka HTTPS kwenye port hiyo moja badala yake. Hoja hiyo hiyo inahusu daemon inayofungwa kimakusudi kwenye localhost pekee, kama vile dsh inayoendeshwa bila kichwa chini ya systemd, ambapo anwani ya tailnet kwenye VPS hiyo inachukua nafasi ya SSH tunnel ambayo ungeiweka wazi ili kufikia UI yake.

Kisa kingine ni mtandao ulio upande mwingine wa VPS. LAN (local area network) ya nyumbani au ofisini iliyo nyuma ya router yake yenyewe, au rundo la vifaa ambavyo haviwezi kuendesha Tailscale hata kidogo, kama vile managed switch au NAS ya zamani yenye firmware iliyofungwa. Kompyuta moja ya Linux kwenye mtandao huo inakuwa subnet router kwa kila kitu kingine kilichopo. Nyumbani, kompyuta hiyo mara nyingi ni VM ndogo kwenye hypervisor unayoiendesha tayari, na hesabu ya gharama ya Proxmox host nyumbani dhidi ya VPS iliyokodishwa ndilo jambo la kuzingatia kabla ya kuamua ni upande upi wa tunnel huduma zako zinapaswa kuwepo.

Visa vyote viwili vinashiriki hitaji moja. Subnet router lazima iweze kufikia range inayotangaza, kwa kutumia routing table yake yenyewe na firewall yake yenyewe. Tailscale haijengi muunganisho huo. Inabeba trafiki hadi kwenye router na kuikabidhi kwa kernel ili iisambaze.

Sakinisha Tailscale na uhakiki njia ya ndani kwanza

curl -fsSL https://tailscale.com/install.sh | sh

Hati hii hutambua mfumo wa uendeshaji, huongeza hazina ya vifurushi (package repository) ya Tailscale, husakinisha amri ya tailscale na daemon ya tailscaled, kisha huwezesha huduma hiyo. Ithibitishe kwa kutumia systemctl is-active tailscaled, ambayo inapaswa kutoa matokeo ya active.

Kabla ya jambo lingine lolote, thibitisha kuwa VPS inaweza kufikia mtandao unaokusudia kuutangaza.

ip route show
ping -c3 10.0.0.20

ip route show lazima ionyeshe masafa ya anwani za ndani (private range) kwenye interface halisi, kitu kama 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Ikiwa ping itafeli hapa, kwenye router yenyewe, hakuna flag ya Tailscale itakayoweza kurekebisha hilo. Tatizo ni usanidi wa mtandao wa VPS au firewall iliyopo kwenye host lengwa. Rekebisha hilo kwanza, kwa sababu kila jaribio litakalofuata linategemea hatua hiyo.

Washa IP forwarding, na uhakikishe inabaki baada ya reboot

Mashine ya Linux hupoteza pakiti yoyote ambayo haijaelekezwa kwake isipokuwa kama forwarding imewashwa. Kusambaza pakiti za mashine nyingine ndiyo kazi kuu ya subnet router, kwa hivyo hatua hii si ya hiari.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Ithibitishe kwa kutumia sysctl net.ipv4.ip_forward, ambayo inapaswa kuchapisha net.ipv4.ip_forward = 1.

Watu mara nyingi hufanya hatua hii kwa nusu. sudo sysctl -w net.ipv4.ip_forward=1 hufanya kazi mara moja lakini hupotea baada ya boot inayofuata, kwa hivyo subnet router hufanya kazi kwa wiki kadhaa kisha huacha kufanya kazi asubuhi inayofuata baada ya reboot ya kernel upgrade. Sehemu ya kutatanisha ni kwamba hakuna kinachoonekana kuharibika. tailscale status bado inaonyesha node iko online, admin console bado inaonyesha route imekubaliwa, na wateja bado wana route iliyowekwa. Pakiti hufika kwenye VPS na kernel huzipoteza bila kuingiza logi yoyote. Kuandika thamani hizo kwenye /etc/sysctl.d/99-tailscale.conf ndiko kunakozirejesha baada ya reboot.

Ukitangaza routes wakati forwarding bado imezimwa, tailscale up inakuonya wakati huo, kwa mstari ulio karibu na Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Soma matokeo ya amri hiyo badala ya kuipuuza.

Tangaza njia za mtandao (routes)

sudo tailscale up --advertise-routes=10.0.0.0/24

Kwenye VPS ambayo tayari imeingia kwenye tailnet yako, badilisha mpangilio uliopo badala yake:

sudo tailscale set --advertise-routes=10.0.0.0/24

Tumia tailscale set kwa kila mabadiliko ya baadaye. Kuendesha tena tailscale up kwa flag moja tu hufuta flag ambazo hukuzirudia, na CLI itakupa kosa ikisema kuwa kubadilisha mipangilio kwa njia hii kunahitaji kutaja flag zote zisizo za kawaida (non-default). tailscale set hubadilisha mpangilio mmoja na kuacha mingine kama ilivyo.

Masafa kadhaa ya mtandao huwekwa kwenye orodha moja iliyotenganishwa kwa koma bila nafasi: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Kila ingizo lazima liwe anwani ya mtandao katika mfumo wa CIDR (classless inter-domain routing, mfumo wa 10.0.0.0/24). Kuandika anwani yako ya host kimakosa, 10.0.0.5/24, hukataliwa kwa sababu biti zilizo baada ya prefix si sufuri, na ujumbe wa kosa hutaja prefix uliyokusudia. Ili kusitisha utangazaji, weka orodha tupu kwa sudo tailscale set --advertise-routes=.

Idhinisha njia katika dashibodi ya admin

Kutangaza njia (advertising a route) ni ombi tu, si mabadiliko ya moja kwa moja. Hadi admin atakapoidhinisha, hakuna mteja atakayepokea njia hiyo na hakuna kitu katika masafa hayo kitakachoweza kufikiwa. Hii imekusudiwa makusudi, kwa sababu mashine inayoweza kujiingiza kwenye jedwali la uelekezaji (routing table) la kila mtu inaweza kunasa trafiki ya masafa yoyote inayotaka.

Idhinisha njia hiyo kwenye ukurasa wa Machines wa dashibodi ya admin. VPS itaonekana ikiwa na beji ya subnet. Fungua mstari wake, tafuta sehemu ya subnets, hariri mipangilio ya njia, tia alama kwenye njia hiyo, kisha uhifadhi.

Idhini hutolewa kwa kila prefix. Ukitangaza 10.0.0.0/24 leo na 192.168.50.0/24 mwezi ujao, prefix mpya itawasili ikiwa haijaidhinishwa huku ile ya zamani ikiendelea kufanya kazi. Njia iliyoidhinishwa na njia iliyopuuzwa huonekana sawa kutoka kwa VPS, kwa hivyo kagua dashibodi kabla ya kufanya utatuzi wa kitu kingine chochote.

Unaweza kuruka hatua hii ya mwongozo kwa kutumia block ya autoApprovers katika faili ya sera ya tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Kisha anzisha node hiyo kwa kutumia tag hiyo, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, na njia hiyo itaidhinishwa mara tu inapotangazwa. Tag hiyo lazima iwepo kwanza katika sehemu ya tagOwners ya faili hiyo hiyo ya sera. Hii inafaa kusanidiwa ikiwa unajenga upya VPS kutoka kwenye script, kwa sababu node iliyojengwa upya ni node mpya na njia zake huanza zikiwa hazijaidhinishwa tena.

Kwa nini wateja wa Linux hupuuza njia bila --accept-routes

Njia hiyo sasa inatangazwa na kuidhinishwa. Simu yako na Mac yako zinaweza kufikia 10.0.0.20. Laptop yako ya Linux haiwezi, na hakuna chochote katika dashibodi ya admin kinachoashiria tatizo.

Kukubali njia ya subnet kunamaanisha kuandika maingizo kwenye jedwali la uelekezaji (routing table) la mteja. Kwenye Android, iOS, macOS, tvOS na Windows, mteja wa Tailscale hukufanyia hivyo. Kwenye Linux haifanyi hivyo, kwa sababu mashine ya Linux mara nyingi ni seva au kipanga njia (router) ambacho jedwali lake la uelekezaji liliwekwa kwa makusudi na mtu, na kuingiza /24 iliyojifunza kutoka kwenye mtandao kimyakimya kunaweza kuvuruga trafiki ambayo mashine hiyo tayari inashughulikia. Kwa hiyo kwenye Linux unachagua kujiunga, kwenye kila mteja:

sudo tailscale set --accept-routes

Kisha angalia mahali njia hiyo ilipotua:

ip route show table 52
ip route get 10.0.0.20

Tailscale kwenye Linux haiweki njia zilizokubaliwa kwenye jedwali kuu la uelekezaji. Inaziweka kwenye jedwali la uelekezaji 52 na kusakinisha sheria za sera, zinazoonekana kwa ip rule show katika safu ya kipaumbele 5210 hadi 5270, ambazo hutuma pakiti zisizolingana kwenye jedwali hilo. Kwa hivyo ip route show pekee haitaorodhesha 10.0.0.0/24 kamwe, na msomaji anayeangalia amri hiyo pekee atahitimisha kuwa --accept-routes haikufanya chochote. ip route show table 52 ndiyo amri inayoonyesha ukweli, na inapaswa kuorodhesha safu iliyotangazwa kwenye tailscale0.

Kuna ubaguzi mmoja unaofaa kujulikana. Ikiwa nodi hii ya Linux yenyewe ni kipanga njia cha pili cha subnet kwa mtandao wake wa ndani, --accept-routes huifanya itume trafiki kwa subnet yake iliyounganishwa moja kwa moja kupitia kipanga njia kingine badala ya kutoka kwenye kiolesura chake yenyewe. Kwenye kipanga njia cha akiba (standby router) katika jozi ya upatikanaji wa juu (high availability pair), acha --accept-routes ikiwa imezimwa na utangaze tu.

Hali ya hitilafu: ruta mbili zinazotangaza masafa yanayoingiliana

Ruta mbili za subnet hazipaswi kutangaza masafa yanayofanana. Masafa yanayoingiliana yenye urefu tofauti wa prefix yanaruhusiwa, na Tailscale huchagua mechi mahususi zaidi. Ruta A ikitangaza 10.0.0.0/24 na ruta B ikitangaza 10.0.0.0/16, trafiki ya 10.0.0.20 huenda kwa A.

Kinachowashangaza watu ni tabia inayotokea wakati A inapokuwa nje ya mtandao. Tailscale hairejei kwenye njia isiyo mahususi. Trafiki ya 10.0.0.20 husimama, wakati trafiki ya 10.1.0.20 inaendelea kufanya kazi kupitia B. Dalili hii huonekana kama nusu ya mtandao wa kibinafsi haufanyi kazi, na sababu ni nodi moja iliyo nje ya mtandao inayoshikilia prefix mahususi zaidi. Ikiwa unataka failover, fanya ruta pana pia itangaze prefix nyembamba, ili zote mbili zifunike anwani zilezile.

Uingiliano mwingine uko karibu na mteja. Kuwa kwenye mtandao wa hoteli katika 192.168.1.0/24 wakati ruta yako ya subnet inatangaza 192.168.1.0/24 inamaanisha kuwa zote mbili zinashindania maeneo sawa, na ile inayoshinda inategemea mfumo. Kwenye Linux, sakinisha sheria kabla ya ile ya Tailscale ili anwani za ndani zitumie jedwali kuu:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Sheria hiyo haidumu na hupotea wakati wa boot inayofuata. Suluhisho la kweli ni kuchagua masafa ya kibinafsi ambayo hutakutana nayo nje. 192.168.0.0/24 na 192.168.1.0/24 ndizo chaguo-msingi kwenye ruta nyingi za nyumbani, kwa hivyo chagua kitu ndani ya 10.0.0.0/8 ulichokichagua kwa makusudi. Mgongano huo huo huvunja VPN ya kawaida ya WireGuard unayosanidi kwa mkono, kwa sababu hiyo hiyo: njia ya ndani mahususi zaidi ndiyo inayoshinda, kwa hivyo trafiki haiingii kwenye tunnel.

Hali ya hitilafu: DNS inatafsiri anwani ambayo haina njia (route)

Hali hii ni ngumu kutatua, kwa sababu hakuna kinachotoa ujumbe wa hitilafu. Jina linatafsiriwa vizuri. Muunganisho unakwama (times out).

Tuseme db.internal.example.com inatafsiriwa kuwa 10.0.5.20 kupitia nameserver yako ya ndani, na wewe umetangaza 10.0.0.0/24. Utafutaji unafanikiwa, kwa sababu utafsiri wa DNS (domain name system) na uelekezaji wa IP (IP routing) ni hatua mbili tofauti na hakuna inayokagua nyingine. Kisha, pakiti inayoelekea 10.0.5.20 haipati njia inayolingana kwenye tailnet, hivyo inatoka kupitia default gateway ya mteja na kupotea.

Amri mbili hutenganisha sehemu hizi mbili:

nslookup db.internal.example.com
ip route get 10.0.5.20

Ikiwa utafutaji unarudisha anwani lakini ip route get haijibu kwa dev tailscale0, basi jina liko sawa na njia (route) ndiyo inayokosekana. Tangaza masafa (range) yanayohusu anwani hiyo, aidha 10.0.0.0/16 au prefix nyingine ya ziada, kisha idhinisha prefix hiyo mpya kwenye console.

Kuna mtego unaofanana kwenye nameserver yenyewe. Ukiweka nameserver ya kimataifa (global nameserver) kwenye admin console kwa anwani ya ndani kama 10.0.0.53, anwani hiyo lazima iwe ndani ya njia (route) iliyoidhinishwa, vinginevyo vifaa vyako haviwezi kufikia resolver hiyo hata kidogo. Ukiwasha chaguo linalobatilisha (override) DNS servers za ndani huku ukielekeza kwenye resolver ambayo hakuna anayeweza kuifikia, kila kifaa kwenye tailnet kitapoteza uwezo wa kutafsiri majina mara moja, ikiwemo vile vilivyokuwa vikifanya kazi sekunde moja iliyopita. Tangaza na idhinisha njia ya kuelekea resolver hiyo kwanza, kisha ubadilishe mpangilio wa DNS. Ikiwa DNS ndani ya tunnel ndiyo sehemu unayopambana nayo mara kwa mara, njia ambayo DNS inavyovunjika kwenye WireGuard tunnel inaelezea utaratibu uleule bila kutumia safu ya uratibu (coordination layer) iliyo juu yake.

Source NAT, na viungo vya site-to-site

Kwa chaguo-msingi, subnet router huandika upya anwani ya chanzo ya kila pakiti inayopitishwa na kuibadilisha kuwa anwani yake ya kibinafsi. Hiyo ndiyo SNAT (source network address translation), na ipo ili majibu yafanye kazi bila kubadilisha chochote kwenye mtandao wa kibinafsi: hifadhidata iliyo kwenye 10.0.0.20 hujibu VPS, ambayo tayari inajua jinsi ya kuifikia. Gharama yake ni kwamba hifadhidata huona kila muunganisho wa tailnet kama unatoka kwenye VPS, kwa hivyo sheria za firewall za kila chanzo na logi za ufikiaji hazikupi taarifa zozote.

Iizime kwenye Linux wakati unataka anwani halisi ya tailnet ya mteja ihifadhiwe:

sudo tailscale set --snat-subnet-routes=false

Wenyeji (hosts) kwenye mtandao wa kibinafsi kisha wanahitaji njia ya kurudi kwenye 100.64.0.0/10, masafa ambayo Tailscale huwapa vifaa, ikielekeza kwenye subnet router. Bila njia hiyo ya kurudi, majibu yao huenda kwenye default gateway na hayafiki kamwe, kwa hivyo miunganisho hukwama baada ya pakiti ya kwanza. Ongeza static route kwenye gateway ya mtandao wa kibinafsi, au acha SNAT ikiwa imewashwa.

Kiungo cha site-to-site ni subnet router mbili zinazofanya hivi kwa wakati mmoja, kila moja ikitangaza mtandao wake na kukubali wa mwenzake:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Tekeleza amri inayolingana kwenye router nyingine kwa kutumia masafa yake yenyewe. Masafa hayo mawili lazima yawe tofauti. Ikiwa uhamishaji mkubwa wa data unakwama wakati ssh na ping ziko sawa, sababu ni MSS (maximum segment size), kipande kikubwa zaidi cha data ambacho pakiti ya TCP hubeba. Overhead ya tunnel hufanya pakiti zilizopitishwa kuwa kubwa mno kwa kiungo fulani kilichopo katikati, na clamping hutatua tatizo hilo:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Hifadhi sheria hiyo kwa kutumia iptables-persistent, au itapotea wakati wa boot inayofuata.

Utunzaji wa mfumo ili uendelee kufanya kazi

Node keys huisha muda wake baada ya siku 180 kwa chaguomsingi, kuanzia Agosti 2026. Ufunguo kwenye subnet router unapoisha muda wake, node hujiondoa na masafa yote yaliyotangazwa huwa hayawezi kufikika, bila mabadiliko yoyote ya usanidi kuelezea hilo. Zima muda wa kuisha kwa ufunguo (key expiry) kwa mashine hii kwenye ukurasa wa Machines wa admin console, kisha andika kumbukumbu kwamba umefanya hivyo.

Tailscale hupendelea muunganisho wa moja kwa moja kati ya peers na hutumia relay servers zake wakati muunganisho wa moja kwa moja hauwezekani. Relay hufanya kazi, lakini huongeza latency. VPS yenye anwani ya umma ni rahisi: ruhusu UDP 41641 ya ndani na peers wengi wataunganishwa moja kwa moja. Ikiwa ufw inasimamia firewall, sheria za ufw ambazo VPS inahitaji hasa zinaelezea syntax hiyo.

Access rules ni sehemu nyingine muhimu. Kwenye tailnet ya kawaida, kila kifaa chako kinaweza kufikia kingine, kwa hivyo route iliyoidhinishwa hufanya kazi mara moja. Mara tu unapoandika ACL policy, upande wa marudio wa sheria lazima utaje masafa ya kibinafsi (private range), kwa sababu 10.0.0.20 si anwani ya tailnet na haijashughulikiwa na sheria zilizoandikwa dhidi ya IP au tags za tailnet.

Mwisho, amua kama unataka coordination server ambayo huiendeshi wewe mwenyewe. Control plane ya Tailscale ni huduma inayohifadhiwa na wao. Funguo zako hubaki kwenye mashine zako, lakini akaunti na faili ya sera huishi huko. Kile ambacho mtu anaweza kufanya kwa control plane iliyoathiriwa au login ya utambulisho iliyoibiwa ni jambo la kuzingatia kabla ya kuipa njia ya kuingia kwenye mtandao wako wa kibinafsi, na mfumo wa uaminifu wa Tailscale unaonyesha mahali mpaka huo ulipo. Gharama mara chache ndiyo huwafanya watu kuacha kuitumia, kwa kuwa mpango wa bure unashughulikia hadi watumiaji sita wenye vifaa visivyo na kikomo, ingawa subnet router unayoianzisha chini ya tag huhesabiwa tofauti na ile uliyoiingia kama wewe. Baada ya hapo, bili hufuata watu badala ya mashine, kwa hivyo kile ambacho kaya au timu ya watu watano hulipa mpango wa bure unapoisha ni vyema kukokotolewa kabla ya kuongeza akaunti inayokuvusha mpaka huo. Kuendesha Headscale, seva ya udhibiti ya Tailscale inayojiendesha huiweka hiyo kwenye VPS yako mwenyewe, kwa gharama ya kuitunza. Jibu lingine kwa wasiwasi huo ni kuacha wateja wa Tailscale pia, na kujiendeshea seva ya NetBird VPN huweka safu ya uratibu na wateja wake wa mesh kwenye mashine moja unayoimiliki. Ikiwa bado unaamua kati ya mtindo huu na usanidi wa mikono, ulinganisho wa WireGuard na Tailscale unaelezea kile ambacho safu ya uratibu inakupa na gharama zake.

FAQ

Kuna tofauti gani kati ya subnet router na exit node?

Subnet router hutangaza masafa ya anwani za kibinafsi, ili vifaa vya kwenye tailnet viweze kufikia mashine ambazo hazitumii Tailscale. Exit node hujitangaza kama njia ya kufikia mtandao mzima wa Internet, hivyo kifaa hutuma trafiki yake yote kupitia anwani ya umma ya node hiyo. VPS moja inaweza kuwa zote mbili. Hizi ni flag tofauti, --advertise-routes na --advertise-exit-node, na kila moja inahitaji idhini yake katika admin console.

Kwa nini mteja wangu wa Linux anapuuza subnet route niliyotangaza?

Wateja wa Linux hawakubali subnet routes isipokuwa ukiwaagiza kufanya hivyo. Tekeleza sudo tailscale set --accept-routes kwenye mteja. Kisha thibitisha kwa kutumia ip route show table 52, si ip route show. Tailscale huweka routes zilizokubaliwa kwenye routing table 52 na kuzifikia kupitia sheria za sera, kwa hivyo jedwali kuu haliziorodheshi na route inayofanya kazi huonekana kama haipo.

Subnet yangu iliacha kufanya kazi baada ya reboot. Nini kimeharibika?

IP forwarding, mara nyingi ndiyo sababu. Thamani iliyowekwa kwa sysctl -w haidumu baada ya reboot, kwa hivyo iandike kwenye /etc/sysctl.d/99-tailscale.conf na uthibitishe kwa sysctl net.ipv4.ip_forward. Ikiwa forwarding imewashwa na masafa bado hayafikiki, angalia node hiyo kwenye admin console. Node keys huisha muda wake baada ya siku 180 kwa chaguo-msingi, na subnet router iliyoisha muda wake huonekana kama hitilafu ya mtandao badala ya tatizo la akaunti.

Je, subnet routers mbili zinaweza kutangaza masafa sawa?

Sio masafa yanayofanana kabisa. Masafa yanayoingiliana yenye urefu tofauti wa prefix ni sawa, na ile iliyo mahususi zaidi ndiyo inayoshinda. Failover inahitaji uangalifu: router inayoshikilia prefix mahususi zaidi inapozimika, Tailscale hairejei kwenye route pana zaidi, kwa hivyo trafiki hiyo husimama. Kwa jozi ya standby ya kweli, fanya routers zote mbili zitangaze prefix zilezile mahususi.

Hostname inatatuliwa lakini muunganisho unakwama (times out). Kwa nini?

DNS resolution na routing ni hatua tofauti. Jina linaweza kutatuliwa kuwa anwani ambayo hakuna route iliyoidhinishwa inayofunika, na pakiti hiyo kisha huondoka kupitia default gateway ya mteja. Tekeleza ip route get <address> kwenye mteja. Ikiwa jibu halijumuishi dev tailscale0, tangaza masafa yanayofunika anwani hiyo na uidhinishe prefix mpya katika admin console.