تمام پورٹس فارورڈ کرنے والے قواعد آپ کے WireGuard لسنر کو نگل سکتے ہیں

ایک عوامی گیٹ وے پہلے ہی UDP 51820 پر WireGuard، 22 پر SSH اور ایک ایپلیکیشن چلا رہا ہے جس تک انٹرنیٹ سے رسائی ضروری ہے۔ پرکشش قاعدہ ہر پورٹ کو peer تک فارورڈ کر دیتا ہے اور کام مکمل قرار دے دیتا ہے۔ WireGuard گیٹ وے پر یہ قاعدہ خود سرنگ کی نقل و حمل کو پکڑ سکتا ہے اور آپ کو اُس مشین سے باہر قفل کر سکتا ہے جو اسے ختم کرتی ہے۔ اشاعت کنٹرول طیارے کی استثنا کے ساتھ روٹنگ کا فیصلہ ہے، ایک DNAT سطر نہیں۔

عوامی داخلہ یا سرنگ کا داخلہ: ایک چنیں

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

انتظامی انٹرفیس شاذ و نادر ہی اُس مقام کے لیے موزوں ہوتے ہیں۔ مجاز VPN کلائنٹس کی رسائی والا انتظامی صفحہ حملے کی سطح کو سرنگ کے اندر رکھتا ہے اور لاگ اِن فارم کو بے ترتیب اسکیننگ کے سامنے لانے سے بچاتا ہے۔ عوامی ایپلیکیشن اینڈ پوائنٹس کو اب بھی اپنا TLS سرٹیفکیٹ، توثیق اور شرح کی حد درکار ہے؛ خفیہ کردہ WireGuard چھلانگ زائرین کے گیٹ وے تک کے حصے کی حفاظت نہیں کرتی۔

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

ایک پورٹ اندر، ایک backend باہر

ایک عوامی پورٹ اور ایک backend سروس استعمال کریں۔ اس مثال میں eth0 عوامی پتہ 198.51.100.20 رکھتا ہے، گیٹ وے کا سرنگ پتہ 10.200.0.1 ہے، اور peer ایپلیکیشن 10.200.0.7 پر چلاتا ہے۔ عوامی TCP 9443 کو peer کے TCP 8443 پر نقش کیا جاتا ہے:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

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

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

peer کو گیٹ وے کے سرنگ پتے سے سروس کنکشن قبول کرنا اور جواب سرنگ کے ذریعے واپس بھیجنا ہوگا۔ اس کا AllowedIPs اُس ماخذ کی اجازت دے جسے وہ واقعی وصول کرتا ہے، جو ماخذ کی ترجمانی کے تحت گیٹ وے کا سرنگ پتہ ہے، اور اس ڈیزائن کے لیے ہر peer پر وسیع 0.0.0.0/0 اندراج ضروری نہیں۔ واپسی ٹریفک گراتی ہے وہ peer جس کی فہرست اُس پتے کو چھوڑ دے، یا ماخذ محفوظ رکھنے والا ڈیزائن جو اس کے بجائے خود زائرین کا پتہ فارورڈ کرتا ہے، اس لیے وہ ماخذ دیکھیں جو peer واقعی دیکھتا ہے، نہ کہ آپ کے قاعدے والا۔

گیٹ وے کے اپنے لسنرز کو قاعدے سے باہر رکھیں

پورٹ میلان کو ہر TCP اور UDP منزل کو ڈھانپنے والے قاعدے سے بدلیں، اور گیٹ وے کا اپنا WireGuard ساکٹ اس کے اندر آ جاتا ہے۔ منزل کی ترجمانی مشین کے یہ فیصلہ کرنے سے پہلے ہوتی ہے کہ پیکٹ مقامی ہے، اس لیے UDP 51820 ہر peer کنکشن رکھنے والے عمل کی بجائے peer تک پہنچ سکتا ہے۔ قاعدہ کامیابی سے لوڈ ہوتا ہے اور سرنگ مر جاتی ہے، جو peer کی طرف سے پڑھنا مشکل ناکامی ہے۔

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

اگر وسیع فارورڈنگ واقعی ضروری ہو تو سب کچھ پکڑنے والے قاعدے سے پہلے کنٹرول پورٹس مخصوص کر لیں یا اشاعت کے لیے الگ عوامی پتہ استعمال کریں۔ دوسرا اختیار زیادہ صاف ہے کیونکہ کنٹرول پتہ اپنی پالیسی رکھتا ہے، لیکن فراہم کنندہ کو وہ پتہ دینا ہوگا؛ DNS ریکارڈ شامل کرنا پتہ مختص نہیں کرتا۔

وسیع TCP اور UDP فارورڈنگ بھی تمام پروٹوکول نہیں۔ ICMP، IPv6، path-MTU رائے اور بیرونی VPN نقل و حمل کو اپنی پالیسی درکار ہے، اور TCP و UDP کو ڈھانپنے والا قاعدہ اُن صورتوں کو طے شدہ چین پر چھوڑ دیتا ہے۔

قواعد لکھنے سے پہلے ماڈل چنیں

چار شکلیں گیٹ وے سے ہونے والی زیادہ تر اشاعتوں کو ڈھانپتی ہیں، اور انتخاب اس پر منحصر ہے کہ آپ کتنی سروسز چلاتے ہیں اور کنٹرول طیارے میں کتنا خطرہ برداشت کر سکتے ہیں۔ نیچے دیا گیا جدول اُنہیں تنگ ترین سے وسیع ترین ترتیب میں رکھتا ہے۔

تنگ ماڈل سے شروع کریں چاہے بعد میں مزید سروسز کی توقع ہو۔ اس کا آڈٹ کرنا سب سے آسان ہے، اور تنگ قواعد کے مجموعے کو جائزہ شدہ سب کچھ پکڑنے والے قاعدے میں بدلنا یہ معلوم کرنے سے آسان ہے کہ وسیع قاعدے نے کون سا لسنر پکڑا۔ جو بھی ماڈل چنیں، قواعد فائر وال کے مالک کے پاس رکھیں۔ اُنہی چینز کو سنبھالنے والی UFW یا nftables ترتیب کے ساتھ iptables سطریں لاگو کرنا ایسی پالیسی دیتا ہے جو بوٹ ترتیب کے مطابق بدلتی ہے۔

اشاعت اور کنٹرول راستہ دونوں ثابت کریں

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

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