برج شدہ OpenVPN کلائنٹس میں انٹرنیٹ نہیں؟ NAT قاعدہ چیک کریں

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

ثبوت کاؤنٹر ہے، جدول کا اندراج نہیں

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

iptables -t nat -L POSTROUTING -v -n

پہلے انٹرفیس کے میل کے پاس کا کاؤنٹر پڑھیں۔ اگر ماخذ کی حد درست ہے اور نکلنے کا رخ غلط ہے، تو اصلاح نیا قاعدہ نہیں بلکہ قاعدے میں ایک لفظ ہے۔

وہ نام تلاش کریں جو کرنل واقعی درج کرتا ہے

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

ip -brief link

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

ٹنل ڈیوائس کے لیے قاعدہ دوبارہ لکھیں

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

کاؤنٹروں کے ساتھ forward زنجیر پڑھنے میں ایک حکم لگتا ہے اور دوسرے قاعدے کو چھونے سے پہلے باقی آدھے امکانات یہی مسترد کر دیتا ہے۔

فزیکل کارڈ کبھی کیوں نہیں ملتا

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

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

اسے شروع سے آخر تک ثابت کریں، پھر مستقل کریں

ایک کلائنٹ اٹھائیں اور سرور کے LAN میں کچھ پنگ کریں؛ وہ راستہ بغیر کسی ترجمے کے فارورڈنگ کی مشق کرتا ہے۔ اس کے بعد کوئی عوامی چیز طلب کریں تاکہ masquerade قاعدہ استعمال کرنا پڑے، اور کاؤنٹر ایک بار پھر پڑھیں: اسے اس امتحان کے لیے ہلنا چاہیے، پچھلے کے لیے نہیں۔ ٹنل ڈیوائس پر لی گئی گرفت دکھاتی ہے کہ فریم کہاں ظاہر ہوتا ہے اور کون سا پتہ اٹھائے ہوئے ہے۔

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

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