SNAT، DNAT اور Masquerade: VPN میں ہر NAT قاعدہ کیا کرتا ہے

VPN گیٹ وے کے دونوں طرف کیپچر رکھیں اور ایک بہاؤ چار مختلف پتے دکھا سکتا ہے۔ سورس NAT دوبارہ لکھتا ہے کہ پیکٹ کہاں سے آنے کا دعویٰ کرتا ہے؛ ڈیسٹینیشن NAT دوبارہ لکھتا ہے کہ وہ کہاں جاتا ہے۔ Masquerade تیسری سمت نہیں، یہ سورس-NAT قاعدہ ہے جو مقررہ قدر کی بجائے باہر جانے والے انٹرفیس سے پتہ لیتا ہے۔ بتائیں کہ تینوں میں سے آپ کو واقعی کون سا چاہیے اور زیادہ تر «VPN خراب ہے» ٹکٹ واپسی کے راستے کے سوال میں بدل جائیں گے۔

ہر قاعدہ کیا دوبارہ لکھتا ہے

سورس NAT، عام طور پر SNAT لکھا جاتا ہے، بہاؤ کا سورس پتہ بدلتا ہے جب وہ روٹر یا گیٹ وے چھوڑتا ہے۔ وصول کرنے والی سروس ترجمہ شدہ پتے پر جواب دیتی ہے اور ترجمہ کرنے والا باکس اس کنکشن کے لیے رکھی گئی حالت سے تبدیلی واپس پلٹاتا ہے۔ Linux میں وہ حالت conntrack میں رہتی ہے، اسی لیے conntrack -L اصل اور جوابی جوڑے ساتھ ساتھ چھاپتا ہے۔

ڈیسٹینیشن NAT، یعنی DNAT، اس کی بجائے منزل بدلتا ہے۔ UDP 51820 پر عوامی پتے کو بھیجا گیا پیکٹ 10.8.0.2:51820 پر اندرونی WireGuard سرور کی طرف دوبارہ لکھا جا سکتا ہے۔ گھریلو روٹر یا کلاؤڈ لوڈ بیلنسر VPN سننے والا اسی طرح شائع کرتا ہے اور یہ نہیں بتاتا کہ سرنگ آگے کیا لے جا سکتی ہے۔

Masquerade SNAT خاندان کا ہے۔ قاعدہ کوئی پتہ نہیں بتاتا؛ پیکٹ نکلتے وقت باہر جانے والے انٹرفیس کے پاس جو پتہ ہو وہی استعمال کرتا ہے۔ Linux اسے اپنا ہدف دیتا ہے اور DHCP یا PPPoE سے پتہ لینے والے WAN انٹرفیس پر یہ معمول کا انتخاب ہے۔

نقشہ کہاں رہتا ہے وہی ناکامی طے کرتا ہے

ہر حد پر جوڑا درج کریں: سرنگ سے پہلے، اس کے اندر اور عوامی انٹرفیس پر۔ سرنگ کے اندر کیپچر باہر والے سے قانونی طور پر مختلف ہوتا ہے اور جو ترجمہ کہاں ہوتا ہے یہ جانے بغیر دونوں کا موازنہ کرے گا وہ غلط ہوسٹ کے پیچھے بھاگے گا۔

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

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

Masquerade یا واضح SNAT

دونوں کا موازنہ ان کے وعدوں سے کریں۔ Masquerade اخراجی پتہ چنتا ہے، واضح SNAT اسے پن کرتا ہے۔ مستحکم عوامی پتے والے گیٹ وے پر پن کرنا لاگز اور شراکت داروں کی اجازت فہرستوں کو ایک قابل اندازہ قدر دیتا ہے۔ متحرک WAN لنک پر پن شدہ SNAT پتہ لیز بدلتے ہی غلط ہو جاتا ہے اور Masquerade بالکل اسی صورت کے لیے بنایا گیا ہے۔

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

پالیسی پر مبنی IPsec میں یہ سب سے زیادہ کاٹتا ہے۔ strongSwan کی فارورڈنگ گائیڈ IP فارورڈنگ فعال کرنے اور کلائنٹس کے لیے سورس-NAT قاعدہ شامل کرنے کی مرحلہ وار وضاحت کرتی ہے، اور وہی دستاویز اس ٹریفک کو خارج کرنے کا بھی احاطہ کرتی ہے جسے اپنا اصل پتہ رکھنا ہو۔ حفاظتی پالیسی کے میل کھانے سے پہلے سورس کا ترجمہ کریں، سرنگ اوپر آ سکتی ہے مگر ٹریفک پھر بھی گرتی رہے گی، کیونکہ پیکٹ اب طے شدہ سلیکٹر جیسا نہیں لگتا۔

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

Linux گیٹ وے پر قواعد پڑھنا

10.8.0.0/24 پر کلائنٹس اور eth0 نامی WAN انٹرفیس والے ریموٹ ایکسیس گیٹ وے کو فارورڈنگ فعال اور ٹریفک کی اجازت دینے والی فلٹر پالیسی درکار ہے، تبھی کوئی NAT قاعدہ مدد کر سکتا ہے۔ iptables ورژن دونوں سمتیں nat جدول میں رکھتا ہے:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables شکل وہی دو ہکس نامزد انٹرفیس اور واضح چین کے ساتھ استعمال کرتی ہے:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

دونوں اقتباسات فرض کرتے ہیں کہ فلٹر چین فارورڈ شدہ بہاؤ کو پہلے ہی قبول کرتی ہے۔ NAT اجازت کا قاعدہ نہیں اور درست ترجمہ شدہ پیکٹ بھی ایک جدول بعد رد ہو سکتا ہے۔ conntrack -L سے زندہ نقشہ کی تصدیق کریں، nft list ruleset یا iptables-save -t nat سے تصدیق کریں کہ کیا لوڈ ہے، پھر پتہ واقعی بدلتا دیکھنے کے لیے دونوں انٹرفیس پر کیپچر کریں۔

ناقص قاعدے جیسے نظر آنے والے ناکامی کے انداز

ہیئر پن ٹریفک کلاسک ہے۔ سرور کے عوامی پتے سے اندرونی سرور تک پہنچنے والے اندرونی کلائنٹ کو اندر آنے کے راستے DNAT اور واپس باہر جانے کے راستے سورس ترجمہ چاہیے، ورنہ سرور سیدھا کلائنٹ کو جواب دیتا ہے اور جواب مسترد ہو جاتا ہے۔ حل اسی اندرونی-سے-عوامی صورت کے لیے دوسرا، تنگ قاعدہ ہے، ہر چیز کے لیے وسیع Masquerade قاعدہ نہیں۔

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

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

قاعدہ محفوظ کرنے سے پہلے چیک لسٹ

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

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