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

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

کلائنٹ سے شروع کریں اور باہر کی طرف جائیں

اسی ترتیب سے تین ٹیسٹ کریں اور لکھیں کہ پہلا کہاں ناکام ہوتا ہے۔ سرور کے ٹنل پتے پر ping کریں، جو ثابت کرتا ہے کہ ٹنل خود ٹریفک لے جا رہی ہے۔ نمبر سے کسی عوامی پتے پر ping کریں، جو نام کے حل کو شامل کیے بغیر آگے بھیجنے اور ترجمے کو ثابت کرتا ہے۔ پھر کسی ہوسٹ نام کو حل کرنے کی کوشش کریں، جو واحد ٹیسٹ ہے جو DNS استعمال کرتا ہے۔ ہر نتیجہ شک سے ایک پوری تہہ ہٹا دیتا ہے۔

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

دو کیپچر دکھاتے ہیں کہ پیکٹ کہاں رکتے ہیں

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

اس آؤٹ پٹ کا dev فیلڈ وہ نام ہے جو NAT قاعدے کو بعد میں درکار ہوگا، اس لیے اسے رکھیں۔

آگے بھیجنا کرنل کا ایک سوئچ اور فائر وال کی پالیسی ہے

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

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

آگے بھیجنا آدھا ہی ہے۔ UFW والے ہوسٹ پر فارورڈ پالیسی /etc/default/ufw میں مقرر ہوتی ہے اور ری لوڈ لاگو ہونے سے پہلے اسے ACCEPT ہونا چاہیے۔ فارورڈ راستے پر ڈیفالٹ ڈراپ ہینڈ شیک کو بالکل صحت مند رکھتا ہے اور ٹنل سے باہر نکلنے کی کوشش کرنے والا ہر پیکٹ خاموشی سے گرا دیتا ہے، اور یہی وہ علامت ہے جس سے آپ نے شروع کیا تھا۔

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

NAT قاعدے میں اصل ایگریس انٹرفیس کا نام دیں

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

کلاسیکی ناکامی وہ قاعدہ ہے جو کسی گائیڈ سے نقل کیا گیا اور -o eth0 کہتا ہے ایسی مشین پر جس کا اڈاپٹر کچھ اور کہلاتا ہے۔ قاعدہ بغیر انتباہ انسٹال ہو جاتا ہے، کسی سے میل نہیں کھاتا، اور کلائنٹ کے پاس انٹرنیٹ نہیں آتا۔ پول اسی غلطی کا دوسرا نصف ہے: اگر سرور 10.44.0.0/24 تقسیم کرتا ہے اور قاعدہ 10.8.0.0/24 کو ڈھانپتا ہے، تو کچھ بھی کبھی میل نہیں کھائے گا۔

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS پہلی کے پیچھے دوسری ناکامی ہے

نام ناکام ہوں مگر پتے سے ping چلے، یہ resolver کا مسئلہ ہے، اور اس کی اپنی وجہ ہے۔ جو کلائنٹ اپنا مقامی resolver رکھتا ہے وہ وہ استفسارات پوری ٹنل میں بھیجتا ہے اور ایسے جواب کا انتظار کرتا ہے جو کبھی نہیں آتا، کیونکہ مقامی resolver اب راستے کے غلط طرف ہے۔

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows کلائنٹ پھر بھی مقامی resolver پر واپس آ سکتے ہیں، اور block-outside-dns بالکل یہی روکنے کے لیے ہے، مگر اس قیمت پر کہ صرف مقامی نیٹ ورک کے حل کر سکنے والے نام ضائع ہو جائیں۔ systemd-resolved والے Linux کلائنٹ اکثر بھیجے گئے resolver کو نظر انداز کرتے ہیں جب تک کوئی اسکرپٹ اسے انسٹال نہ کرے، اس لیے یہ ماننے سے پہلے کہ بھیجنا نظر انداز ہوا، ٹنل ڈیوائس کے لیے resolvectl status دیکھیں۔

اس سفر کو ویسے ہی مکمل کریں جیسے صارف تجربہ کرتا ہے۔ کلائنٹ سے اصل صفحہ لوڈ کریں، تصدیق کریں کہ وہ کس پتے سے باہر جاتا ہے، سرور ری بوٹ کریں، دوبارہ جڑیں اور تینوں ٹیسٹ دہرائیں۔ صرف وہی دوسرا دور ثابت کرتا ہے کہ محفوظ قواعد، فائر وال پالیسی اور بھیجا گیا resolver سب ساتھ ٹکے رہے۔