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 کے بعد بھی برقرار رکھیں

اگر IP forwarding فعال نہ ہو تو Linux مشین کسی بھی ایسے packet کو ضائع کر دیتی ہے جو براہ راست اس کے لیے نہ ہو۔ دوسری مشینوں کے packets کو آگے بھیجنا subnet router کا بنیادی کام ہے، لہذا یہ مرحلہ لازمی ہے۔

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 کے ذریعے کریں، جس کا نتیجہ net.ipv4.ip_forward = 1 ہونا چاہیے۔

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

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

روٹس کی تشہیر (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) کریں۔

ناکام ہونے کا طریقہ: دو راؤٹرز کا اوورلیپنگ رینجز کو ایڈورٹائز کرنا

دو سب نیٹ راؤٹرز کو ایک جیسی رینجز ایڈورٹائز نہیں کرنی چاہئیں۔ مختلف پریفکس لمبائیوں کے ساتھ اوورلیپنگ رینجز کی اجازت ہے، اور Tailscale سب سے زیادہ مخصوص میچ کا انتخاب کرتا ہے۔ اگر راؤٹر A، 10.0.0.0/24 کو ایڈورٹائز کر رہا ہو اور راؤٹر B، 10.0.0.0/16 کو، تو 10.0.0.20 کے لیے ٹریفک A کی طرف جائے گی۔

لوگوں کو جس چیز سے حیرت ہوتی ہے وہ A کے آف لائن ہونے پر رویہ ہے۔ Tailscale کم مخصوص روٹ پر واپس نہیں جاتا۔ 10.0.0.20 کے لیے ٹریفک رک جاتی ہے، جبکہ 10.1.0.20 کے لیے ٹریفک B کے ذریعے کام کرتی رہتی ہے۔ اس کی علامت ایسی ہے جیسے نجی نیٹ ورک کا نصف حصہ بند ہو، اور اس کی وجہ ایک آف لائن نوڈ کا زیادہ مخصوص پریفکس کو تھامے رکھنا ہے۔ اگر آپ فیل اوور (failover) چاہتے ہیں، تو وسیع تر راؤٹر سے بھی تنگ تر پریفکسز کو ایڈورٹائز کروائیں، تاکہ دونوں ایک ہی ایڈریسز کا احاطہ کریں۔

دوسرا اوورلیپ کلائنٹ کے زیادہ قریب ہوتا ہے۔ ہوٹل کے نیٹ ورک پر 192.168.1.0/24 پر بیٹھنا جبکہ آپ کا سب نیٹ راؤٹر 192.168.1.0/24 کو ایڈورٹائز کر رہا ہو، اس کا مطلب ہے کہ دونوں ایک ہی منزلوں کے لیے مقابلہ کرتے ہیں، اور کون جیتتا ہے اس کا انحصار پلیٹ فارم پر ہوتا ہے۔ Linux پر، Tailscale کے اپنے رول سے پہلے ایک رول انسٹال کریں تاکہ مقامی ایڈریسز مین ٹیبل کا استعمال کریں:

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

وہ رول مستقل نہیں ہوتا اور اگلے بوٹ پر ختم ہو جاتا ہے۔ اصل حل ایک ایسی نجی رینج کا انتخاب کرنا ہے جو آپ کو عام استعمال میں نہ ملے۔ 192.168.0.0/24 اور 192.168.1.0/24 زیادہ تر ہوم راؤٹرز پر ڈیفالٹ ہوتے ہیں، لہذا 10.0.0.0/8 کے اندر کچھ ایسا منتخب کریں جو آپ نے جان بوجھ کر چنا ہو۔ یہی تصادم ایک سادہ WireGuard VPN جسے آپ خود کنفیگر کرتے ہیں کو بھی توڑ دیتا ہے، اسی وجہ سے: زیادہ مخصوص مقامی روٹ جیت جاتا ہے، لہذا ٹریفک کبھی ٹنل میں داخل نہیں ہوتی۔

فیلیر موڈ: 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 کے ساتھ محفوظ کریں، ورنہ یہ اگلے بوٹ پر ختم ہو جائے گا۔

