VPS پر Tailscale subnet router کیسے سیٹ اپ کریں

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

Tailscale subnet router ایک ایسی مشین ہے جو نجی IP ایڈریسز کی پوری رینج کو آپ کے tailnet میں مشتہر (advertise) کرتی ہے، تاکہ tailnet پر موجود ہر ڈیوائس ان ایڈریسز تک رسائی حاصل کر سکے حالانکہ وہاں کوئی بھی ڈیوائس Tailscale نہیں چلا رہی ہوتی۔ آپ کا tailnet آپ کا نجی Tailscale نیٹ ورک ہے: یعنی ان ڈیوائسز کا مجموعہ جو ایک اکاؤنٹ یا تنظیم میں سائن ان ہیں۔ Exit node وہ فیچر ہے جس کے ساتھ لوگ اسے اکثر الجھا دیتے ہیں، حالانکہ یہ اس کے برعکس کام کرتا ہے۔ یہ کسی ڈیوائس کی تمام ٹریفک کو VPS کے ذریعے باہر بھیجتا ہے، لہذا VPS اس ڈیوائس کے لیے عوامی انٹرنیٹ تک جانے کا راستہ بن جاتا ہے۔

ہر ایک جملہ الگ مقصد کے لیے ہے۔ ایک subnet router ایک نجی نیٹ ورک کو tailnet سے قابل رسائی بناتا ہے۔ ایک exit node اس جگہ کو تبدیل کرتا ہے جہاں سے آپ کی عوامی ٹریفک باہر نکلتی ہے۔ اگر آپ کو دوسرے فیچر کی ضرورت ہے، تو اس کے بجائے how to run a Tailscale exit node on a VPS پڑھیں۔ یہ الگ الگ flags ہیں، اور ایک VPS بیک وقت دونوں کام کر سکتا ہے، لیکن یہ مختلف مسائل کو حل کرتے ہیں اور ان کی ناکامی کی وجوہات بھی مختلف ہوتی ہیں۔

جب VPS کو subnet router کی ضرورت ہو

عام صورتحال وہ نجی نیٹ ورک ہے جو آپ کے فراہم کنندہ نے پہلے ہی آپ کو دیا ہوتا ہے۔ آپ کے VPS کے پاس ایک public address اور ایک نجی segment پر دوسرا interface ہوتا ہے، اور اس segment پر موجود دیگر سرورز کے پاس کوئی public address نہیں ہوتا: جیسے 10.0.0.20 پر موجود ڈیٹا بیس، یا 10.0.0.30 پر موجود بیک اپ ٹارگٹ۔ ایک VPS پر Tailscale انسٹال کریں، 10.0.0.0/24 کو advertise کریں، اور آپ کا لیپ ٹاپ براہ راست ان نجی پتوں تک پہنچ جائے گا۔ اس segment پر کچھ اور تبدیل نہیں ہوتا، اور ڈیٹا بیس کے پاس اب بھی کوئی public address نہیں ہوتا۔ اگر آپ کو اس segment سے صرف ایک پورٹ پر ایک ویب ایپ درکار ہے، تو پوری رینج کو advertise کرنا ضرورت سے زیادہ ہے، اور Tailscale serve اس ایک پورٹ پر HTTPS لگا دیتا ہے۔ یہی منطق اس daemon پر بھی لاگو ہوتی ہے جو جان بوجھ کر صرف localhost پر bind ہوتا ہے، جیسے systemd کے تحت چلنے والا dsh، جہاں اس VPS کا tailnet ایڈریس اس SSH ٹنل کی جگہ لے لیتا ہے جسے آپ بصورت دیگر اس کے UI تک پہنچنے کے لیے کھلا رکھتے۔

