VPS پر Tailscale subnet router کیسے چلائیں

Tailscale subnet router کیا کرتا ہے

Tailscale subnet router ایک ایسی مشین ہوتی ہے جو private IP addresses کی پوری range آپ کے tailnet کے لیے advertise کرتی ہے، اس لیے tailnet پر موجود ہر device اس range کے addresses تک پہنچ سکتی ہے، چاہے وہاں کوئی بھی device Tailscale نہ چلا رہی ہو۔

آپ کا tailnet آپ کا private Tailscale network ہے، یعنی ان devices کا مجموعہ جو ایک account یا organisation میں signed in ہوں۔

Exit node وہ feature ہے جسے لوگ subnet router سمجھ لیتے ہیں، لیکن یہ اس کے برعکس کام کرتا ہے۔

یہ کسی device کا تمام traffic VPS کے ذریعے باہر بھیجتا ہے، اس لیے VPS اس device کے لیے public internet تک جانے کا route بن جاتا ہے۔

ہر نکتہ ایک جملے میں۔

Subnet router ایک private network کو tailnet سے reachable بناتا ہے۔

Exit node یہ تبدیل کرتا ہے کہ آپ کا public traffic کس جگہ سے باہر نکلتا ہے۔

اگر آپ کو دوسرا طریقہ درکار ہے تو اس کے بجائے VPS پر Tailscale exit node چلانے کا طریقہ پڑھیں۔

یہ الگ flags ہیں، اور ایک VPS دونوں کام بیک وقت کر سکتا ہے، لیکن یہ مختلف مسائل حل کرتے ہیں اور مختلف طریقوں سے fail ہوتے ہیں۔

جب VPS کے لیے subnet router درکار ہو

عام صورت وہ private network ہے جو آپ کے provider نے پہلے ہی فراہم کیا ہو۔ آپ کے VPS کے پاس ایک public address اور private segment پر دوسرا interface ہوتا ہے، جبکہ اس segment کے دوسرے servers کے پاس کوئی public address نہیں ہوتا: database 10.0.0.20 پر اور backup target 10.0.0.30 پر۔ ایک VPS پر Tailscale انسٹال کریں، 10.0.0.0/24 advertise کریں، اور آپ کا laptop ان private addresses تک براہِ راست پہنچ جائے گا۔ Segment پر کسی اور چیز میں تبدیلی نہیں ہوگی، اور database کے پاس اب بھی کوئی public address نہیں ہوگا۔

دوسری صورت VPS کے دوسری طرف موجود network کی ہے۔ یہ اپنے router کے پیچھے موجود home یا office LAN (local area network) ہو سکتا ہے، یا ایسے appliances کا rack جن پر Tailscale بالکل نہیں چل سکتا، مثلاً managed switch یا locked firmware والا پرانا NAS۔ اس network پر موجود ایک Linux box اس کے باقی تمام devices کے لیے subnet router بن جاتا ہے۔

دونوں صورتوں میں ایک ہی شرط ہے۔ Subnet router کو اپنے routing table اور اپنے firewall کے ذریعے اس range تک پہلے ہی رسائی حاصل ہونی چاہیے جسے وہ advertise کرتا ہے۔ Tailscale یہ connection قائم نہیں کرتا۔ یہ traffic کو router تک پہنچاتا ہے اور پھر اسے forward کرنے کے لیے kernel کے حوالے کر دیتا ہے۔

پہلے Tailscale انسٹال کریں اور مقامی route کی تصدیق کریں

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

یہ script distribution کا پتا لگاتی ہے، Tailscale کا package repository شامل کرتی ہے، tailscale command اور tailscaled daemon انسٹال کرتی ہے، پھر service کو enable کرتی ہے۔ systemctl is-active tailscaled سے اس کی تصدیق کریں۔ اس سے active ظاہر ہونا چاہیے۔

