CGNAT کے پیچھے سے VPN کلائنٹ پورٹ شائع کریں: چیک لسٹ

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

تصدیق کریں کہ سرور بالکل فارورڈ کرے گا

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

اسے چلتے ہوئے کرنل میں سیٹ کرنا ری بوٹ کے دوران سیٹ کرنے کے برابر نہیں۔ net.ipv4.ip_forward=1 کو /etc/sysctl.d/ کے تحت ایک فائل میں لکھیں، sysctl --system چلائیں، اور پھر فائل اٹھا لیے جانے پر بھروسہ کرنے کے بجائے قدر دوبارہ پڑھیں۔ جو کنٹینر اپنا نیٹ ورک نام فضا سنبھالتا ہے اسے اسی فضا کے اندر بھی وہی قدر درکار ہوتی ہے، صرف میزبان پر نہیں۔

اگر دوبارہ پڑھنے پر بھی صفر ہو تو یہیں رک جائیں۔ نیچے کچھ بھی کام نہیں کرے گا۔

کوئی بھی قاعدہ اس کا حوالہ دینے سے پہلے ٹنل کا پتہ مستحکم کریں

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

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

دونوں سمتوں میں ترجمہ کریں

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

دونوں قواعد iptables -t nat -S کے ساتھ دوبارہ پڑھیں اور تصدیق کریں کہ انٹرفیس کا نام وہی ہے جو عوامی پتہ رکھتا ہے۔ جس میزبان پر پہلے سے nftables سے فلٹر ہوتا ہے وہاں اوزار ملانے کے بجائے مطابق پتہ خاندان کی nftables NAT زنجیر میں ترجمہ لکھیں۔

فلٹر جدول کو گزرنے دیں

NAT جدولیں ہیڈر دوبارہ لکھتی ہیں؛ وہ اجازت نہیں دیتیں۔ ڈیفالٹ DROP پالیسی کے ساتھ فارورڈ ہونے والے بہاؤ کو اپنی اجازت چاہیے، نیز واپسی کی سمت جسے زیادہ تر پالیسیاں پہلے ہی established,related قاعدے سے ڈھکتی ہیں۔

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

اسے بیرونی نیٹ ورک سے ثابت کریں

غیر متعلقہ نیٹ ورک سے جانچیں۔ اسی LAN کی دوسری مشین سے جانچ hairpin NAT معاونت سے گزر سکتی ہے اور دور دراز کلائنٹ جو راستہ استعمال کرتا ہے اسے کبھی آزماتی نہیں، اس لیے وہاں کا سبز نتیجہ غلط چیز ثابت کرتا ہے۔

tcpdump -ni any port 29443
conntrack -L | grep 29443

سرور پر اور کلائنٹ پر ایک ہی وقت میں کیپچر چلائیں۔ سرور کا کیپچر دکھاتا ہے کہ مترجم پیکٹ ٹنل کی طرف نکلتا ہے یا نہیں؛ کلائنٹ کا کیپچر دکھاتا ہے کہ درخواست پہنچتی ہے اور جواب کہاں مخاطب ہے۔ conntrack -L میں ترجمے کا اندراج ثابت کرتا ہے کہ قاعدہ مطابق تھا، اور اس کا نہ ہونا ثابت کرتا ہے کہ پیکٹ کبھی NAT زنجیر تک نہیں پہنچا۔

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