منظور شدہ Tailscale سب نیٹ روٹ پھر بھی وقت ختم کیوں ہوتا ہے

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

چار مراحل، ایک ناکامی

راؤٹر سابقہ اعلان کرتا ہے، tailnet اس اعلان کی منظوری دیتا ہے، کلائنٹ موصول شدہ روٹ قبول کرتا ہے، اور رسائی کی پالیسی مخصوص کنکشن کی اجازت دیتی ہے۔ یہ تین مختلف اجزاء کے چار الگ فیصلے ہیں۔ اس لیے منظور شدہ روٹ صرف یہ بتاتا ہے کہ نیٹ ورک اب tailnet کی روٹنگ جدول کا حصہ ہے۔

چوتھا مرحلہ سب سے زیادہ چھوڑا جاتا ہے، کیونکہ پہلے تین نظر آنے والی حالت پیدا کرتے ہیں۔ راؤٹر کے اپنے tailnet پتے کو ڈھانپنے والی اجازت اس کے پیچھے موجود نجی سب نیٹ کو خودکار طور پر نہیں ڈھانپتی۔ یہ الگ منزلیں ہیں، اور پالیسی ہر منزل کے لیے الگ جانچی جاتی ہے۔

Linux پر تیسرے مرحلے میں لوگوں کو حیران کرنے والا ڈیفالٹ بھی ہے: سب نیٹ روٹ قبول کرنا اختیاری ہے۔ کئی GUI کلائنٹ اعلان شدہ روٹ ڈیفالٹ طور پر قبول کرتے ہیں، اس لیے مخلوط بیڑے میں ایک مشین ناکام دکھ سکتی ہے جبکہ باقی کام کر رہی ہوں۔

پلیٹ فارم فرض کرنے کے بجائے ناکام مشین پر ترتیب کی تصدیق کریں۔ کام کرنے والی مشینوں پر روٹ کبھی گمشدہ حصہ نہیں تھا، اس لیے انہیں ثابت کرنے دیں کہ tailnet کا رخ صحت مند ہے۔ Tailscale کی سب نیٹ راؤٹر دستاویزات منظوری، کلائنٹ کی روٹ قبولیت اور پالیسی مرحلے کا احاطہ کرتی ہیں۔

روٹ وہیں دیکھیں جہاں کلائنٹ چلتا ہے

راؤٹر پر نہیں، ناکام کلائنٹ سے شروع کریں۔ تصدیق کریں کہ روٹ موجود ہے اور کلائنٹ کی ترتیب روٹ قبول کرنے کی اجازت دیتی ہے۔

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Linux پر روٹ قبول کرنے کے لیے، جھنڈا مقرر ہے یہ فرض کرنے کے بجائے اس کے ساتھ دوبارہ جڑیں: tailscale up --accept-routes۔ مختلف جھنڈوں کے ساتھ شامل ہونے والا کلائنٹ انہیں بدلنے تک رکھتا ہے، اس لیے دوسرا شامل کرنے سے پہلے موجودہ ترتیب دیکھیں۔ تبدیلی کے بعد پہلا کمانڈ دوبارہ چلانے پر روٹ جدول میں نظر آنا چاہیے۔

آگے بھیجنا اور واپسی کا راستہ ثابت کریں

منظوری راؤٹر کو پیکٹ آگے بھیجنے کے لیے ترتیب نہیں دیتی، اور جواب کا انتظام نہیں کرتی۔ دونوں راؤٹر کی LAN طرف ہوسٹ سطح کے معاملات ہیں۔ انہیں کلائنٹ پر نہیں، راؤٹر پر جانچیں۔

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

پہلے کمانڈ کو 1 بتانا چاہیے، ورنہ کرنل آگے بھیجا گیا پیکٹ گرا دے گا۔ دوسرا دکھاتا ہے کہ سب نیٹ روٹ ماسک کرنا ماخذ کو دوبارہ لکھ رہا ہے یا نہیں، جو ڈیفالٹ رویہ ہے اور عام طور پر وہی جو آپ چاہتے ہیں۔ تیسرا دکھاتا ہے کہ درخواست منزل تک پہنچتی ہے اور کچھ واپس آتا ہے یا نہیں؛ بغیر جواب کی درخواست واپسی راستے کا مسئلہ ہے، منظوری کا نہیں۔ ان میں سے کوئی بھی بدلنے سے پہلے تینوں نتائج ایک ساتھ پڑھیں۔