دوسری صورتحال VPS کے دوسری طرف کا نیٹ ورک ہے۔ ایک گھر یا دفتر کا LAN (لوکل ایریا نیٹ ورک) جو اپنے راؤٹر کے پیچھے ہو، یا آلات کا ایک ریک جو Tailscale نہیں چلا سکتا، جیسے کہ managed switch یا پرانے فرم ویئر والا NAS۔ اس نیٹ ورک پر موجود ایک Linux باکس باقی سب کے لیے subnet router بن جاتا ہے۔ گھر پر وہ باکس اکثر ایک چھوٹا VM ہوتا ہے جو آپ پہلے سے چل رہے hypervisor پر ہوتا ہے، اور گھر پر Proxmox host کی لاگت کا موازنہ کرائے کے VPS سے وہ فیصلہ ہے جو آپ کو یہ طے کرنے سے پہلے کرنا چاہیے کہ آپ کی سروسز ٹنل کے کس سرے پر ہونی چاہئیں۔

دونوں صورتوں میں ایک ضرورت مشترک ہے۔ subnet router کو اپنی routing table اور اپنے firewall کا استعمال کرتے ہوئے اس رینج تک پہنچنے کے قابل ہونا چاہیے جسے وہ advertise کر رہا ہے۔ Tailscale وہ کنکشن نہیں بناتا۔ یہ ٹریفک کو راؤٹر تک پہنچاتا ہے اور اسے آگے بھیجنے (forward) کے لیے kernel کے حوالے کر دیتا ہے۔

Tailscale انسٹال کریں اور پہلے local route چیک کریں

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

یہ اسکرپٹ distribution کا پتہ لگاتی ہے، Tailscale کی package repository شامل کرتی ہے، tailscale کمانڈ اور tailscaled ڈیمن انسٹال کرتی ہے، اور پھر سروس کو فعال کرتی ہے۔ اس کی تصدیق systemctl is-active tailscaled سے کریں، جسے active پرنٹ کرنا چاہیے۔

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

ip route show
ping -c3 10.0.0.20

ip route show کو کسی حقیقی انٹرفیس پر پرائیویٹ رینج کی فہرست دکھانی چاہیے، جیسے کہ 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5۔ اگر یہاں ping ناکام ہو جائے، تو خود راؤٹر پر، کوئی بھی Tailscale فلیگ اسے ٹھیک نہیں کر سکے گا۔ مسئلہ VPS کی نیٹ ورک کنفیگریشن یا ٹارگٹ ہوسٹ پر موجود فائر وال کا ہے۔ اسے پہلے ٹھیک کریں، کیونکہ بعد کے تمام ٹیسٹ اسی پر منحصر ہیں۔

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 کے بعد دوبارہ بحال ہو جاتی ہیں۔

اگر forwarding بند ہونے کے باوجود routes advertise کریں تو tailscale up آپ کو اسی وقت warning دیتا ہے۔ Linux پر یہ line تقریباً Warning: IP forwarding is disabled, subnet routing/exit nodes will not work. جیسی ہوتی ہے۔ اس command کا output پڑھیں؛ اسے scroll کرتے ہوئے نظرانداز نہ کریں۔

روٹس کی تشہیر (Advertise) کریں

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

ایک ایسے VPS پر جو پہلے سے آپ کے tailnet میں سائن ان ہے، اس کے بجائے سیٹنگ کو براہ راست تبدیل کریں:

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

ہر بعد کی تبدیلی کے لیے tailscale set کا استعمال کریں۔ کسی ایک فلیگ کے ساتھ tailscale up کو دوبارہ چلانے سے وہ فلیگز ری سیٹ ہو جاتے ہیں جو آپ نے دہرائے نہیں، اور CLI آپ کو ایک ایرر کے ساتھ روک دیتا ہے کہ اس طریقے سے سیٹنگز تبدیل کرنے کے لیے تمام نان ڈیفالٹ فلیگز کا ذکر کرنا ضروری ہے۔ tailscale set ایک سیٹنگ کو تبدیل کرتا ہے اور باقی کو اپنی جگہ رہنے دیتا ہے۔

