لینکس پر Tailscale کلائنٹ اعلان شدہ سب نیٹ راستوں کو کیوں نظر انداز کرتا ہے

آپ لینکس لیپ ٹاپ پر ہیں، tailscale status دوسری مشینیں فہرست کرتا ہے، اور 10.80.0.25 پر موجود NAS اب بھی وقت ختم ہونے پر رکتا ہے۔ tailnet صحت مند ہے، سب نیٹ راؤٹر آن لائن ہے، اور کلائنٹ کی آؤٹ پٹ میں کچھ بھی نہیں بتاتا کہ اس کے پیچھے کا LAN کیوں ناقابل رسائی ہے۔ نیچے دی گئی رہنمائی اسی علامت سے باہر کی طرف بڑھتی ہے: اس کلائنٹ پر جھنڈا، پھر راؤٹر پر اعلان، پھر منظوری، پھر پالیسی، اور پھر ہی منزل خود۔ ہر دروازہ اسی وقت کی حد سے ناکام ہوتا ہے، اس لیے ترتیب احکامات سے زیادہ اہم ہے۔

لینکس کلائنٹ کس چیز کو انسٹال کرنے سے انکار کرتا ہے

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

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

اس مشین کے لیے راستوں کی منظوری چالو کریں

کلائنٹ پر ترجیح مقرر کریں، پھر یہ سمجھنے کے بجائے کہ حکم لاگو ہو گیا، دیکھیں کہ کیا بدلا۔ موجودہ شکل لاگ ان کے عمل کو دہرائے بغیر سیٹنگ لاگو کرتی ہے، جو سیشن کے بیچ میں ہونے پر اہم ہے۔

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale لینکس پر قبول شدہ راستے اپنے الگ جدول میں انسٹال کرتا ہے، اس لیے جدول 52 میں دکھنا براہ راست ثبوت ہے کہ اس کلائنٹ نے اعلان انسٹال کیا۔ اگر آپ کی رینج اس جدول میں نہیں ہے تو رکیں: مسئلہ مقامی ہے اور راؤٹر پر کتنا ہی کام کیا جائے وہ نہیں بدلے گا۔

پرانے کلائنٹس وہی ترجیح لاگ ان حکم کے جھنڈے کے طور پر پیش کرتے ہیں، اس لیے tailscale set نہ ہونے پر sudo tailscale up --accept-routes متبادل ہے۔ راستے ہاتھ سے تبدیل کرنے کے بجائے یہ استعمال کریں، کیونکہ ڈیمن اپنا جدول دوبارہ لکھتا ہے اور آپ کی تبدیلی اگلے دوبارہ رابطے پر غائب ہو جاتی ہے۔ پرانی پوسٹ سے حکم نقل کرنے سے پہلے ورژن جانچیں۔

اعلان اور منظوری الگ الگ جانچیں

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

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

اعلان شدہ سابقہ کا اس پتے سے حرف بحرف موازنہ کریں جہاں آپ واقعی پہنچنا چاہتے ہیں۔ 10.70.0.0/24 اعلان کرنے والا راؤٹر 10.80.0.25 پر موجود NAS کے بارے میں کچھ نہیں کہتا، اور یہ عدم مطابقت ہر حالت کی آؤٹ پٹ میں نظر نہیں آتی کیونکہ دونوں اعداد یکساں قابل اعتماد لگتے ہیں۔ خراب راستے کی زیادہ تر رپورٹیں یہیں ختم ہوتی ہیں۔ نیچے کچھ بھی چھونے سے پہلے اعلان درست کریں۔

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

ہوسٹ نام سے پہلے نجی پتہ آزمائیں

راؤٹر کے اپنے tailnet پتے سے کامیاب رابطہ ثابت کرتا ہے کہ tailnet کام کرتا ہے، جو آپ پہلے سے جانتے تھے۔ مفید آزمائش وہ سروس ہے جس کی آپ کو واقعی ضرورت ہے، پہلے نجی پتے پر، تاکہ DNS کی ناکامی روٹنگ کی ناکامی کا روپ نہ دھار سکے۔

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

اگر پتہ جواب دے اور ہوسٹ نام نہ دے تو آپ کو نام حل کرنے کا مسئلہ ہے اور اسے راستے کا مسئلہ سمجھنا چھوڑ دیں۔ اگر دونوں میں سے کوئی جواب نہ دے تو ایک حصہ پیچھے جائیں اور تصدیق کریں کہ اعلان پتے کو ڈھانپتا ہے۔ دونوں ناکامیاں ایپلیکیشن سے یکساں دکھتی ہیں اور الگ مقامات پر درست ہوتی ہیں۔

tailnet کو مورد الزام ٹھہرانے سے پہلے ایک مقامی جانچ کی قدر ہے۔ جب آپ کا موجودہ LAN دور دراز سب نیٹ جیسا ہی سابقہ استعمال کرتا ہے، کرنل براہ راست منسلک راستے کو ترجیح دیتا ہے اور ٹریفک کبھی مشین نہیں چھوڑتا؛ یہ تب ہوتا ہے جب گھر اور دفتر دونوں 192.168.1.0/24 منتخب کریں۔

کلائنٹ کا جھنڈا راؤٹر کی سیٹنگ کیوں نہیں

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

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

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