کسی بھی دوسرے کام سے پہلے یہ ثابت کریں کہ VPS اس network تک پہنچ سکتا ہے جسے آپ advertise کرنے کا ارادہ رکھتے ہیں۔

ip route show
ping -c3 10.0.0.20

ip route show کو کسی حقیقی interface پر private range دکھانی چاہیے، مثلاً 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5۔ اگر یہاں، یعنی router تک، ping ناکام ہو جائے تو Tailscale کا کوئی flag اسے درست نہیں کر سکتا۔ مسئلہ VPS کی network configuration یا target host کے firewall میں ہے۔ پہلے اسے درست کریں، کیونکہ بعد کے تمام tests اسی پر منحصر ہیں۔

IP forwarding فعال کریں اور اسے reboot کے بعد بھی برقرار رکھیں

Linux machine ہر ایسے packet کو drop کر دیتی ہے جو خود اس کے لیے addressed نہ ہو، جب تک forwarding فعال نہ ہو۔ دیگر machines کے packets کو forward کرنا subnet router کا بنیادی کام ہے، اس لیے یہ step اختیاری نہیں ہے۔

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

اسے sysctl net.ipv4.ip_forward کے ذریعے check کریں۔ اس کا output net.ipv4.ip_forward = 1 ہونا چاہیے۔

لوگ اکثر یہ step جزوی طور پر درست کرتے ہیں۔ sudo sysctl -w net.ipv4.ip_forward=1 فوراً کام کرتا ہے، لیکن اگلے boot پر ختم ہو جاتا ہے۔ نتیجتاً subnet router کئی ہفتے چلتا ہے، پھر kernel upgrade کے بعد ہونے والے reboot کی اگلی صبح بند ہو جاتا ہے۔ الجھن کی بات یہ ہے کہ بظاہر کچھ خراب نہیں لگتا۔ tailscale status اب بھی node کو online دکھاتا ہے، admin console اب بھی route کو approved دکھاتا ہے، اور clients کے پاس اب بھی route installed ہوتا ہے۔ Packets VPS تک پہنچتے ہیں، لیکن kernel انہیں بغیر کسی log کے drop کر دیتا ہے۔ values کو /etc/sysctl.d/99-tailscale.conf میں لکھنے سے reboot کے بعد یہ values دوبارہ فعال رہتی ہیں۔

اگر forwarding ابھی بھی بند ہو اور آپ routes advertise کریں، تو tailscale up اسی وقت warning دیتا ہے۔ اس میں Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. سے ملتی جلتی line ہوتی ہے۔ اس command کا output پڑھیں، اسے scroll کر کے نظرانداز نہ کریں۔

روٹس کا اعلان کریں

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

ایسے VPS پر جو پہلے ہی آپ کے tailnet میں signed in ہے، اس کے بجائے setting کو وہیں تبدیل کریں:

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

بعد کی ہر تبدیلی کے لیے tailscale set استعمال کریں۔ صرف ایک flag کے ساتھ tailscale up دوبارہ چلانے سے وہ flags reset ہو جاتے ہیں جنہیں آپ نے دوبارہ شامل نہیں کیا۔ CLI ایک error کے ساتھ عمل روک دیتا ہے کہ settings کو اس طریقے سے تبدیل کرنے کے لیے تمام non-default flags کا ذکر ضروری ہے۔ tailscale set ایک setting تبدیل کرتا ہے اور باقی settings کو برقرار رکھتا ہے۔

متعدد ranges کو ایک ہی comma-separated list میں، spaces کے بغیر، لکھیں: --advertise-routes=10.0.0.0/24,192.168.50.0/24۔ ہر entry، CIDR notation (classless inter-domain routing، یعنی 10.0.0.0/24 form) میں network address ہونی چاہیے۔ غلطی سے اپنا host address لکھنے پر، 10.0.0.5/24، اسے reject کر دیا جاتا ہے، کیونکہ prefix کے بعد والے bits صفر نہیں ہوتے۔ Error میں وہ prefix بھی بتایا جاتا ہے جسے آپ کا غالباً مقصد تھا۔ اعلان روکنے کے لیے sudo tailscale set --advertise-routes= کے ساتھ empty list مقرر کریں۔

