جب CGNAT پورٹس کو بلاک کرے تو VPS کے ذریعے گھریلو سرور شائع کرنا

میں نے باہر سے شروع کیا، جیسے کوئی صارف کرتا: نام کو موبائل ڈیٹا پر فون کے براؤزر میں لکھا اور دیکھا کہ کنکشن وقت ختم ہونے تک لٹکا رہا۔ نام حل ہو رہا تھا، یعنی DNS درست تھا۔ گھر کے راؤٹر کا پورٹ فارورڈنگ صفحہ بھی بند گلی تھا، کیونکہ اس کا WAN پتہ 100.64.31.42 دکھا رہا تھا، اور یہ ایسا پتہ نہیں جہاں کوئی فراہم کنندہ مجھے انٹرنیٹ سے بھیجے۔ یہ عدد پوری خرابی کی وضاحت کرتا ہے: لائن carrier-grade NAT کے پیچھے ہے، اس لیے سرنگ کی میری طرف کا عوامی پتہ فراہم کنندہ کا ہے۔ آگے وہ راستہ ہے جو میں نے اس لٹکے ہوئے ٹیب سے جواب دینے والی سروس تک طے کیا۔

کلائنٹ سے شروع کریں اور اندر کی طرف چلیں

کوئی بھی قاعدہ بدلنے سے پہلے ثابت کریں کہ زنجیر کہاں رکتی ہے۔ لیپ ٹاپ پر میں نے dig +short files.example.net چلایا اور VPS کا پتہ واپس ملا، جس نے میری مشین پر پرانا DNS خارج کر دیا۔ پھر curl -v --connect-timeout 5 files.example.net:5022 رد ہونے کے بجائے وقت ختم ہونے پر جا پڑا۔ یہ فرق اہم ہے: وقت ختم ہونا عام طور پر یعنی پیکٹ راستے میں گرا دیے جا رہے ہیں، جبکہ رد ہونا یعنی کسی چیز نے جواب دیا اور نہیں کہا۔

اندر کی طرف اگلا قدم خود VPS تھا۔ ss -ltnp نے کچھ نہیں دکھایا جو 5022 پر سن رہا ہو، جو DNAT قاعدہ بننے سے پہلے متوقع تھا۔ اسی مشین پر wg show (یا OpenVPN کے لیے ip -br a show tun0) نے تصدیق کی کہ گھریلو peer فعال ہے اور اس کا handshake تازہ ہے۔ اگر peer کام نہ کرے تو کوئی NAT قاعدہ مدد نہیں دے گا، اور گھر کے راؤٹر کے VPN صفحے پر سبز بتی کچھ معنی نہیں رکھتی۔

تصدیق کریں کہ گھریلو لائن واقعی CGNAT کے پیچھے ہے

راؤٹر جو پتہ اپنے WAN انٹرفیس پر بتاتا ہے اسے اس سے موازنہ کریں جو کوئی بیرونی سروس دیکھتی ہے۔ 100.64.0.0/10 میں جو کچھ ہے، یعنی 100.64.x.x سے 100.127.x.x تک، RFC 6598 کا مشترکہ پتہ رینج ہے اور انٹرنیٹ سے قابل رسائی نہیں۔ اسی نتیجے پر آپ تب بھی پہنچیں گے جب راؤٹر کوئی عام نجی پتہ ہونے کا دعویٰ کرے اور عوامی تلاش کوئی غیر متعلق چیز واپس دے۔ CGNAT لائن کے ساتھ ایسا عوامی پتہ بھی ہو سکتا ہے جو صرف اگلے lease تک رہے، اس لیے پورٹ فارورڈنگ ایک گھنٹے کام کرتی دکھتی ہے اور پھر خاموشی سے مر جاتی ہے۔

