گیٹ وے پر OpenVPN DNS: dnsmasq اور فائر وال کا دائرہ

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

سننے والا دو سمتوں والی مقامی سروس ہے

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

کلائنٹ کی بتائی ہوئی ٹائم آؤٹ اور گیٹ وے پر نظر آنے والی ٹائم آؤٹ ایک ہی خرابی نہیں ہیں۔

ٹنل کا پتہ باندھیں، ہر پتہ نہیں

اس کام کے لیے مخصوص dnsmasq کو واضح سننے کا پتہ، آغاز کے بعد ٹنل کے ظاہر ہونے کو برداشت کرنے والا بائنڈ موڈ، اور ایک واضح اپر اسٹریم درکار ہے۔ یہ سب سے چھوٹا ورژن ہے جو میں استعمال کرتا ہوں:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic الگ الگ پتوں کو باندھتا ہے اور tun0 بعد میں ظاہر ہونے پر سنبھالتا ہے، جو ایسے ہوسٹ پر اہم ہے جہاں VPN سروس دوبارہ شروع ہوتی ہے۔ loopback کی فہرست رکھنا عوامی سننے والا شامل کیے بغیر مقامی اوزار چلاتا رکھتا ہے۔ no-resolv ڈیمن کو ہوسٹ کی ریزالور ترتیب سے اپر اسٹریم ورثے میں لینے سے روکتا ہے، اور no-hosts اس مثال کو گیٹ وے کی hosts فائل شائع کرنے سے روکتا ہے۔ ان میں سے کوئی بھی اختیار کسی کو سروس سے کوئری کرنے کی اجازت نہیں دیتا۔

دوسرا ڈیمن شروع کرنے سے پہلے دیکھیں کہ آیا پورٹ 53 پر پہلے سے کوئی سننے والا موجود ہے، اور غلط ڈائریکٹری میں پڑی بھٹکی فائل کی بجائے ڈسٹری بیوشن کے کنفیگریشن مالک کو استعمال کریں۔

DNS ان پٹ کی اجازت دیں، ٹنل کی گزرگاہ کی نہیں

اسے کام کرانے والے فائر وال قواعد مقامی ان پٹ قواعد ہیں، جو ٹنل انٹرفیس، کلائنٹ پول، گیٹ وے پتہ اور پورٹ 53 تک محدود ہیں۔ دو قواعد، ہر پروٹوکول کے لیے ایک، کافی ہیں:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP کے ساتھ TCP پر بھی چلتا ہے، اس لیے صرف UDP والا قاعدہ بڑے جوابات کو ایسے ناکام ہونے دیتا ہے جو وقفے وقفے سے لگتا ہے۔ یہ ufw route اجازتیں نہیں ہیں، اور انہیں tun0 پر وسیع اجازت نہیں بننا چاہیے۔ ترتیب مواد جتنی ہی اہم ہے: tun0 سے سارا ان پٹ گراتا ہوا پہلے کا قاعدہ پھر بھی جیتتا ہے، اور آخری ڈراپ کے نیچے اجازت شامل کرنے سے کچھ نہیں بنتا۔

اگر گیٹ وے کا DNS اب ڈیزائن کا حصہ ہے، تو اس پہلی پالیسی پر جان بوجھ کر نظرثانی کریں اور وجہ درج کریں۔

اپر اسٹریم آدھا حصہ الگ راستہ ہے

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

جوابات کے کام کرنے کے لیے لامحدود ٹنل آؤٹ پٹ شامل نہ کریں؛ ٹریک کیے گئے جوابات کو اس کی ضرورت نہیں۔

اختیار پش کریں، پھر حوالگی چیک کریں

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

push "dhcp-option DNS 10.90.0.1"

کمانڈ لائن Linux کلائنٹ کو اپنے کنکشن مینیجر کا ریزالور انٹیگریشن درکار ہو سکتا ہے، اور منظم ڈیوائس کو اپ ڈیٹ شدہ مینجمنٹ پروفائل درکار ہو سکتا ہے۔ جڑنے کے بعد کلائنٹ پر فعال ریزالور کی تصدیق کریں، پش لاگو ہو گئی ماننے کی بجائے۔ جب دو میکانزم ایک ساتھ DNS سیٹ کرنے کی کوشش کرتے ہیں، تو ایسی دوڑ بنتی ہے جو ٹمٹماتے ریزولوشن کی صورت میں ظاہر ہوتی ہے۔

کلائنٹ کی ریزالور کنفیگریشن کے لیے ایک ہی مالک ہونا ہدف ہے، اور پش عام طور پر وہی مالک اس وقت ہوتی ہے جب کلائنٹ پلیٹ فارم متفق ہو۔

جو آپ نے واقعی بنایا ہے اسے آزمائیں

ایک نجی مکمل اہل نام اور ایک مجاز بیرونی نام براہ راست ٹنل پتے کے خلاف، UDP اور TCP دونوں پر کوئری کریں۔ پھر ایپ کے معمول کے تلاش راستے سے دہرائیں۔

اگر براہ راست کوئریاں کام کریں اور ایپ پھر بھی ناکام ہو، تو خرابی سرور پر نہیں، حوالگی میں ہے:

• کلائنٹ نے پش کیا گیا اختیار کبھی لاگو نہیں کیا۔
• بعد میں کوئی دوسرا ریزالور سیٹ ہوا اور دوڑ جیت گیا۔
• ایپ اپنی ریزالور لائبریری یا کیش شدہ جواب استعمال کرتی ہے۔

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