ایڈمن کنسول میں route منظور کریں

route کو advertise کرنا ایک درخواست ہے، تبدیلی نہیں۔ جب تک کوئی admin اسے منظور نہ کرے، کسی client کو route موصول نہیں ہوتا اور range میں موجود کوئی چیز قابلِ رسائی نہیں ہوتی۔ یہ جان بوجھ کر ایسا رکھا گیا ہے، کیونکہ جو machine سب کے routing table میں خود کو شامل کر سکتی ہو، وہ اپنی پسند کی کسی بھی range کے لیے traffic capture کر سکتی ہے۔

ایڈمن کنسول کے Machines صفحے پر اسے منظور کریں۔ VPS subnet badge کے ساتھ درج ہوتا ہے۔ اس کی row کھولیں، subnets section تلاش کریں، route settings میں ترمیم کریں، route کو tick کریں اور save کریں۔

منظوری ہر prefix کے لیے الگ ہوتی ہے۔ آج 10.0.0.0/24 اور اگلے ماہ 192.168.50.0/24 advertise کریں تو نیا prefix غیر منظور شدہ حالت میں شامل ہوگا، جبکہ پرانا prefix کام کرتا رہے گا۔ VPS کی طرف سے منظور شدہ route اور نظرانداز کیا گیا route ایک جیسے دکھائی دیتے ہیں، اس لیے کسی اور چیز کی debugging سے پہلے console چیک کریں۔

آپ tailnet policy file میں autoApprovers block شامل کرکے manual مرحلہ چھوڑ سکتے ہیں:

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

پھر node کو اس tag، sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router، کے ساتھ up کریں۔ route advertise ہوتے ہی منظور ہو جائے گا۔ اسی policy file کے tagOwners section میں یہ tag پہلے سے موجود ہونا چاہیے۔ اگر آپ script کے ذریعے VPS دوبارہ بناتے ہیں تو یہ ترتیب دینا مفید ہے، کیونکہ rebuilt node ایک نیا node ہوتا ہے اور اس کے routes دوبارہ غیر منظور شدہ حالت میں شروع ہوتے ہیں۔

لینکس clients، --accept-routes کے بغیر route کیوں نظرانداز کرتے ہیں

اب route advertise اور approve ہو چکا ہے۔ آپ کا phone اور Mac، 10.0.0.20 تک پہنچ سکتے ہیں۔ آپ کا Linux laptop نہیں پہنچ سکتا، اور admin console میں بھی کسی مسئلے کی نشاندہی نہیں ہوتی۔

Subnet route قبول کرنے کا مطلب client کی routing table میں entries لکھنا ہے۔ Android، iOS، macOS، tvOS اور Windows پر Tailscale client یہ کام خود کرتا ہے۔ Linux پر ایسا نہیں ہوتا، کیونکہ Linux machine اکثر server یا router ہوتی ہے جس کی routing table کسی مقصد کے تحت configure کی گئی ہوتی ہے۔ Network سے خاموشی سے سیکھا گیا /24 شامل کرنے سے وہ traffic متاثر ہو سکتا ہے جسے machine پہلے سے handle کر رہی ہو۔ اس لیے Linux پر ہر client میں خود opt in کریں:

sudo tailscale set --accept-routes

پھر دیکھیں کہ route کہاں شامل ہوا:

ip route show table 52
ip route get 10.0.0.20

