VPS فائر وال: صرف VPN پورٹ کھولیں، پھر اسے ثابت کریں

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

وہ واحد پورٹ جسے بند نہیں کیا جا سکتا

VPN سننے والے کو ایسے پتوں سے رابطے قبول کرنے پڑتے ہیں جن کا آپ پیشگی اندازہ نہیں لگا سکتے، اس لیے یہ تعریف کے مطابق عوامی سروس ہے۔ ڈیزائن اسی ایک استثنا پر قائم ہے: OpenVPN کے لیے ایک UDP پورٹ، WireGuard کے لیے ایک UDP پورٹ، SSL VPN کے لیے ایک TCP پورٹ۔ باقی سب کچھ ٹنل کے پیچھے ہے، یعنی ایپلی کیشن سروسز کو ہر انٹرفیس کی بجائے ٹنل کے پتے یا loopback سے بندھنا چاہیے۔

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

اِن پٹ، فارورڈ اور NAT مختلف سوالوں کے جواب دیتے ہیں

اِن پٹ ٹریفک میزبان ہی کے لیے ہے، اس لیے VPN سننے والا اور انتظامی راستہ وہیں رہتے ہیں۔ فارورڈ ٹریفک میزبان سے گزرتا ہے، اور ٹنل کلائنٹس کو یہ net.ipv4.ip_forward=1 کے ساتھ درکار ہوتا ہے۔ روایتی آدھا ٹوٹا کنفیگریشن باہر جانے والے بہاؤ کی اجازت دیتا ہے اور واپسی کی سمت بھول جاتا ہے، چنانچہ کلائنٹ ہینڈ شیک مکمل کرتا ہے اور پھر کچھ لوڈ نہیں ہوتا؛ قائم اور متعلقہ ٹریفک کے لیے conntrack قاعدہ اُس سمت کو ڈھانپ لیتا ہے۔

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

IPv6 دوسری پالیسی ہے، بعد کی سوچ نہیں۔ سخت IPv4 چین اور ip6tables پر کھلی پالیسی والے میزبان نے کچھ نہیں بند کیا؛ سروسز اب بھی دوسرے خاندان کے ذریعے قابل رسائی ہیں۔ یا تو ip6tables کے ساتھ قواعد کا مجموعہ منعکس کریں، یا عوامی انٹرفیس پر IPv6 دانستہ بند کریں، اور لکھیں کہ کون سا چنا۔

ایک ہی نظر میں پڑھا جانے والا بنیادی ڈھانچہ

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

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

میزبان گنوائے بغیر آخری پورٹ بند کرنا

ڈیزائن میں ایک جال ہے۔ اگر SSH صرف ٹنل کے ذریعے موجود ہے، تو ناکام VPN سروس SSH کو بھی ساتھ لے جاتی ہے، اور واپسی کا واحد راستہ ایسا کنسول ہو سکتا ہے جو آپ نے کبھی نہ کھولا ہو۔ آخری عوامی پورٹ بند کرنے سے پہلے یقینی بنائیں کہ وہ کنسول موجود ہے اور آپ واقعی اسے استعمال کر سکتے ہیں، یا ٹنل پر منحصر نہ ہونے والا ایک تنگ انتظامی راستہ رکھیں: مقررہ پتے سے SSH، صرف کلیداں، پاس ورڈ کی توثیق بند۔

تبدیلی پہلے سے قائم سیشن سے لاگو کریں، اُس رابطے کے ذریعے نہیں جسے آپ فلٹر کرنے والے ہیں۔ رول بیک کا وقت مقرر کریں تاکہ غلطی مستقل ہونے کی بجائے ختم ہو جائے، مثلاً پچھلے قواعد کا مجموعہ بحال کرنے والا systemd-run --on-active=10min کام، اور پہلے کی جانچ کے دوران دوسرا SSH سیشن کھلا رکھیں۔ پھر تصدیق کریں کہ رول بیک کام واقعی چلتا ہے، کیونکہ غیر جانچا ہوا بحالی بحالی نہ ہونے کے برابر ہے۔

سکرپٹ نہیں، راستہ جانچیں

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

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

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

ایک عادت قواعد کے مجموعے سے زیادہ قیمتی ہے: ہر تبدیلی کے بعد کلائنٹ کی درخواست سے فارورڈ راستہ اور دوسرے سیشن سے بحالی راستہ ثابت کریں۔ جو لاک ڈاؤن آپ نے استعمال نہیں کیا وہ محض ایک مفروضہ ہے۔