MULTI: کلائنٹ سے غلط ماخذ پتہ: یہ کس کا پتہ تھا؟
اندرونی ماخذ اس کلائنٹ سے میل نہیں کھاتا جس نے اسے پہنچایا۔ اسے ٹنل کے تخصیص، کلائنٹ کے پیچھے LAN، یا دوہری شناخت سے ملائیں۔
سرور لاگ MULTI: bad source address from client چھاپتا ہے، پیکٹ گرا دیتا ہے، اور سیشن جڑا رہتا ہے۔ یہ امتزاج ان لوگوں کو الجھاتا ہے جو پیغام کو تصدیق کی ناکامی سمجھتے ہیں۔ ایسا نہیں ہے: کلائنٹ تصدیق ہو چکا ہے، اور آنے والا پیکٹ ایک اندرونی ماخذ پتہ لے کر آیا تھا جسے سرور اس کلائنٹ کے نمونے سے منسلک نہیں کر سکا۔ جانچ پہنچانے سے پہلے ہوتی ہے، اسی لیے ٹنل صحت مند دکھائی دیتی ہے جبکہ اس میں سے کوئی مفید چیز نہیں گزرتی۔
پہنچانے سے پہلے سرور کیا موازنہ کرتا ہے
کلائنٹ سے آنے والے ہر پیکٹ کے لیے، صارف کی جگہ کا سرور ٹنل کے اندر ماخذ پتے کو دیکھتا ہے اور اپنی اندرونی روٹنگ حالت سے پوچھتا ہے کہ یہ پتہ کس کلائنٹ کا ہے۔ اگر مالک کوئی دوسرا نمونہ ہو، یا کوئی مالک ہی نہ ہو، پیکٹ ہٹا دیا جاتا ہے اور انتباہ جاری ہوتا ہے۔
ٹنل انٹرفیس کے ذریعے عام پہنچانا کبھی نہیں ہوتا۔
یہ ترتیب ایک ایسی تفصیل کی وضاحت کرتی ہے جو لوگوں کو حیران کرتی ہے: میزبان کے فائر وال کے کاؤنٹر نہیں ہلتے، کیونکہ پیکٹ کبھی فائر وال تک نہیں پہنچا۔ میزبان پر الٹی راہ کی چھانٹی کو ایڈجسٹ کرنے سے یہاں کچھ نہیں بدلتا، کیونکہ مسترد ہونا ڈیمن کی اپنی ربط جانچ میں ہوا۔ پیغام کو ملکیت کے بارے میں ایک بیان کے طور پر پڑھیں، پھر معلوم کریں کہ تین حالتوں میں سے کس نے یہ پیدا کیا۔
نہ ملنے والے اندرونی پتے کے تین ماخذ
کلائنٹ ایسے پتے سے بھیج رہا ہو سکتا ہے جو اسے تفویض نہیں ہوا، ایسے نیٹ ورک سے جسے کسی نے اپنا قرار نہیں دیا، یا ایسی شناخت کی نقل سے جس کا پہلے سے مالک ہے۔ تینوں ایک ہی لاگ سطر بناتے ہیں۔ وہ اس میں مختلف ہیں کہ آپ کو کیا بدلنا ہے۔ پتے اور موجودہ تخصیص کی فہرست سے شروع کریں، اور ان دو حقائق کو معاملہ چننے دیں۔
انہیں الگ کرنے کے لیے دو حقائق درکار ہیں: لاگ میں مسترد شدہ پتہ، اور وہ تخصیصات جنہیں سرور موجودہ سمجھتا ہے۔ دوسرا چلتی ہوئی مثال کے حالت یا انتظام کے منظر سے دستیاب ہے، اور مشورہ لینے کے قابل واحد اختیار یہی ہے، کیونکہ ترتیب کی فائل موجودہ حالت نہیں بلکہ ارادے درج کرتی ہے۔
کچھ بھی بدلنے سے پہلے دونوں درج کریں، پھر درجہ بندی کریں۔ بعد میں لی گئی اسکرین شاٹ اس حالت کا ریکارڈ نہیں ہے جس نے انتباہ پیدا کیا۔ وقت کی مہر بھی رکھیں، کیونکہ تخصیصات سیشنوں کے درمیان سرکتی ہیں۔
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
کلائنٹ کے پیچھے LAN اور iroute
جب سائٹ کلائنٹ اپنا نجی نیٹ ورک روٹ کرتا ہے، تو اس نیٹ ورک کو کلائنٹ کا قرار دینا ضروری ہے۔ iroute اندراج والی کلائنٹ مخصوص فائل یہ کرتی ہے، اور اندراج اس سابقے کا نام دیتا ہے جسے کلائنٹ لے جانے کا مجاز ہے۔
وہی سابقہ ٹنل کی طرف اشارہ کرنے والا کرنل راستہ الگ ضرورت ہے، اور اسے شامل کرنا ڈیمن کی اندرونی ملکیت میں کچھ نہیں بدلتا۔
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0یقینی بنائیں کہ مؤثر شناخت فائل کے نام سے میل کھاتی ہے، کیونکہ نہ ملنا یعنی فائل کبھی لوڈ نہیں ہوتی اور علامت غائب اندراج جیسی ہی ہوتی ہے۔ انتباہ کو خاموش کرنے کے لیے وسیع iroute شامل نہ کریں، کیونکہ یہ غیر متوقع ماخذ کو مجاز بنا دیتا ہے اور یہ نہیں بتاتا کہ کلائنٹ نے اسے کیوں بھیجا۔ OpenVPN 2.6 کی دستی iroute، duplicate-cn اور شناخت کی نقشہ بندی کو الگ کنٹرول کے طور پر درج کرتی ہے۔
دو مشینوں پر ایک ہی شناخت
دوسرے لیپ ٹاپ پر نقل کی گئی پروفائل وہی سرٹیفکیٹ اور وہی عام نام رکھتی ہے۔ سرور کی ترتیبات کے مطابق نیا کنکشن پرانے کی جگہ لے سکتا ہے، اور ربط جانچ وہ نمونہ جیتتا ہے جس کے پاس ملکیت ہے۔
اس سے خرابی وقفے وقفے سے دکھائی دیتی ہے اور صرف اس وقت ظاہر ہوتی ہے جب دونوں آلات بیدار ہوں۔
دوہرے عام ناموں کی اجازت دونوں کو جڑنے دیتی ہے، مگر انہیں الگ مستقل پتے یا الگ ملکیت نہیں دیتی۔ اگر دو آلات کو ساتھ رہنا ہے، تو انہیں الگ الگ رجسٹر کریں تاکہ ہر ایک کی اپنی شناخت اور اپنی تخصیص ہو۔ دوہری ترتیب کو اس انتباہ کا علاج سمجھنا معمہ اپنی جگہ رکھتا ہے اور ایک اور بڑھا دیتا ہے۔
ثابت کریں کہ ربط بدل گیا
ترمیم کو ترتیب کے مالک کے ذریعے لاگو کریں، پھر متاثرہ کلائنٹ کو دوبارہ جوڑیں تاکہ نئی پالیسی لوڈ ہو۔
وہی بہاؤ دہرائیں اور تین چیزوں کی تصدیق کریں: پیکٹ کا اندرونی ماخذ، وہ کلائنٹ نمونہ جس سے سرور اسے جوڑتا ہے، اور اس کے بعد منزل کا رویہ۔
اگر انتباہ رک جائے مگر ایپلیکیشن پھر بھی ناکام ہو، تو مسئلہ ختم نہیں ہوا بلکہ جگہ بدل گیا ہے۔ آگے بھیجنا، فائر وال کے قواعد اور واپسی کا راستہ الگ مراحل ہیں، اور ربط جانچ پاس کرنے کا مطلب صرف یہ ہے کہ پیکٹ کو ٹنل چھوڑنے کی اجازت ملی۔