Linux پر Tailscale قبول شدہ routes کو main routing table میں شامل نہیں کرتا۔ یہ انہیں routing table 52 میں شامل کرتا ہے اور policy rules نصب کرتا ہے۔ یہ rules priority range 5210 سے 5270 میں ip rule show کے ذریعے نظر آتے ہیں اور ایسے packets کو اس table کی طرف بھیجتے ہیں جن کے لیے کوئی matching route موجود نہیں ہوتا۔ اس لیے صرف ip route show چلانے سے 10.0.0.0/24 کبھی نظر نہیں آئے گا، اور جو قاری صرف یہی command check کرے گا وہ یہ نتیجہ نکالے گا کہ --accept-routes نے کچھ نہیں کیا۔ اصل صورت حال دکھانے والی command ip route show table 52 ہے، اور اس میں advertised range، tailscale0 پر، نظر آنی چاہیے۔

ایک exception جاننا مفید ہے۔ اگر یہ Linux node اپنی local network کے لیے خود ایک second subnet router بھی ہے تو --accept-routes اسے اپنے براہ راست connected subnet کے traffic کو اپنی interface سے باہر بھیجنے کے بجائے دوسرے router کے ذریعے بھیجنے پر مجبور کرتا ہے۔ High availability pair میں standby router پر --accept-routes کو off رکھیں اور صرف advertise کریں۔

ناکامی کی صورت: دو routers کا overlapping ranges کا اعلان کرنا

دو subnet routers کو ایک جیسے ranges کا اعلان نہیں کرنا چاہیے۔ مختلف prefix lengths والے overlapping ranges قابلِ قبول ہیں، اور Tailscale سب سے زیادہ specific match منتخب کرتا ہے۔ اگر router A 10.0.0.0/24 کا اعلان کر رہا ہو اور router B 10.0.0.0/16 کا، تو 10.0.0.20 کے لیے traffic A کے ذریعے جائے گا۔

A کے offline ہونے پر رویہ اکثر حیران کن ہوتا ہے۔ Tailscale کم specific route پر fallback نہیں کرتا۔ 10.0.0.20 کے لیے traffic رک جاتا ہے، جبکہ 10.1.0.20 کے لیے traffic B کے ذریعے چلتا رہتا ہے۔ یہ صورتِ حال ایسی دکھائی دیتی ہے جیسے private network کا نصف حصہ بند ہو، لیکن اصل وجہ یہ ہوتی ہے کہ ایک offline node کے پاس زیادہ specific prefix موجود ہے۔ اگر آپ failover چاہتے ہیں تو wider router سے narrower prefixes کا اعلان بھی کروائیں، تاکہ دونوں routers ایک ہی addresses کو cover کریں۔

دوسرا overlap client کے زیادہ قریب ہوتا ہے۔ اگر آپ 192.168.1.0/24 پر hotel network استعمال کر رہے ہوں اور آپ کا subnet router 192.168.1.0/24 کا اعلان کر رہا ہو، تو دونوں ایک ہی destinations کے لیے مقابلہ کرتے ہیں، اور کون سا route جیتے گا اس کا انحصار platform پر ہوتا ہے۔ Linux پر Tailscale کے اپنے rule سے پہلے ایک rule شامل کریں، تاکہ local addresses main table استعمال کریں:

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

یہ rule persistent نہیں ہوتا اور اگلے boot پر ختم ہو جاتا ہے۔ مستقل حل یہ ہے کہ ایسا private range منتخب کریں جس سے آپ عام networks میں نہ ٹکرائیں۔ 192.168.0.0/24 اور 192.168.1.0/24 زیادہ تر home routers پر default ہوتے ہیں، اس لیے 10.0.0.0/8 کے اندر کوئی ایسا range منتخب کریں جس کا انتخاب آپ نے جان بوجھ کر کیا ہو۔ اسی وجہ سے یہ collision ایک plain WireGuard VPN جسے آپ خود configure کرتے ہیں کو بھی متاثر کرتا ہے: زیادہ specific local route جیت جاتا ہے، اس لیے traffic tunnel میں داخل ہی نہیں ہوتا۔

خرابی کی صورت: DNS ایسے پتے پر resolve ہو جو کسی route کے دائرے میں نہ آتا ہو