متعدد رینجز کو بغیر کسی اسپیس کے ایک کوما سے الگ شدہ فہرست میں درج کریں: --advertise-routes=10.0.0.0/24,192.168.50.0/24۔ ہر اندراج CIDR نوٹیشن (کلاس لیس انٹر ڈومین روٹنگ، 10.0.0.0/24 فارمیٹ) میں ایک نیٹ ورک ایڈریس ہونا چاہیے۔ غلطی سے اپنا ہوسٹ ایڈریس لکھنا، یعنی 10.0.0.5/24، مسترد کر دیا جاتا ہے کیونکہ پریفکس کے بعد کے بٹس صفر نہیں ہوتے، اور ایرر میں وہ پریفکس بتایا جاتا ہے جس کا آپ نے غالباً ارادہ کیا تھا۔ تشہیر روکنے کے لیے، sudo tailscale set --advertise-routes= کے ساتھ ایک خالی فہرست سیٹ کریں۔

ایڈمن کنسول میں روٹ (route) کی منظوری دیں

روٹ کی تشہیر (advertising) صرف ایک درخواست ہے، کوئی تبدیلی نہیں۔ جب تک کوئی ایڈمن اس کی منظوری نہیں دیتا، کوئی بھی کلائنٹ روٹ وصول نہیں کرتا اور اس رینج میں کچھ بھی قابل رسائی نہیں ہوتا۔ یہ جان بوجھ کر کیا گیا ہے، کیونکہ جو مشین خود کو ہر کسی کے راؤٹنگ ٹیبل میں شامل کر سکتی ہے، وہ کسی بھی رینج کے ٹریفک کو حاصل کر سکتی ہے۔

ایڈمن کنسول کے Machines صفحے پر اس کی منظوری دیں۔ VPS وہاں ایک subnet بیج کے ساتھ درج ہوگا۔ اس کی قطار کھولیں، subnets سیکشن تلاش کریں، روٹ کی ترتیبات میں ترمیم کریں، روٹ کو ٹک کریں اور محفوظ کریں۔

منظوری فی پریفکس (prefix) ہوتی ہے۔ اگر آپ آج 10.0.0.0/24 کی تشہیر کریں اور اگلے مہینے 192.168.50.0/24 کی، تو نیا پریفکس غیر منظور شدہ رہے گا جبکہ پرانا کام کرتا رہے گا۔ VPS کی جانب سے منظور شدہ روٹ اور نظر انداز کردہ روٹ ایک جیسے نظر آتے ہیں، لہذا کسی اور چیز کو ڈیبگ کرنے سے پہلے کنسول کو چیک کریں۔

آپ tailnet پالیسی فائل میں autoApprovers بلاک کے ذریعے دستی مرحلے کو چھوڑ سکتے ہیں:

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

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

Linux کلائنٹس --accept-routes کے بغیر روٹ کو نظر انداز کیوں کرتے ہیں

روٹ اب مشتہر (advertise) اور منظور شدہ ہے۔ آپ کا فون اور آپ کا Mac 10.0.0.20 تک رسائی حاصل کر سکتے ہیں۔ آپ کا Linux لیپ ٹاپ ایسا نہیں کر سکتا، اور ایڈمن کنسول میں کوئی مسئلہ نظر نہیں آتا۔

سب نیٹ روٹ کو قبول کرنے کا مطلب ہے کلائنٹ کے راؤٹنگ ٹیبل میں اندراجات لکھنا۔ Android، iOS، macOS، tvOS اور Windows پر، Tailscale کلائنٹ یہ کام آپ کے لیے کرتا ہے۔ Linux پر ایسا نہیں ہوتا، کیونکہ Linux مشین اکثر ایک سرور یا راؤٹر ہوتی ہے جس کا راؤٹنگ ٹیبل کسی نے جان بوجھ کر ترتیب دیا ہوتا ہے، اور نیٹ ورک سے سیکھے گئے /24 کو خاموشی سے شامل کرنے سے وہ ٹریفک متاثر ہو سکتی ہے جسے وہ مشین پہلے ہی سنبھال رہی ہے۔ اس لیے Linux پر آپ ہر کلائنٹ پر خود انتخاب کرتے ہیں:

sudo tailscale set --accept-routes

پھر چیک کریں کہ روٹ کہاں پہنچا:

ip route show table 52
ip route get 10.0.0.20

