Access Server کے کلائنٹس LAN سے کیوں ناقابلِ رسائی ہیں

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

سروس جو ماخذ پتہ دیکھتی ہے، وہ پڑھیں

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

کچھ بدلنے سے پہلے دونوں سروں کا موازنہ کریں۔ سرور پر ٹنل انٹرفیس اور ان کے پتے فہرست کریں؛ کلائنٹ پر تصدیق کریں کہ وہ واقعی کون سا پتہ رکھتا ہے؛ اندرونی ہوسٹ پر فعال کنکشن دیکھیں۔

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

آخری کمانڈ وہی ہے جو خراب حالت میں ناکام ہوتی ہے: یہ یا تو ٹنل کے سابقے کو ناقابلِ رسائی بتاتی ہے یا، اس سے بھی بدتر، آپ کا ڈیفالٹ گیٹ وے واپس دیتی ہے، اور اسی طرح جوابات انٹرنیٹ پر پہنچ جاتے ہیں۔

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

جواب طے ہونے کی جگہ راستہ شامل کریں

راستہ اس گیٹ وے کا ہے جو اندرونی سروس پہلے ہی استعمال کرتی ہے، سروس کا نہیں، الا یہ کہ سروس خود اپنا ٹریفک روٹ کرے۔ اسے Access Server کے قابلِ رسائی نجی پتے کی طرف ہدایت کریں، جو کلائنٹ کے پاس موجود ٹنل پتے سے مختلف قدر ہے۔

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

کلاؤڈ نیٹ ورک میں وہی بیان روٹ ٹیبل کی اندراج بن جاتا ہے جس کا ہدف وہ انسٹانس یا نیٹ ورک انٹرفیس ہے جس پر سرور چلتا ہے، اور اس انٹرفیس پر ماخذ اور منزل کی جانچ بند ہوتی ہے۔ غور کریں کہ وہ اندراج کیا نہیں کرتا: راستہ رسائی دینے کا ذریعہ نہیں، اس لیے سیکیورٹی گروپس، نیٹ ورک ACL اور ہوسٹ فائر وال کو اب بھی ٹریفک کی اجازت دینی ہوگی۔

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

فارورڈنگ اور فلٹر راستے سے مطابقت رکھنے چاہئیں

روٹنگ راستے کا صرف آدھا حصہ ہے۔ سرور کو ٹنل اور نجی انٹرفیس کے درمیان فارورڈ کرنے کی اجازت ہونی چاہیے، جس کا لینکس پر مطلب net.ipv4.ip_forward اور انٹرفیس کے جوڑے کو اجازت دینے والی فارورڈ چین ہے، اور سخت ہوسٹ پر عام طور پر ہر سمت کے لیے الگ واضح قاعدہ۔

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

حالت کے ساتھ فلٹرنگ ایسی علامت کی وضاحت کرتی ہے جو لوگوں کو غلط راستے پر لے جاتی ہے۔ قائم شدہ بہاؤ کے اندر جواب کو نئے اندرونی قاعدے کی ضرورت نہیں، اس لیے SYN-ACK کے بعد لٹکنے والا کنکشن کسی غائب قبولیت قاعدے سے بلاک نہیں ہو رہا؛ اسے گرا دیا جاتا ہے یا غلط روٹ کیا جاتا ہے۔ یہ فرق برقرار رکھیں، کیونکہ یہ روٹنگ تبدیلی کو فائر وال تبدیلی سے الگ کرتا ہے۔

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

روٹڈ یا مسکڈ: سوچ سمجھ کر چنیں

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

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

کلائنٹ کے پیچھے سب نیٹ الگ کام ہے

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

سمت بھی پالیسی کا سوال ہے۔ کلائنٹ کو اندرونی سروس سے کنکشن کھولنے کی اجازت خود بخود اندرونی ہوسٹ کو اس کلائنٹ سے کنکشن کھولنے کی اجازت نہیں دیتی۔ راستہ خراب ہونے کا نتیجہ اخذ کرنے سے پہلے سرور کی رسائی پالیسی اور کلائنٹ کی ہوسٹ فائر وال جانچیں۔

ایک بہاؤ اور ایک کیپچر سے تصدیق کریں

عام رسائی ٹیسٹ کے بجائے ایک ہی کنکشن سے راستہ ثابت کریں۔ دونوں سروں پر وہی بہاؤ دیکھیں: سروس پر آنے والی درخواست اور اسے چھوڑنے والا جواب۔

tcpdump -ni any host 10.90.0.25 and port 443

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

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