اس مسئلے کی تشخیص مشکل ہوتی ہے، کیونکہ کوئی بھی چیز error رپورٹ نہیں کرتی۔ نام resolve ہو جاتا ہے، لیکن connection timeout ہو جاتا ہے۔

فرض کریں کہ آپ کے private nameserver کے ذریعے db.internal.example.com، 10.0.5.20 پر resolve ہوتا ہے، اور آپ نے 10.0.0.0/24 advertise کیا ہے۔ Lookup کامیاب ہو جاتا ہے، کیونکہ DNS (domain name system) resolution اور IP routing الگ مراحل ہیں، اور ان میں سے کوئی بھی دوسرے مرحلے کی جانچ نہیں کرتا۔ اس کے بعد 10.0.5.20 کو بھیجا گیا packet tailnet پر matching route نہ ملنے کی وجہ سے client کے default gateway سے باہر نکل جاتا ہے اور ضائع ہو جاتا ہے۔

دو commands ان دونوں مراحل کو الگ کر دیتی ہیں:

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

اگر lookup کوئی address واپس کرتا ہے، لیکن ip route get، dev tailscale0 کے ساتھ جواب نہیں دیتا، تو نام درست ہے اور route موجود نہیں ہے۔ ایسا range advertise کریں جس میں یہ address شامل ہو، یعنی 10.0.0.0/16 یا دوسرا explicit prefix، پھر console میں نیا prefix approve کریں۔

nameserver پر بھی اسی نوعیت کا ایک trap موجود ہے۔ اگر آپ admin console میں 10.0.0.53 جیسا private address استعمال کرتے ہوئے global nameserver مقرر کرتے ہیں، تو یہ address کسی approved route کے اندر ہونا چاہیے، ورنہ آپ کے devices resolver تک بالکل نہیں پہنچ سکتے۔ اگر آپ ایسے resolver کی طرف اشارہ کرتے ہوئے local DNS servers کو override کرنے والا option فعال کر دیں جس تک کوئی device نہیں پہنچ سکتا، تو tailnet کا ہر device بیک وقت name resolution سے محروم ہو جاتا ہے، حتیٰ کہ وہ devices بھی جو ایک لمحہ پہلے درست کام کر رہے تھے۔ پہلے resolver تک route advertise اور approve کریں، پھر DNS setting تبدیل کریں۔ اگر tunnel کے اندر DNS وہ مسئلہ ہے جس سے آپ بار بار نمٹ رہے ہیں، تو WireGuard tunnel کے ذریعے DNS کے خراب ہونے کا طریقہ اسی mechanism کی وضاحت کرتا ہے، مگر اوپر موجود coordination layer کے بغیر۔

Source NAT اور site-to-site links

ڈیفالٹ طور پر subnet router ہر forwarded packet کے source address کو اپنے private address سے تبدیل کر دیتا ہے۔ اسے SNAT (source network address translation) کہتے ہیں۔ اس کا مقصد یہ ہے کہ private network میں کوئی تبدیلی کیے بغیر replies کام کریں: 10.0.0.20 پر موجود database VPS کو جواب دیتا ہے، کیونکہ وہ پہلے ہی جانتا ہے کہ VPS تک کیسے پہنچنا ہے۔ اس کا نقصان یہ ہے کہ database کو ہر tailnet connection VPS سے آتا ہوا دکھائی دیتا ہے۔ اس لیے source کے لحاظ سے firewall rules اور access logs کوئی مفید معلومات نہیں دیتے۔

جب آپ client کا اصل tailnet address برقرار رکھنا چاہتے ہوں تو Linux پر اسے بند کریں:

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