Linux پر Tailscale قبول شدہ روٹس کو مین راؤٹنگ ٹیبل میں نہیں ڈالتا۔ یہ انہیں راؤٹنگ ٹیبل 52 میں رکھتا ہے اور پالیسی رولز انسٹال کرتا ہے، جو ip rule show کے ساتھ 5210 سے 5270 کی ترجیحی رینج میں نظر آتے ہیں، جو غیر مماثل پیکٹس کو اس ٹیبل پر بھیجتے ہیں۔ لہذا ip route show اکیلے کبھی بھی 10.0.0.0/24 کو لسٹ نہیں کرے گا، اور جو قاری صرف اس کمانڈ کو چیک کرتا ہے وہ یہ نتیجہ اخذ کرے گا کہ --accept-routes نے کچھ نہیں کیا۔ ip route show table 52 وہ کمانڈ ہے جو حقیقت دکھاتی ہے، اور اسے tailscale0 پر مشتہر کردہ رینج کو لسٹ کرنا چاہیے۔

ایک استثنا جاننا ضروری ہے۔ اگر یہ Linux نوڈ خود اپنے مقامی نیٹ ورک کے لیے دوسرا سب نیٹ راؤٹر ہے، تو --accept-routes اسے اپنے براہ راست منسلک سب نیٹ کے لیے ٹریفک کو اپنے انٹرفیس کے بجائے دوسرے راؤٹر کے ذریعے بھیجنے پر مجبور کرتا ہے۔ ہائی اویلیبلٹی جوڑی میں اسٹینڈ بائی راؤٹر پر، --accept-routes کو آف رکھیں اور صرف مشتہر (advertise) کریں۔

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

دو subnet routers ایک جیسے ranges کا اعلان کر سکتے ہیں، اور high availability pair اسی طرح کام کرتا ہے: ہر router بالکل ایک جیسے prefixes کا اعلان کرتا ہے، اور clients ایک router سے دوسرے router پر fail over کر سکتے ہیں۔ مختلف prefix lengths والے متداخل 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 پر واپس نہیں جاتا، کیونکہ offline router اپنا advertisement واپس نہیں لے سکتا اور clients زیادہ specific prefix کو ترجیح دیتے رہتے ہیں۔ 10.0.0.20 تک traffic رک جاتا ہے، جبکہ 10.0.1.20 تک traffic، جسے صرف B کا /16 cover کرتا ہے، B کے ذریعے چلتا رہتا ہے۔ اس کی علامت یہ محسوس ہوتی ہے کہ private network کا ایک حصہ down ہے، جبکہ وجہ یہ ہوتی ہے کہ ایک offline node کے پاس زیادہ specific prefix موجود ہے۔ اگر آپ failover چاہتے ہیں تو wider router سے narrower prefixes کا اعلان بھی کروائیں، تاکہ دونوں ایک ہی 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 install کریں، تاکہ 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 ranges ہیں، اس لیے 10.0.0.0/8 کے اندر کوئی ایسا range منتخب کریں جسے آپ نے جان بوجھ کر مقرر کیا ہو۔ یہی collision plain WireGuard VPN جسے آپ خود configure کرتے ہیں کو بھی ناکام بناتا ہے، اسی وجہ سے: زیادہ specific local route جیت جاتا ہے، اس لیے traffic tunnel میں داخل ہی نہیں ہوتا۔

فیلیر موڈ: DNS کا ایسے ایڈریس پر ریزولو ہونا جس کے لیے کوئی روٹ موجود نہ ہو

اس مسئلے کو ڈیبگ کرنا مشکل ہے، کیونکہ کوئی بھی چیز ایرر رپورٹ نہیں کرتی۔ نام ریزولو ہو جاتا ہے، لیکن کنکشن ٹائم آؤٹ ہو جاتا ہے۔

فرض کریں کہ db.internal.example.com آپ کے پرائیویٹ نیم سرور کے ذریعے 10.0.5.20 پر ریزولو ہوتا ہے، اور آپ نے 10.0.0.0/24 کو ایڈورٹائز کیا ہے۔ لک اپ کامیاب ہو جاتا ہے، کیونکہ DNS (ڈومین نیم سسٹم) ریزولوشن اور IP روٹنگ الگ الگ مراحل ہیں اور ان میں سے کوئی بھی دوسرے کو چیک نہیں کرتا۔ پھر 10.0.5.20 کے لیے بھیجا گیا پیکٹ ٹیل نیٹ (tailnet) پر کوئی مماثل روٹ نہیں پاتا، لہذا یہ کلائنٹ کے ڈیفالٹ گیٹ وے سے باہر نکل جاتا ہے اور غائب ہو جاتا ہے۔

