Jinsi ya kusanidi Tailscale subnet router kwenye VPS

Kazi ya Tailscale subnet router

Tailscale subnet router ni mashine moja inayotangaza safu nzima ya anwani za IP za ndani kwenye tailnet yako, ili kila kifaa kwenye tailnet kiweze kufikia anwani katika safu hiyo ingawa hakuna kifaa kingine kinachoendesha Tailscale huko. 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.

Sentensi moja kwa kila moja. Subnet router hufanya mtandao mmoja wa ndani uweze kufikika kutoka kwenye tailnet. Exit node hubadilisha mahali ambapo trafiki yako ya umma hutokea. Ikiwa hiyo ya pili ndiyo unayotaka, 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 (private network) ambao mtoa huduma wako ameshakupa. VPS yako ina anwani ya umma na interface ya pili kwenye sehemu ya ndani, na seva nyingine kwenye sehemu hiyo hazina anwani ya umma hata kidogo: database katika 10.0.0.20, na target ya backup katika 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 kwenye sehemu hiyo kinachobadilika, na database bado haina anwani ya umma.

Kisa kingine ni mtandao ulio upande mwingine wa VPS. LAN (local area network) ya nyumbani au ofisini iliyo nyuma ya router yake, au rack ya vifaa ambavyo haviwezi kuendesha Tailscale hata kidogo, kama vile managed switch au NAS ya zamani yenye firmware iliyofungwa. Sanduku moja la Linux kwenye mtandao huo huwa subnet router kwa kila kitu kingine kilichopo hapo.

Visa vyote viwili vinashiriki hitaji moja. Subnet router lazima iwe tayari ina uwezo wa kufikia masafa (range) inayotangaza, kwa kutumia routing table yake yenyewe na firewall yake yenyewe. Tailscale haijengi muunganisho huo. Inabeba trafiki hadi kwa router na kuikabidhi kwa kernel ili iisambaze (forward).

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 huwasha huduma hiyo. Thibitisha kwa kutumia systemctl is-active tailscaled, ambayo inapaswa kuchapisha active.

Kabla ya jambo lingine lolote, thibitisha kuwa VPS inaweza kufikia mtandao unaopanga 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 kwenye host lengwa. Rekebisha hilo kwanza, kwa sababu kila jaribio la baadaye hutegemea hatua hiyo.

Washa IP forwarding, na uifanye idumu 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 kwenye boot inayofuata, kwa hivyo subnet router huendelea kufanya kazi kwa wiki kadhaa kisha huacha kufanya kazi asubuhi inayofuata baada ya reboot ya kernel upgrade. Sehemu inayochanganya 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 route huku forwarding ikiwa 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 kuipita kwa haraka.