اس کے بعد private network کے hosts کو 100.64.0.0/10 کے لیے واپسی کا route درکار ہوگا۔ یہ وہ range ہے جو Tailscale devices کو assign کرتا ہے۔ یہ route subnet router کی طرف ہونا چاہیے۔ واپسی کا route نہ ہو تو replies default gateway کو بھیجے جاتے ہیں اور منزل تک نہیں پہنچتے۔ نتیجتاً connections پہلے packet کے بعد رک جاتے ہیں۔ private network کے gateway پر static route شامل کریں، یا SNAT فعال رہنے دیں۔

site-to-site link میں دو subnet routers بیک وقت یہی کام کرتے ہیں۔ ہر router اپنا network advertise کرتا ہے اور دوسرے router کے network کو قبول کرتا ہے:

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

دوسرے router پر اس کی اپنی range کے ساتھ متعلقہ command چلائیں۔ دونوں ranges مختلف ہونی چاہییں۔ اگر بڑے transfers رک جاتے ہیں جبکہ ssh اور ping درست کام کر رہے ہیں تو وجہ MSS (maximum segment size) ہے۔ یہ TCP packet میں منتقل ہونے والے data کے سب سے بڑے حصے کا سائز ہوتا ہے۔ tunnel کا اضافی overhead forwarded packets کو درمیان میں موجود کسی link کے لیے بہت بڑا بنا دیتا ہے۔ MSS clamping اس مسئلے کو درست کرتی ہے:

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

اس rule کو iptables-persistent کے ساتھ محفوظ کریں، ورنہ اگلے boot پر یہ ختم ہو جائے گا۔

اسے فعال رکھنے کے لیے ضروری دیکھ بھال

August 2026 تک، Node keys کی میعاد default طور پر 180 دن بعد ختم ہو جاتی ہے۔ جب subnet router پر key کی میعاد ختم ہوتی ہے تو node sign out ہو جاتا ہے اور مشتہر کردہ پوری range ناقابل رسائی ہو جاتی ہے، جبکہ اس کی وضاحت کے لیے کہیں بھی configuration میں کوئی تبدیلی موجود نہیں ہوتی۔ Admin console کے Machines page پر اس machine کے لیے key expiry disable کریں، پھر اس تبدیلی کا ریکارڈ لکھ کر رکھیں۔

Tailscale peers کے درمیان direct connection کو ترجیح دیتا ہے، اور جب direct connection قائم نہ ہو سکے تو اپنے relay servers استعمال کرتا ہے۔ یہ relays کام کرتے ہیں، لیکن latency بڑھاتے ہیں۔ Public address والے VPS کی صورت آسان ہوتی ہے: inbound UDP 41641 کی اجازت دیں، جس کے بعد زیادہ تر peers direct connection قائم کر لیتے ہیں۔ اگر firewall کا انتظام ufw کر رہا ہو تو VPS کو درکار اصل ufw rules میں syntax دیا گیا ہے۔

Access rules دوسرا اہم حصہ ہیں۔ Default tailnet میں آپ کی ہر device دوسری ہر device تک پہنچ سکتی ہے، اس لیے approved route فوراً کام کرتا ہے۔ جب آپ ACL policy لکھتے ہیں تو rule کے destination حصے میں private range کا نام دینا ضروری ہوتا ہے، کیونکہ 10.0.0.20 tailnet address نہیں ہے اور tailnet IPs یا tags کے خلاف لکھی گئی rules میں شامل نہیں ہوتا۔

آخر میں فیصلہ کریں کہ کیا آپ ایسا coordination server استعمال کرنا چاہتے ہیں جسے آپ خود نہ چلائیں۔ Tailscale کا control plane hosted service ہے۔ آپ کی keys آپ کی machines پر رہتی ہیں، لیکن account اور policy file وہاں محفوظ رہتے ہیں۔ Headscale، self-hosted Tailscale control server چلانے سے یہ انتظام آپ کے اپنے VPS پر رہتا ہے، لیکن اسے maintain کرنا پڑتا ہے۔ اسی تشویش کا دوسرا حل یہ ہے کہ Tailscale کے clients کو بھی خود host کریں؛ NetBird VPN server کو self-host کرنا coordination layer اور اس کے اپنے mesh clients کو آپ کے زیر انتظام ایک machine پر رکھتا ہے۔ اگر آپ ابھی اس model اور ہاتھ سے لکھی گئی config کے درمیان فیصلہ کر رہے ہیں تو WireGuard اور Tailscale کا موازنہ واضح کرتا ہے کہ coordination layer کیا سہولت دیتی ہے اور اس کی لاگت کیا ہے۔