دو کمانڈز ان دونوں حصوں کو الگ کرتی ہیں:

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

اگر لک اپ ایک ایڈریس واپس کرتا ہے لیکن ip route get جواب میں dev tailscale0 نہیں دیتا، تو نام ٹھیک ہے اور روٹ غائب ہے۔ ایک ایسی رینج ایڈورٹائز کریں جو اس ایڈریس کا احاطہ کرتی ہو، یا تو 10.0.0.0/16 یا پھر کوئی دوسرا واضح پریفکس، اور پھر کنسول میں نئے پریفکس کو منظور (approve) کریں۔

نیم سرور پر خود ایک مماثل ٹریپ موجود ہے۔ اگر آپ ایڈمن کنسول میں گلوبل نیم سرور کو کسی پرائیویٹ ایڈریس جیسے 10.0.0.53 پر سیٹ کرتے ہیں، تو وہ ایڈریس کسی منظور شدہ روٹ کے اندر ہونا چاہیے، ورنہ آپ کی ڈیوائسز ریزورور تک بالکل نہیں پہنچ سکیں گی۔ اگر آپ اس آپشن کو آن کر دیں جو لوکل DNS سرورز کو اوور رائیڈ کرتا ہے جبکہ پوائنٹ کسی ایسے ریزورور پر ہو جہاں کوئی نہیں پہنچ سکتا، تو ٹیل نیٹ میں موجود ہر ڈیوائس کی نیم ریزولوشن فوری طور پر ختم ہو جائے گی، بشمول ان کے جو ایک سیکنڈ پہلے کام کر رہی تھیں۔ پہلے ریزورور کے روٹ کو ایڈورٹائز اور منظور کریں، پھر DNS سیٹنگ تبدیل کریں۔ اگر ٹنل کے اندر DNS وہ حصہ ہے جس سے آپ مسلسل نبردآزما ہیں، تو جس طرح DNS ایک WireGuard ٹنل پر ٹوٹتا ہے اسی میکانزم کا احاطہ کرتا ہے، بغیر اوپر موجود کوآرڈینیشن لیئر کے۔

Source NAT اور سائٹ ٹو سائٹ لنکس

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

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

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

اس کے بعد پرائیویٹ نیٹ ورک پر موجود hosts کو 100.64.0.0/10 (وہ رینج جو Tailscale ڈیوائسز کو تفویض کرتا ہے) کی طرف واپسی کا راستہ (route) درکار ہوتا ہے، جو subnet router کی طرف اشارہ کرے۔ اس واپسی کے راستے کے بغیر ان کے جوابات ڈیفالٹ گیٹ وے پر چلے جاتے ہیں اور کبھی نہیں پہنچتے، جس کی وجہ سے پہلا پیکٹ موصول ہونے کے بعد کنکشن معطل ہو جاتے ہیں۔ پرائیویٹ نیٹ ورک کے گیٹ وے پر static route شامل کریں، یا SNAT کو آن رہنے دیں۔

سائٹ ٹو سائٹ لنک کا مطلب ہے کہ دو subnet routers بیک وقت یہ کام کر رہے ہوں، ہر ایک اپنے نیٹ ورک کو advertise کر رہا ہو اور دوسرے کے نیٹ ورک کو قبول کر رہا ہو:

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

دوسرے راؤٹر پر اس کی اپنی رینج کے ساتھ مماثل کمانڈ چلائیں۔ دونوں رینجز کا مختلف ہونا ضروری ہے۔ اگر بڑی فائلز کی منتقلی رک جائے جبکہ ssh اور ping ٹھیک کام کر رہے ہوں، تو اس کی وجہ MSS (maximum segment size) ہے، جو کہ TCP پیکٹ میں ڈیٹا کا سب سے بڑا حصہ ہوتا ہے۔ ٹنل کے اوور ہیڈ کی وجہ سے فارورڈ کیے گئے پیکٹس درمیان میں کسی لنک کے لیے بہت بڑے ہو جاتے ہیں، اور clamping اسے ٹھیک کر دیتی ہے:

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

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