Tangaza njia (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 hufuta flags ambazo hukurudia, na CLI itakuzuia kwa kutoa kosa ikisema kuwa kubadilisha mipangilio kwa njia hii kunahitaji kutaja flags zote zisizo za kawaida (non-default). tailscale set hubadilisha mpangilio mmoja na kuacha mingine kama ilivyo.

Masafa (ranges) kadhaa 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, 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 bila idhini wakati ile ya zamani ikiendelea kufanya kazi. Njia iliyoidhinishwa na njia iliyopuuzwa huonekana sawa kutoka kwa VPS, kwa hivyo angalia dashibodi kabla ya kufanya utatuzi wa aina nyingine yoyote.

Unaweza kuruka hatua hii ya mikono kwa kutumia kizuizi cha autoApprovers katika faili ya sera ya tailnet:

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

Kisha anzisha node kwa kutumia tag hiyo, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, na njia hiyo itaidhinishwa papo hapo 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 hati (script), kwa sababu node iliyojengwa upya ni node mpya na njia zake huanza bila idhini tena.

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

Njia hiyo sasa imetangazwa 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 entries kwenye jedwali la routing 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 router ambayo jedwali lake la routing liliwekwa kwa makusudi na mtu, na kuingiza kimya kimya /24 iliyojifunza kutoka kwenye mtandao 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 ilipotua:

ip route show table 52
ip route get 10.0.0.20

Tailscale kwenye Linux haiweki njia zilizokubaliwa kwenye jedwali kuu la routing. Inaziweka kwenye jedwali la routing 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 node hii ya Linux yenyewe ni router ya pili ya subnet kwa mtandao wake wa ndani, --accept-routes huifanya itume trafiki kwa subnet yake iliyounganishwa moja kwa moja kupitia router nyingine badala ya kutoka kwenye interface yake yenyewe. Kwenye router ya kusubiri katika jozi ya upatikanaji wa juu (high availability), 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 inayoelekea 10.0.0.20 huenda kwa A.

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

Mwingiliano mwingine uko karibu zaidi na mteja. Kuwa kwenye mtandao wa hoteli ukiwa na 192.168.1.0/24 wakati ruta yako ya subnet inatangaza 192.168.1.0/24 inamaanisha kuwa zote mbili zinashindania maeneo yaleyale, na inayoshinda inategemea mfumo unaotumika. 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 reboot inayofuata. Suluhisho la kweli ni kuchagua masafa ya kibinafsi ambayo hutakutana nayo nje. 192.168.0.0/24 na 192.168.1.0/24 ndiyo chaguo-msingi kwenye ruta nyingi za nyumbani, kwa hivyo chagua kitu ndani ya 10.0.0.0/8 ulichokichagua kwa makusudi. Mgongano huohuo huvunja VPN ya kawaida ya WireGuard unayosanidi kwa mkono, kwa sababu ileile: njia ya ndani mahususi zaidi ndiyo inayoshinda, kwa hivyo trafiki haiingii kamwe kwenye tunnel.

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

Hii ni ngumu kuitatua, kwa sababu hakuna kinachotoa ujumbe wa hitilafu. Jina linatafsiriwa. Muunganisho unakwama (times out).

Tuseme db.internal.example.com inatafsiriwa kuwa 10.0.5.20 kupitia seva yako ya majina (nameserver) ya kibinafsi, na 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, kwa 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, jina ni sahihi na njia (route) haipo. Tangaza masafa (range) yanayofunika anwani hiyo, aidha 10.0.0.0/16 au prefix ya pili ya wazi, kisha idhinisha prefix mpya kwenye console.

Kuna mtego wa kulinganisha kwenye seva ya majina yenyewe. Ikiwa utaweka seva ya majina ya kimataifa (global nameserver) kwenye admin console katika anwani ya kibinafsi kama 10.0.0.53, anwani hiyo lazima iwe ndani ya njia iliyoidhinishwa, vinginevyo vifaa vyako havitaweza kufikia resolver hata kidogo. Washa chaguo linalobatilisha seva za DNS za ndani wakati unaelekeza kwenye resolver ambayo hakuna anayeweza kuifikia, na kila kifaa kwenye tailnet kitapoteza utafsiri wa majina mara moja, ikiwemo vile vilivyokuwa vikifanya kazi sekunde moja iliyopita. Tangaza na uidhinishe njia ya kuelekea resolver kwanza, kisha ubadilishe mipangilio ya DNS. Ikiwa DNS ndani ya tunnel ndiyo sehemu unayopambana nayo kila mara, jinsi DNS inavyoharibika kwenye WireGuard tunnel inaelezea utaratibu uleule bila safu ya uratibu juu yake.

Source NAT, na viungo vya site to site

Kwa chaguo-msingi, subnet router huandika upya anwani ya chanzo (source address) 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 kana kwamba unatoka kwenye VPS, kwa hivyo sheria za firewall kulingana na chanzo na logi za ufikiaji hazitoi taarifa zozote muhimu.

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

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

Vifaa kwenye mtandao wa kibinafsi vinahitaji njia ya kurudi kwenye 100.64.0.0/10, masafa ambayo Tailscale huipangia 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 routers 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. Masafa hayo mawili lazima yawe tofauti. Ikiwa uhamishaji mkubwa wa data hukwama wakati ssh na ping zikiwa 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 kuweka 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, la sivyo itapotea wakati wa boot inayofuata.

Utunzaji wa mfumo ili uendelee kufanya kazi

Node keys huisha muda wake baada ya siku 180 kwa chaguo-msingi, kuanzia Agosti 2026. Ufunguo kwenye subnet router unapoisha muda wake, node hujiondoa kwenye mtandao na masafa yote yaliyotangazwa hayafikiki, 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 kuwa umefanya hivyo.

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

Access rules ndiyo nusu nyingine ya kazi. 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 rule lazima utaje masafa ya kibinafsi (private range), kwa sababu 10.0.0.20 si anwani ya tailnet na haijafunikwa na rules zilizoandikwa dhidi ya IP za tailnet au tags.

Mwisho, amua kama unataka coordination server ambayo huiendeshi wewe mwenyewe. Control plane ya Tailscale ni huduma inayohifadhiwa (hosted service). Funguo zako hubaki kwenye mashine zako, lakini akaunti na faili ya policy hukaa huko. Kuendesha Headscale, the self hosted Tailscale control server kunaiweka hiyo kwenye VPS yako mwenyewe, kwa gharama ya kuifanyia matengenezo. Jibu lingine kwa wasiwasi huo ni kuacha wateja wa Tailscale pia, na self-hosting the NetBird VPN server huweka safu ya coordination na wateja wake wa mesh kwenye mashine moja unayoimiliki. Ikiwa bado unaamua kati ya mtindo huu na usanidi wa kuandika kwa mkono, ulinganisho wa WireGuard na Tailscale unaelezea kile ambacho safu ya coordination inakupa na gharama zake.

FAQ

Kuna tofauti gani kati ya subnet router na exit node?

Subnet router hutangaza masafa ya anwani za kibinafsi (private addresses), ili vifaa vilivyo kwenye tailnet viweze kufikia mashine ambazo hazitumii Tailscale. Exit node hujitangaza kama njia ya kufikia Internet nzima, hivyo kifaa hutuma trafiki yake yote kupitia anwani ya umma ya node hiyo. VPS moja inaweza kuwa vyote viwili. 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. Endesha sudo tailscale set --accept-routes kwenye mteja. Kisha hakiki 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 (policy rules), kwa hivyo meza kuu (main table) haiziorodheshi na route inayofanya kazi huonekana kama haipo.

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

IP forwarding, mara nyingi. 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 yale yale?

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

Hostname inatatuliwa lakini muunganisho unakata (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. Endesha ip route get <address> kwenye mteja. Ikiwa jibu halijumuishi dev tailscale0, tangaza masafa yanayofunika anwani hiyo na uidhinishe prefix mpya katika admin console.