کچھ فراہم کنندگان واقعی حقیقی عوامی پتہ دیتے ہیں مگر رہائشی اکاؤنٹس پر آنے والے 80 اور 443 پورٹس بلاک کر دیتے ہیں۔ اگر آپ کی سروس صرف ویب ہے اور WAN پتہ واقعی عوامی ہے تو relay بنانے سے پہلے سپورٹ سے پوچھیں۔ اگر نہیں، تو نیچے کا ڈیزائن ہر پورٹ پر یکساں لاگو ہوتا ہے، اور تجربہ راؤٹر کی طرف روکنا بہتر ہے: فراہم کنندہ کے نیٹ ورک میں مترجم کنکشن کو ختم کر دیتا ہے اس سے پہلے کہ وہ کبھی آپ کے WAN انٹرفیس تک پہنچے۔

نام کو VPS کے پتے کی طرف اشارہ کریں

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

اگر VPS اور گھریلو مشین دونوں HTTP پیش کریں تو ہر ایک کو اپنا نام دیں اور VPS کو فیصلہ کرنے دیں کہ کون جواب دے۔ انہیں ایک نام میں سمیٹ کر یہ امید کرنا کہ پراکسی درست backend چنے گا، بالکل وہی طریقہ ہے جس سے آپ ساری دوپہر غلط میزبان پر خرابی ڈھونڈتے ہیں۔

ایک پورٹ DNAT پر، SSH 22 پر رہے

براہِ راست آپشن VPS پر منزل کا NAT ہے۔ چل رہے کرنل کے لیے forwarding فعال کریں اور قاعدے میں گھریلو سرور کا ٹنل پتہ رکھیں، اس کا LAN پتہ نہیں:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

خود VPS تک SSH کو 22 پر رہنے دیں اور کوئی اور پورٹ، مثلاً 5022، گھریلو مشین کی طرف بھیجیں۔ اگر 22 کسی بند مشین کی طرف بھیجیں تو وہ واحد راستہ کھو دیں گے جو اسے درست کر سکتا تھا۔ یہی منطق پراکسی پر بھی لاگو ہے: VPS کا انتظامی پورٹ relay قواعد سے باہر رکھیں۔

قواعد کو کام کرنے لگیں تو مستقل کر دیں۔ Debian یا Ubuntu پر apt install iptables-persistent اور پھر netfilter-persistent save انہیں /etc/iptables/rules.v4 میں لکھتے ہیں۔ firewalld والے میزبان پر اس کا متبادل زون میں مستقل پورٹ فارورڈنگ ہے، جسے لاگو ہونے سے پہلے firewall-cmd --reload درکار ہے۔ صرف یادداشت میں رہنے والے قواعد فراہم کنندہ کے پہلے دیکھ بھال والے ری اسٹارٹ پر غائب ہو جاتے ہیں، عموماً کسی برے وقت پر۔

واپسی کا راستہ درست کریں یا اس کی ضرورت سے بچیں

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

دو اصلاحیں کام کرتی ہیں۔ گھریلو مشین کو پالیسی راستہ دیں تاکہ ٹنل سے آنے والی ٹریفک ٹنل سے واپس جائے:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

یا VPS کو ماخذ دوبارہ لکھنے دیں تاکہ جواب کا ایسا پتہ ہو جو وہ پا سکے، اور conntrack اسے باہر جاتے وقت پلٹ دے:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

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

پورا راستہ باہر سے جانچیں

ایسے نیٹ ورک سے تصدیق کریں جو نہ VPS ہے نہ گھر: موبائل ڈیٹا پر فون، یا کہیں اور سستا shell۔ nc -vz files.example.net 5022 کو کامیاب کنکشن کی اطلاع دینی چاہیے، اور openssl s_client -connect files.example.net:443 -servername files.example.net کو عوامی نام کے لیے سرٹیفکیٹ دکھانا چاہیے۔ پھر فراہم کنندہ کا سیکیورٹی گروپ یا کلاؤڈ فائر وال دیکھیں۔ ایسا DNAT قاعدہ جو کبھی پیکٹ نہیں دیکھتا عموماً میزبان سے ایک پرت اوپر بلاک ہوتا ہے۔

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