اگر ماسک کرنا بند کر دیا گیا ہو تو منزل نیٹ ورک کو tailnet کے پتوں کی طرف واپسی روٹ درکار ہے، اور درمیان کے ہر ہاپ کو یہ معلوم ہونا چاہیے۔ ایک سروس کے لیے ماسک کرنا دوبارہ چالو کرنا تیز ترین حل ہے، لیکن منزل سے اصل کلائنٹ پتہ چھپانے کی قیمت پر۔ یہ تبادلہ اس وقت اہم ہے جب منزل آڈٹ کے لیے ماخذ پتے لاگ کرتی ہے، اس لیے واقعے کے دوران جھنڈا پلٹنے کے بجائے سوچ سمجھ کر فیصلہ کریں۔ دستاویز کریں کہ آپ نے کون سا انتخاب کیا، کیونکہ اگلا شخص دو رویوں میں سے صرف ایک دیکھے گا۔

وسیلے کے لیے رسائی کا قاعدہ پڑھیں

روٹ موجود اور آگے بھیجنا ثابت ہونے پر باقی مشتبہ پالیسی ہے۔ وہ اجازت پڑھیں جو کنکشن کی اجازت دینی چاہیے اور صرف ماخذ نہیں، اس کی منزل بھی دیکھیں۔ کلائنٹ کی اپنی شناخت بھی پالیسی منتخب کنندہ سے میل کھانی چاہیے، اس لیے اسے اسی مشین سے لیں جو ناکام ہو رہی ہے۔

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

حالت کی آؤٹ پٹ کلائنٹ کے اپنے پتوں اور ان ہم منصبوں کی نشاندہی کرتی ہے جنہیں وہ دیکھ سکتا ہے، اور پالیسی کے ماخذ منتخب کنندہ کو انہی سے میل کھانا چاہیے۔ tailscale ping خود سب نیٹ راؤٹر تک tailnet کا راستہ ثابت کرتا ہے؛ یہ ہم منصب نام اور tailnet پتے حل کرتا ہے، اعلان شدہ سب نیٹ کے اندر کے ہوسٹ نہیں۔ تیسرا کمانڈ سب نیٹ روٹ کے ذریعے عام ICMP بازگشت بھیجتا ہے، اس لیے اس کا نتیجہ راؤٹر کے بجائے منزل بیان کرتا ہے۔ tailnet سطح کی تردید عام طور پر تردید کے طور پر واپس آتی ہے، جبکہ نکل کر کبھی نہ لوٹنے والا پیکٹ وقت ختم ہو جاتا ہے۔

ناکام نام ناکام پتے سے الگ سوال ہے؛ روٹ کو قصوروار ٹھہرانے سے پہلے ہوسٹ کو براہ راست حل کریں۔ اجازت پورے سب نیٹ کے بجائے وسیلے کی حقیقی ضرورت کے مطابق لکھیں۔ ایک ایپلیکیشن کے کام کرنے کے لیے پورا /24 کھولنا وہ طریقہ ہے جس سے تنگ درخواست ایسی وسیع اجازت بن جاتی ہے جسے بعد میں کوئی ہٹانے کی ہمت نہیں کرتا۔

اگر مقصد نجی سب نیٹ نہیں بلکہ انٹرنیٹ اخراج تھا، تو درست جزو ایگزٹ نوڈ ہے، سب نیٹ راؤٹر نہیں، اور پالیسی اور روٹنگ اسی کے مطابق مختلف ہوتی ہیں۔ اجازت وسیع کرنے سے پہلے وہ فیصلہ دیکھیں۔ ایگزٹ نوڈ ڈیفالٹ روٹ بدلتا ہے؛ سب نیٹ راؤٹر صرف سابقہ کا اعلان کرتا ہے۔