PiVPN کا ہینڈ شیک کام کرتا ہے، صفحات رک جاتے ہیں: MASQUERADE چیک کریں

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

اس بات سے شروع کریں کہ کلائنٹ کیا حاصل کر سکتا ہے اور کیا نہیں

منسلک کلائنٹ سے، عوامی انٹرنیٹ پر موجود صفحہ لوڈ کریں اور نوٹ کریں کہ یہ فوراً ناکام ہوتا ہے یا درمیان میں رک جاتا ہے۔ پھر VPN سرور کے اپنے نجی پتے پر کوئی وسیلہ کھولیں اور دونوں نتائج کا موازنہ کریں۔

جو ٹنل پتہ ping کا جواب دیتا ہے جبکہ عوامی سائٹس کا وقت ختم ہو جاتا ہے، وہ فارورڈنگ یا ترجمے کے مسئلے کی علامت ہے، ٹوٹے ہینڈ شیک کی نہیں۔ کلائنٹ کا اپنا اسٹیٹس پینل ان دونوں میں فرق نہیں کر سکتا، کیونکہ اسے صرف یہ معلوم ہے کہ کنٹرول چینل اوپر ہے۔ سرور پر ٹنل انٹرفیس اس سے چیک کریں: ip -br addr show tun0 اور تصدیق کریں کہ کلائنٹ کو دیا گیا پتہ آپ کے ترتیب دیے گئے پول کے اندر آتا ہے۔ اگر پول اور کلائنٹ پتہ مطابقت نہ رکھیں تو پہلے اسے درست کریں، کیونکہ نیچے کا ہر اصول پول سے مطابقت رکھتا ہے۔

اس کے بعد سرور سے پوچھیں کہ عوامی پتے تک پہنچنے کے لیے وہ کون سا انٹرفیس استعمال کرے گا۔ ip route get 203.0.113.9 اپنی پہلی سطر میں منتخب ڈیوائس اور ماخذ چھاپتا ہے۔ اس ڈیوائس کا نام لکھ لیں، کیونکہ NAT اصول میں یہی قدر ہونی چاہیے۔

وہ اصول پڑھیں جو فیصلہ کرتا ہے کہ پیکٹ باہر جائیں گے یا نہیں

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

زندہ جدول کی فہرست بنائیں اور صرف MASQUERADE لفظ تلاش کرنے کے بجائے آؤٹ انٹرفیس کالم پڑھیں۔ فارمیٹ شدہ فہرست سے شامل کرنے کی شکل کا آؤٹ پٹ موازنہ کرنا آسان ہے:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

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

محفوظ اصولوں کے مجموعے کو درست کریں، صرف چلنے والے کو نہیں

صرف زندہ جدول میں ترمیم اگلی ری بوٹ تک چلتی ہے، جو آپ کو یہ یقین دلانے کے لیے بالکل کافی ہے کہ مسئلہ حل ہو گیا ہے۔ بوٹ پر واپس آنے والے اصول ایسی فائل میں رہتے ہیں جسے فائر وال پائیداری پیکج دوبارہ لوڈ کرتا ہے۔ Debian پر مبنی Pi امیجز میں وہ فائل عام طور پر /etc/iptables/rules.v4۔

اسے چھونے سے پہلے نقل لیں، پھر MASQUERADE سطر کا آؤٹ انٹرفیس اس ڈیوائس سے بدلیں جو آپ نے لکھا، مثال کے طور پر -o wlan0 کی بجائے -o eth0۔ ماخذ کی حد کو ویسے ہی رہنے دیں، جب تک آپ کا کلائنٹ پول نہ بدلا ہو۔ دوبارہ لوڈ کریں اور تصدیق کریں کہ اصول اب درست ڈیوائس بتاتا ہے:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

ملحقہ دو ترتیبات بھولنا آسان ہے۔ sysctl net.ipv4.ip_forward کو 1 بتانا چاہیے، اور اوپر والے روٹر کو نجی ماخذ پتے خود فلٹر نہیں کرنے چاہئیں۔

ثابت کریں کہ اصول متحرک ہوتا ہے، پھر الگ کریں کہ اب بھی کیا سست ہے

کاؤنٹر ہی اس بات کا واحد ایماندار ثبوت ہیں کہ کوئی اصول مطابق ہوا۔ تفصیلی فہرست چلائیں، کلائنٹ پر ڈاؤن لوڈ شروع کریں اور دوبارہ چلائیں۔ آپ کے اصول کے ساتھ والے پیکٹ اور بائٹ کالم بڑھنے چاہئیں، اور صفر پر رہنے والا اصول اب بھی مطابق نہیں۔ اگر کاؤنٹر حرکت کریں مگر صفحات اب بھی ناکام ہوں تو ماخذ کی حد کا اصل پول سے اس سے موازنہ کریں grep -n "^server " /etc/openvpn/server.conf۔ اگر وہ حرکت کریں اور صفحات لوڈ ہوں مگر تھرو پٹ خراب ہو تو ترجمہ ہو چکا ہے اور باقی مسئلہ کہیں اور ہے۔

ایک ہی کلائنٹ سے دو منتقلیوں کا موازنہ کریں، ایک مقامی نیٹ ورک کے ہوسٹ پر اور دوسری ٹنل کے ذریعے اسی ہوسٹ پر۔ دونوں میں سست ہونا VPN کی طرف نہیں بلکہ Pi کے اوپری لنک یا Wi-Fi کنکشن کی طرف اشارہ کرتا ہے۔ صرف ٹنل سے سست ہونا MTU اور دوبارہ ترسیل کی طرف اشارہ کرتا ہے، جنہیں آپ اس سے دیکھ سکتے ہیں ip -s link show tun0 کوئی بھی کرپٹو ترتیب بدلنے سے پہلے۔

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