nginx ٹوٹنے سے پہلے OpenVPN SNAT قاعدے کا دائرہ محدود کریں

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

یقینی بنائیں کہ کنٹینر tun آلہ بنا سکتا ہے

اگر سرنگ کا انٹرفیس وجود ہی نہ رکھ سکے تو باقی کچھ اہم نہیں۔ جانچیں کہ /dev/net/tun موجود ہے اور آزمائشی آلہ بنانا کامیاب ہوتا ہے، کیونکہ بہت سے فراہم کنندگان کنٹینرز میں tun بطور طے شدہ بند رکھتے ہیں۔ کبھی نہ بنائے گئے آلے کی تلافی کوئی firewall کام نہیں کرتا۔

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

طے کریں کہ اس انٹرفیس پر MASQUERADE کیا کرتا ہے

عام ورچوئل مشین پر معمول کا اخراجی قاعدہ مرکزی انٹرفیس سے POSTROUTING MASQUERADE ہوتا ہے۔ OpenVZ کنٹینر میں نظر آنے والا آلہ اکثر venet0 ہوتا ہے، یعنی میزبان کے زیرِ انتظام ورچوئل انٹرفیس، روٹ شدہ NIC نہیں، اور MASQUERADE وہاں ہمیشہ ویسا رویہ نہیں رکھتا جیسا ٹیوٹوریل فرض کرتے ہیں۔

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

قاعدے کو ایک pool اور ایک انٹرفیس تک محدود کریں

دوسری علامت کی وجہ مختلف ہے: ماخذ یا اخراجی پابندی کے بغیر POSTROUTING قاعدہ۔ ایسا قاعدہ میزبان چھوڑنے والے ہر پیکٹ کو دوبارہ لکھتا ہے۔

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

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

قواعد کو مستقل بنائیں اور جانیں کہ ان کا مزید مالک کون ہے

ہاتھ سے شامل کیے گئے قواعد ری بوٹ پر غائب ہو جاتے ہیں، اس لیے انہیں iptables-save سے محفوظ کریں یا جہاں یہ نصب ہے وہاں netfilter-persistent کے ذریعے منظم کریں۔ تصدیق کریں کہ بحالی OpenVPN شروع ہونے سے پہلے چلتی ہے۔ پھر واقعے کے دوران خلا دریافت کرنے کی بجائے جان بوجھ کر ایک بار ری بوٹ کریں۔

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

کاؤنٹر اور ایک گرفتار شدہ بہاؤ سے تصدیق کریں

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

سرور پر iptables -t nat -L -v -n سے NAT اور FORWARD قواعد کے پیکٹ کاؤنٹر پڑھیں اور ایک کیپچر میں ایک بہاؤ دیکھیں۔ اگر کیپچر میں کلائنٹ کا پتہ نظر آئے اور کوئی جواب نہ آئے تو خلا واپسی کے راستے پر یا فراہم کنندہ کی فلٹرنگ میں ہے، کلائنٹ پروفائل میں نہیں۔ گرفتار شدہ ماخذ کا موازنہ اس پتے سے کریں جس پر قاعدہ ترجمہ کرتا ہے، کیونکہ عدم مطابقت کا مطلب ہے کہ کوئی دوسرا قاعدہ پہلے ملا۔ ایک مشاہدہ شدہ بہاؤ کنفیگریشن پڑھنے کے ایک صفحے سے زیادہ طے کرتا ہے۔

pool، ترجمہ شدہ پتہ اور انٹرفیس کا نام تبدیلی ریکارڈ میں ساتھ رکھیں۔ ایک pool کے لیے درست قاعدہ اگلے کا غلط ترجمہ کرتا ہے۔