FAQ

subnet router اور exit node میں کیا فرق ہے؟

subnet router نجی addresses کی ایک range کا اعلان کرتا ہے، اس لیے tailnet devices ان machines تک پہنچ سکتے ہیں جن پر Tailscale نہیں چلتا۔ exit node خود کو پورے internet کے route کے طور پر ظاہر کرتا ہے، اس لیے device اپنا تمام traffic اس node کے public address کے ذریعے بھیجتا ہے۔ ایک VPS دونوں کردار ادا کر سکتا ہے۔ یہ الگ flags ہیں، --advertise-routes اور --advertise-exit-node، اور ہر ایک کے لیے admin console میں الگ approval درکار ہوتی ہے۔

میرا Linux client advertised subnet route کو نظرانداز کیوں کرتا ہے؟

Linux clients subnet routes قبول نہیں کرتے، جب تک آپ انہیں ایسا کرنے کے لیے نہ کہیں۔ client پر sudo tailscale set --accept-routes چلائیں۔ پھر ip route show کے بجائے ip route show table 52 سے جانچ کریں۔ Tailscale منظور شدہ routes کو routing table 52 میں نصب کرتا ہے اور policy rules کے ذریعے ان تک پہنچتا ہے، اس لیے main table میں یہ routes کبھی درج نہیں ہوتے اور کام کرنے والا route غائب دکھائی دیتا ہے۔

reboot کے بعد میرا subnet کام کرنا بند ہو گیا۔ کیا خراب ہوا؟

غالباً IP forwarding۔ sysctl -w سے set کی گئی value reboot کے بعد برقرار نہیں رہتی، اس لیے اسے /etc/sysctl.d/99-tailscale.conf میں لکھیں اور sysctl net.ipv4.ip_forward سے تصدیق کریں۔ اگر forwarding فعال ہے اور range اب بھی unreachable ہے تو admin console میں node دیکھیں۔ Node keys بطور default 180 دن بعد expire ہو جاتی ہیں، اور expired subnet router account کے مسئلے کے بجائے network fault جیسا دکھائی دیتا ہے۔

کیا دو subnet routers ایک ہی range کا اعلان کر سکتے ہیں؟

بالکل یکساں ranges کا اعلان نہیں کیا جا سکتا۔ مختلف prefix lengths والی overlapping ranges درست ہیں، اور زیادہ specific route کو ترجیح ملتی ہے۔ Failover کے لیے احتیاط ضروری ہے: جب زیادہ specific prefix رکھنے والا router offline ہو جائے تو Tailscale وسیع route پر واپس نہیں آتا، اس لیے وہ traffic رک جاتا ہے۔ حقیقی standby pair کے لیے دونوں routers سے وہی specific prefixes advertise کروائیں۔

hostname resolve ہو جاتا ہے، لیکن connection timeout ہو جاتا ہے۔ کیوں؟

DNS resolution اور routing الگ مراحل ہیں۔ کوئی name ایسے address پر resolve ہو سکتا ہے جسے کوئی approved route cover نہ کرتا ہو، اور packet پھر client کے default gateway سے باہر چلا جاتا ہے۔ client پر ip route get <address> چلائیں۔ اگر جواب میں dev tailscale0 شامل نہ ہو تو ایسی range advertise کریں جو اس address کو cover کرتی ہو، اور admin console میں نئے prefix کو approve کریں۔