iptables: VPN کلائنٹس کو صرف ایک ہوسٹ تک پہنچنے دیں

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

کون سی زنجیر آپ کے سوال کا جواب دیتی ہے

VPN کلائنٹ جو پیکٹ LAN ہوسٹ کو یا آگے انٹرنیٹ کی طرف بھیجتا ہے، کرنل انہیں آگے بھیجتا ہے اور ان کا جائزہ FORWARD میں ہوتا ہے۔ INPUT اور OUTPUT صرف وہ ٹریفک دیکھتے ہیں جو سرور پر ہی ختم ہوتا ہے یا وہیں سے شروع ہوتا ہے۔ اسی لیے tun0 پر نہ آنے والی ہر چیز کو مسترد کرنا سرور کے اپنے سامعین کی حفاظت کرتا ہے، اور اگر قائم شدہ فلو پہلے اجازت نہ پائیں تو یہ آپ کا SSH سیشن بھی ختم کر دے گا۔ اس سے اس بات میں کچھ نہیں بدلتا کہ کلائنٹس کہاں جا سکتے ہیں۔

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

پہلے حالت، پھر اجازت، پھر انکار

اجازت کی فہرست تبھی کام کرتی ہے جب مخصوص اجازت عام انکار کے اوپر ہو اور واپسی ٹریفک دونوں کے اوپر اجازت یافتہ ہو۔ قواعد کو واضح مقامات پر داخل کریں، پھر iptables -S FORWARD سے زنجیر نکالیں تاکہ ترتیب فرض نہ کی جائے بلکہ نظر آئے۔

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

حقیقی ٹریفک سے ٹکراؤ میں یہ ٹکے گا یا نہیں، یہ دو تفصیلیں طے کرتی ہیں۔ حالت کے قاعدے کے بغیر، جن کنکشنز کو آپ نے ابھی اجازت دی، ان کے جواب خود انکار کے سامنے جانچے جاتے ہیں اور پھینک دیے جاتے ہیں۔ بے حد LOG قاعدہ پہلی اسکین پر ہی چھوٹا حصہ بھر سکتا ہے، اس لیے لاگنگ جاری رکھنے سے پہلے -m limit --limit 10/min شامل کریں۔ REJECT فوراً غلطی واپس کرتا ہے، جو فہرست درست کرتے وقت زیادہ دوستانہ ہے؛ DROP خاموشی سے پھینک دیتا ہے، اس لیے ہر غلطی وقت ختم ہونے کی طرح دکھتی ہے۔ جان بوجھ کر ایک منتخب کریں اور انتخاب کو تبدیلی کے ریکارڈ میں لکھیں۔

فارورڈنگ اور NAT پہلے سے کام کر رہے ہوں

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

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

میل بلاک ایک زنجیر آگے ہے

INPUT میں پورٹ 25 بلاک کرنا صرف وہ میل روکتا ہے جو VPN سرور کو بھیجا گیا ہو۔ ٹنل سے میل بھیجنے والا متاثرہ کلائنٹ فارورڈ ہوتا ہے، اس لیے بلاک 465 اور 587 کے ساتھ FORWARD میں ہونا چاہیے۔ اگر کوئی ایپلیکیشن قانونی طور پر میل ری لے کرتی ہے تو اس کی منزل اور پورٹ اس قاعدے کے اوپر رکھیں۔

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

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

اسے دوبارہ پڑھیں، پھر کلائنٹ سے ثابت کریں

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

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