سسٹم کی دیکھ بھال جو اسے چلتا رکھتی ہے

اگست 2026 سے، Node keys بائی ڈیفالٹ 180 دنوں کے بعد expire ہو جاتی ہیں۔ جب subnet router پر key expire ہوتی ہے، تو node سائن آؤٹ ہو جاتا ہے اور پوری advertised range ناقابل رسائی ہو جاتی ہے، جس کی کوئی ظاہری وجہ configuration میں نظر نہیں آتی۔ ایڈمن کنسول کے Machines صفحہ پر اس مشین کے لیے key expiry کو disable کریں، اور پھر اسے نوٹ کر لیں۔

Tailscale peers کے درمیان براہ راست کنکشن کو ترجیح دیتا ہے اور جب یہ ممکن نہ ہو تو اپنے relay servers کا استعمال کرتا ہے۔ Relays کام تو کرتے ہیں، لیکن ان سے latency بڑھ جاتی ہے۔ ایک public address والا VPS آسان کیس ہے: inbound UDP 41641 کی اجازت دیں اور زیادہ تر peers براہ راست کنیکٹ ہو جائیں گے۔ اگر ufw فائر وال کو manage کر رہا ہے، تو وہ ufw رولز جن کی VPS کو اصل میں ضرورت ہوتی ہے میں اس کا syntax موجود ہے۔

Access rules دوسرا اہم حصہ ہیں۔ ڈیفالٹ tailnet پر آپ کا ہر آلہ دوسرے تک رسائی حاصل کر سکتا ہے، لہذا ایک منظور شدہ روٹ فوراً کام کرتا ہے۔ جب آپ ایک بار ACL پالیسی لکھ لیتے ہیں، تو رول کی destination سائیڈ پر private range کا نام دینا ضروری ہوتا ہے، کیونکہ 10.0.0.20 ایک tailnet ایڈریس نہیں ہے اور یہ ان رولز کے تحت نہیں آتا جو tailnet IPs یا tags کے لیے لکھے گئے ہوں۔

آخر میں، فیصلہ کریں کہ کیا آپ کوئی ایسا coordination server چاہتے ہیں جسے آپ خود نہ چلاتے ہوں۔ Tailscale کا control plane ایک hosted سروس ہے۔ آپ کی keys آپ کی مشینوں پر رہتی ہیں، لیکن اکاؤنٹ اور پالیسی فائل وہاں موجود ہوتی ہے۔ اگر control plane compromised ہو جائے یا identity login چوری ہو جائے تو کوئی کیا کر سکتا ہے، یہ وہ سوال ہے جس کا جواب آپ کو اپنے private network تک رسائی دینے سے پہلے طے کر لینا چاہیے، اور Tailscale کا trust ماڈل اس حد کی وضاحت کرتا ہے۔ قیمت شاذ و نادر ہی لوگوں کو اسے استعمال کرنے سے روکتی ہے، کیونکہ free پلان 6 صارفین تک کو ان کے اپنے لامحدود آلات کے ساتھ کور کرتا ہے، حالانکہ ایک subnet router جسے آپ tag کے تحت لاتے ہیں، اسے آپ کے ذاتی اکاؤنٹ سے سائن ان ہونے والے router سے مختلف گنا جاتا ہے۔ اس حد سے آگے، بل مشینوں کے بجائے لوگوں کی تعداد پر آتا ہے، لہذا free پلان ختم ہونے کے بعد ایک گھر یا 5 افراد کی ٹیم کو اصل میں کتنا ادا کرنا پڑتا ہے، اس کا حساب اس اکاؤنٹ کو شامل کرنے سے پہلے کر لینا چاہیے جو آپ کو اس حد سے آگے لے جائے۔ Headscale، جو کہ self-hosted Tailscale کنٹرول سرور ہے کو چلانے سے یہ آپ کے اپنے VPS پر رہتا ہے، جس کی قیمت اسے برقرار رکھنے کی محنت ہے۔ اسی تشویش کا دوسرا جواب Tailscale کے کلائنٹس کو چھوڑنا ہے، اور NetBird VPN سرور کو self-host کرنا coordination layer اور اس کے اپنے mesh کلائنٹس کو ایک ایسی مشین پر لے آتا ہے جسے آپ کنٹرول کرتے ہیں۔ اگر آپ ابھی بھی اس ماڈل اور دستی configuration کے درمیان فیصلہ کر رہے ہیں، تو WireGuard اور Tailscale کا موازنہ وضاحت کرتا ہے کہ coordination layer آپ کو کیا دیتا ہے اور اس کی قیمت کیا ہے۔