اسے چلتا رکھنے کے لیے ضروری دیکھ بھال

October 2026 تک node keys کی میعاد پہلے سے طے شدہ طور پر 180 دن بعد ختم ہو جاتی ہے۔ جب subnet router پر موجود key کی میعاد ختم ہوتی ہے تو node sign out ہو جاتا ہے اور مشتہر کردہ پورا range ناقابل رسائی ہو جاتا ہے، جبکہ اس کی وضاحت کے لیے کہیں بھی configuration میں کوئی تبدیلی نہیں ہوتی۔ Admin console کے Machines صفحے پر اس machine کے لیے key expiry غیر فعال کریں، پھر درج کر لیں کہ آپ نے یہ کام کیا ہے۔ اوپر دی گئی autoApprovers مثال کے مطابق tag کے تحت شروع کیا گیا node پہلے سے key expiry کے ساتھ غیر فعال ہوتا ہے۔

Tailscale peers کے درمیان براہ راست connection کو ترجیح دیتا ہے اور جب یہ connection قائم نہ ہو سکے تو اپنے relay servers استعمال کرتا ہے۔ Relay servers کام کرتے ہیں، لیکن latency بڑھاتے ہیں۔ Public address والا VPS آسان صورت ہے: inbound UDP 41641 کی اجازت دیں، اور زیادہ تر peers براہ راست connect ہو جائیں گے۔ جب private range تک traffic VPS link کی متوقع رفتار سے کم ہو، تو یہ جانچنا کہ آپ کا client subnet router تک براہ راست پہنچ رہا ہے یا relay کے ذریعے سب سے پہلے کیا جانے والا جائزہ ہے۔ اگر firewall کا انتظام ufw کر رہا ہو تو VPS کو درکار حقیقی ufw rules میں syntax دی گئی ہے۔

Access rules دوسرا اہم حصہ ہیں۔ Default tailnet میں آپ کی ہر device دوسری تمام devices تک پہنچ سکتی ہے، اس لیے منظور شدہ 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 وہاں موجود ہوتے ہیں۔ Compromised control plane یا چوری شدہ identity login سے حقیقتاً کیا کیا جا سکتا ہے، یہی وہ معاملہ ہے جسے اپنے private network تک route دینے سے پہلے طے کرنا ضروری ہے، اور Tailscale کا trust model واضح کرتا ہے کہ یہ حد کہاں قائم ہوتی ہے۔ لاگت عموماً لوگوں کو اس سے دور نہیں کرتی، کیونکہ free plan میں زیادہ سے زیادہ چھ users اور ان کی اپنی unlimited devices شامل ہوتی ہیں، اگرچہ tag کے تحت شروع کیا گیا subnet router، آپ کے نام سے signed in subnet router سے مختلف طریقے سے شمار ہوتا ہے۔ اس حد سے آگے bill machines کے بجائے لوگوں کی تعداد کے مطابق بڑھتا ہے، اس لیے free plan ختم ہونے کے بعد household یا پانچ افراد کی team حقیقتاً کتنی ادائیگی کرتی ہے یہ جانچ لینا اس account کو شامل کرنے سے پہلے مفید ہے جو آپ کو مقررہ حد سے آگے لے جائے گا۔ Headscale، self-hosted Tailscale control server چلانے سے یہ control آپ کے اپنے VPS پر رہتا ہے، لیکن اسے maintain کرنا پڑتا ہے۔ اسی تشویش کا دوسرا حل یہ ہے کہ Tailscale کے clients بھی استعمال نہ کیے جائیں، اور 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 missing دکھائی دے سکتا ہے۔

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 problem کے بجائے network fault جیسا دکھائی دیتا ہے۔

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

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

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 کا اعلان کریں جو اس address کو cover کرے، اور admin console میں نیا prefix approve کریں۔