NAT کے پیچھے WireGuard peer تک پورٹ فارورڈنگ: DNAT اور SNAT

ایک براؤزر https://203.0.113.10:8443 کی درخواست کرتا ہے، پراکسی کنکشن قبول کرتی ہے، اور WireGuard peer پر سروس کبھی جواب نہیں دیتی۔ DNAT قاعدہ اپنا کام کر رہا ہے؛ ناکام ہونے والا حصہ جواب ہے۔ پیکٹ کو دونوں ترجموں سے گزاریں اور گمشدہ قاعدہ واضح ہو جاتا ہے۔ حل درست hook میں ایک اور NAT بیان ہے، نئی ٹنل نہیں۔

ایک درخواست کو شروع سے آخر تک دیکھیں

درخواست پراکسی کے عوامی انٹرفیس پر پہنچتی ہے، ماخذ کلائنٹ کا عوامی پتہ اور منزل پراکسی کا پتہ ہوتا ہے۔ nat PREROUTING میں DNAT قاعدہ منزل کو peer کی ٹنل کے پتے 10.90.0.2 پر دوبارہ لکھتا ہے۔ پھر روٹنگ کا فیصلہ پیکٹ کو wg0 کے ذریعے باہر بھیجتا ہے، اور فارورڈ راستہ مکمل ہو جاتا ہے۔

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

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

واپسی ترجمہ شامل کریں

فارورڈ ہونے والے بہاؤ کا ماخذ peer کی طرف جانے سے پہلے پراکسی کی ٹنل کے پتے پر دوبارہ لکھیں۔ پھر سروس 10.90.0.1 کو جواب دیتی ہے، پراکسی اسے وصول کرتی ہے، اور پیکٹ کے کلائنٹ کی طرف واپس جانے سے پہلے کنکشن ٹریکنگ دونوں ترجمے الٹ دیتی ہے۔

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING قاعدہ جان بوجھ کر تنگ ہے: یہ ترجمہ شدہ منزل اور ٹنل انٹرفیس سے مماثل ہے، اس لیے wg0 سے اتفاقاً نکلنے والی غیر متعلقہ ٹریفک دوبارہ نہیں لکھتا۔ ایک وسیع masquerade قاعدہ بھی کلائنٹ کا پتہ چھپاتا، مگر یہ ہر بہاؤ کے لیے ایسا کرتا اور NAT جدول کی جانچ مشکل بنا دیتا۔

قواعد وہاں رکھیں جہاں ٹنل موجود ہے

ٹنل کے پتے یا انٹرفیس کا حوالہ دینے والے قواعد wg-quick کے اسے ترتیب دینے کے بعد چلنے چاہئیں۔ انٹرفیس PreUp سے پہلے بنتا ہے، مگر پتے، MTU، DNS اور راستے اس کے بعد لاگو ہوتے ہیں، اور PostUp تب چلتا ہے جب یہ سب اپنی جگہ پر ہو۔ اضافے PostUp میں اور حذف PreDown میں رکھیں۔

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

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

نتیجہ iptables -t nat -S سے دوبارہ کنکشن کے بعد جانچیں۔ اگر وہی قاعدہ دو بار نظر آئے تو PreDown سطر مماثل نہیں ہے اور صفائی خاموشی سے ناکام ہو رہی ہے۔

فارورڈنگ، فلٹرنگ اور دوسرا NAT

IPv4 فارورڈنگ مستقل طور پر فعال کریں، پھر فلٹر جدول میں فارورڈ ہونے والے بہاؤ کی اجازت دیں۔ DNAT FORWARD زنجیر سے پہلے ہوتا ہے، اس لیے فلٹر قاعدہ عوامی پتے کے بجائے ترجمہ شدہ منزل سے مماثل ہے۔ اگر UFW فائر وال سنبھالتی ہے تو اجازت کو راستے کے قاعدے کے طور پر بیان کریں؛ عام host قاعدہ فارورڈ ہونے والی ٹریفک کا احاطہ نہیں کرتا۔

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

NAT VPS پر فراہم کنندہ عوامی پورٹ کو نجی پتے پر میپ کرتا ہے۔ میپنگ اسی پورٹ سے مماثل ہونی چاہیے جس کا آپ اعلان کرتے ہیں، اور عدم مطابقت ٹوٹی ٹنل جیسی نظر آتی ہے۔ WireGuard ترتیبات بدلنے سے پہلے فراہم کنندہ کی میپنگ کی تصدیق کریں۔

واپسی راستہ جانچیں اور لاگت قبول کریں

پراکسی کے LAN کے علاوہ کسی نیٹ ورک سے جڑیں، پھر کنکشن کھلا رہنے کے دوران ترجمہ جوڑی کا معائنہ کریں:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

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

یہ ثابت کرنے کے لیے ایک بار دوبارہ شروع کریں کہ PostUp قواعد دوبارہ لاگو کرتا ہے، پھر ٹنل روکیں اور تصدیق کریں کہ PreDown نے وہ ہٹا دیے۔ ڈسکنیکٹ کے بعد بچے مردہ قواعد ہی اس بات کی وجہ ہیں کہ بعد کی تبدیلی غیر متوقع طور پر برتاؤ کرتی ہے۔

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