FAQ

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

Subnet router نجی IP ایڈریسز کی ایک رینج کو مشتہر (advertise) کرتا ہے، تاکہ tailnet ڈیوائسز ان مشینوں تک پہنچ سکیں جن پر Tailscale نہیں چل رہا۔ ایک exit node خود کو پورے انٹرنیٹ کے لیے ایک راستے کے طور پر مشتہر کرتا ہے، جس سے ڈیوائس اپنا تمام ٹریفک اس نوڈ کے پبلک ایڈریس کے ذریعے بھیجتی ہے۔ ایک VPS بیک وقت دونوں ہو سکتا ہے۔ یہ الگ الگ فلیگز ہیں، --advertise-routes اور --advertise-exit-node، اور ہر ایک کو ایڈمن کنسول میں الگ سے منظوری درکار ہوتی ہے۔

میرا Linux کلائنٹ مشتہر کردہ subnet route کو کیوں نظر انداز کر رہا ہے؟

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

ریبوٹ کے بعد میرا subnet کام کرنا کیوں بند کر گیا؟

زیادہ امکان IP forwarding کا ہے۔ sysctl -w کے ساتھ سیٹ کی گئی ویلیو ریبوٹ کے بعد برقرار نہیں رہتی، اس لیے اسے /etc/sysctl.d/99-tailscale.conf میں لکھیں اور sysctl net.ipv4.ip_forward کے ساتھ تصدیق کریں۔ اگر forwarding آن ہے اور رینج اب بھی ناقابل رسائی ہے، تو ایڈمن کنسول میں نوڈ کو دیکھیں۔ نوڈ کیز بائی ڈیفالٹ 180 دنوں کے بعد ختم ہو جاتی ہیں، اور ایک expired subnet router اکاؤنٹ کے مسئلے کے بجائے نیٹ ورک کی خرابی جیسا دکھائی دیتا ہے۔

کیا دو subnet routers ایک ہی رینج کو مشتہر کر سکتے ہیں؟

ایک جیسی رینجز نہیں۔ مختلف prefix lengths کے ساتھ اوورلیپنگ رینجز ٹھیک ہیں، اور سب سے زیادہ مخصوص (specific) رینج ترجیح پاتی ہے۔ Failover کے لیے احتیاط ضروری ہے: جب زیادہ مخصوص prefix والا راؤٹر آف لائن ہوتا ہے، تو Tailscale خود بخود وسیع تر روٹ پر منتقل نہیں ہوتا، اس لیے ٹریفک رک جاتی ہے۔ حقیقی standby جوڑے کے لیے، دونوں راؤٹرز سے ایک ہی مخصوص prefixes مشتہر کروائیں۔

ہوسٹ نیم resolve ہو جاتا ہے لیکن کنکشن ٹائم آؤٹ ہو جاتا ہے۔ کیوں؟

DNS ریزولیوشن اور روٹنگ الگ الگ مراحل ہیں۔ ایک نام ایسے ایڈریس پر resolve ہو سکتا ہے جسے کوئی منظور شدہ روٹ کور نہیں کرتا، اور پھر پیکٹ کلائنٹ کے ڈیفالٹ گیٹ وے کے ذریعے باہر نکل جاتا ہے۔ کلائنٹ پر ip route get <address> چلائیں۔ اگر جواب میں dev tailscale0 شامل نہیں ہے، تو ایک ایسی رینج مشتہر کریں جو اس ایڈریس کو کور کرتی ہو اور ایڈمن کنسول میں نئے prefix کی منظوری دیں۔