مارک پر مبنی VPN فائر وال کی روکی ہوئی libvirt مہمان DNS درست کریں

ڈیفالٹ libvirt نیٹ ورک پر مہمان WireGuard انٹرفیس آنے تک نام بالکل درست حل کرتے ہیں، اور پھر ہر تلاش اسی جگہ رک جاتی ہے۔ dnsmasq اب بھی 192.168.122.1:53 پر سن رہا ہے، مہمان کے پاس اب بھی وہی پتہ حل کنندہ کے طور پر ہے، اور استفسار اب بھی پہنچتا ہے۔ جو بدلا وہ یہ ہے کہ میزبان کا اپنا اوپری استفسار، یا اس کا جواب، اب ایسے قاعدے سے گرا دیا جاتا ہے جو کسی بھی فلٹر زنجیر سے پہلے جانچا جاتا ہے جسے آپ ترمیم کرنے کا سوچیں گے۔ نکلنے کا راستہ یہ ہے وقت سے پہلے لگایا گیا نشان، ایسے کنکشن پر جسے جواب ورثے میں پاتا ہے۔

سرنگ اٹھتے ہی مہمانوں کا DNS چلا جاتا ہے

کچھ بھی بدلنے سے پہلے شکل کی تصدیق کریں۔ سرنگ نیچے کریں، مہمان سے dig @192.168.122.1 example.com چلائیں اور اسے جواب دیتے دیکھیں۔ سرنگ اوپر کریں، دہرائیں، اور اسے وقت ختم ہوتے دیکھیں۔ یہ دونوں نتائج ایک ہی قدم میں خراب libvirt نیٹ ورک، غلط حل کنندہ پتہ اور مردہ dnsmasq کو خارج کر دیتے ہیں۔

پھر میزبان کی طرف دیکھیں۔ اگر dnsmasq استفسار اور اس کی اوپری فارورڈنگ لاگ کرتا ہے تو پیکٹ پہنچ گیا ہے اور ناکامی باہر جانے میں ہے۔ اگر dnsmasq کچھ بھی لاگ نہیں کرتا تو مہمان کا استفسار اندر آتے ہی گرا دیا جاتا ہے اور استثنا اس ہک پر ہونا چاہیے جو اس مضمون کے نشان زد کردہ ہک سے مختلف ہے۔

بعد والی زنجیر میں accept قاعدہ کبھی کیوں نہیں چلتا

مارک پر مبنی VPN فائر وال آپ کے ماخذ پتے کو نہیں بلکہ پیکٹ نشان یا کنکشن نشان کو دیکھ کر فیصلہ کرتا ہے۔ جسمانی انٹرفیس پر متوقع نشان کے بغیر آنے والی ہر چیز مسترد ہوتی ہے، اور یہ مسترد ہونا اسی قواعد کے مجموعے میں ہوتا ہے جس کے پاس نشان کی جانچ ہے۔ ip saddr 192.168.122.0/24 accept سطر بعد والی کسی بھی زنجیر میں شامل کرنے پر بھی اس پیکٹ کے لیے کبھی نہیں دیکھی جاتی، اسی لیے ظاہر قاعدہ درست لگتا ہے مگر کچھ نہیں بدلتا۔

جب تک کچھ کام نہ کرے اسے پھیلانا دوسرا جال ہے۔ میزبان کے input راستے میں پورا libvirt سب نیٹ قبول کرنا مہمانوں کے لیے میزبان کی ہر سروس کھول دیتا ہے، جبکہ اصل ضرورت ایک ہی پورٹ کی ہے۔

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

VPN جدول کے دیکھنے سے پہلے استفسار نشان زد کریں

استثنا کو اس کے اپنے جدول میں رکھیں تاکہ بعد والا قاری VPN قواعد تجزیہ کیے بغیر اسے ڈھونڈ سکے:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle منفی ہے، جو اس زنجیر کو VPN پیکیج کی صفر ترجیح پر نصب کردہ عام فلٹر زنجیروں سے آگے رکھتا ہے۔ ہک کی ترتیب ہی قاعدے کو مؤثر بناتی ہے؛ VPN زنجیر کے بعد آنے والی زنجیر میں وہی قاعدہ محض آرائش ہے۔

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

سوراخ کو پورٹ 53 جتنا چوڑا ہی رکھیں

جیسا لکھا ہے، یہ libvirt سب نیٹ سے میزبان تک TCP یا UDP پورٹ 53 پر DNS کی اجازت دیتا ہے اور اس کے سوا کچھ نہیں۔ یہ مہمانوں کو سرنگ سے باہر انٹرنیٹ تک پہنچنے نہیں دیتا، اور میزبان کو مہمانوں کی طرف کنکشن کھولنے نہیں دیتا۔ اگر بعد میں کسی مہمان کو میزبان کی کوئی اور سروس درکار ہو تو اس قاعدے کو ڈھیلا کرنے کے بجائے اس منزل پورٹ کا نام لینے والا الگ قاعدہ شامل کریں۔

اس بارے میں ایماندار رہیں کہ آپ کیا بدل رہے ہیں۔ جو مہمان حل کنندہ تک پہنچ سکتا ہے وہ DNS استفسارات کے ذریعے من مانی ڈیٹا بھی سرنگ کر سکتا ہے، اور یہ استثنا VPN حد میں جان بوجھ کر چھیدا گیا سوراخ ہے نہ کہ یہ اعلان کہ مقامی نیٹ ورک قابل اعتماد ہے۔ ماخذ کو 192.168.122.0/24 تک محدود رکھنا اس سوراخ کو ہر دوسرے مقامی سب نیٹ سے دور رکھتا ہے، اور اگر خطرہ آپ کے لیے اہم ہو تو اس ماخذ پر استفسارات گننا سستا ہے۔

اسے ری بوٹ کے بعد بھی قائم رکھیں اور دونوں نصف ثابت کریں

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

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

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