StrongSwan ایک DNS پتہ بھیجتا ہے جو Mac تک نہیں پہنچ سکتا

ہر چیز کام کرتی ہے جب تک کوئی MacBook نہ کھولے۔ ٹنل قائم ہو جاتی ہے، اندرونی میزبان پتے سے جواب دیتے ہیں، اور نام کا حل مر جاتا ہے۔ iPhone پر بھی وہی پروفائل ایسا ہی برتاؤ کرتا ہے، جبکہ Windows اور Linux کلائنٹس ٹھیک رہتے ہیں۔ بھیجا گیا DNS وصف عام طور پر مجرم ہوتا ہے: سرور اپنا عوامی انٹرفیس پتہ دیتا ہے، اور Apple کا IKEv2 کلائنٹ وہاں ٹنل کے ذریعے سوالات نہیں بھیجتا۔ حل کنندہ کو پول کے اندر لے جائیں اور علامت کلائنٹ کو چھوئے بغیر غائب ہو جاتی ہے۔

علامت بھیجے گئے پتے کی طرف اشارہ کرتی ہے

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

عوامی پتہ معمول کا انتخاب ہے کیونکہ یہی وہ پتہ ہے جو منتظم پہلے سے جانتا ہے۔ یہی واحد پتہ بھی ہے جو ٹنل کے اپنے سابقے سے باہر ہونے کی ضمانت رکھتا ہے، اور یہی خاصیت Apple کلائنٹس کو توڑتی ہے۔

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

حل کنندہ کو لیز کی حد سے الگ کریں

ٹنل کو پتوں کا ایسا منصوبہ دیں جس میں حل کنندہ پول کے اپنے ذیلی نیٹ کا رکن ہو، پھر اس پتے کو محفوظ رکھیں تاکہ کسی کلائنٹ کو کبھی لیز پر نہ ملے۔ اس مثال میں پول 10.180.7.0/24 ہے، سرور کے پاس 10.180.7.1 ہے، اور لیز 10.180.7.2 سے شروع ہوتی ہیں۔

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

پول کا سابقہ اور حل کنندہ ایک ہی ذیلی نیٹ بانٹتے ہیں، اس لیے وہ راستہ جو پہلے ہی ٹنل ٹریفک لے جاتا ہے سوالات بھی لے جاتا ہے۔ یہی واحد خاصیت اصلاح کو کلائنٹس کے درمیان منتقلی کے قابل بناتی ہے۔ swanctl کنفیگریشن میں وہی دو حقیقتیں کنکشن پر پول کی تعریف اور DNS ترتیب کے طور پر ظاہر ہوتی ہیں، ipsec.conf نحو میں نہیں۔

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

حل کنندہ کو باندھیں اور پورٹ 53 بند کریں

پتہ تفویض کرنا اس پر سننے کے مترادف نہیں۔ جو حل کنندہ صرف LAN پتے پر سنتا ہے وہ پول پتے پر بھیجے گئے سوالات مسترد یا نظر انداز کرے گا، اور کلائنٹ کو ایسا وقت ختم ہوتا نظر آئے گا جو روٹنگ کی ناکامی جیسا لگے۔

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

تصدیق کریں کہ کلائنٹ نے حقیقت میں کیا وصول کیا

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

براہ راست سوال ثابت کرتا ہے کہ حل کنندہ پول پتے پر ایسے میزبان سے جواب دیتا ہے جو اس تک پہنچ سکتا ہے۔ یہ ثابت نہیں کرتا کہ Mac نے وہی سرور چنا۔ macOS پر scutil --dns ہر دائرہ کار سروس کے مطابق حل کنندے فہرست کرتا ہے اور خلاصہ پینل سے زیادہ معلوماتی ہے؛ Windows پر Get-DnsClientServerAddress دکھاتا ہے کہ ٹنل اڈاپٹر نے بھیجا گیا قدر قبول کیا یا نہیں۔

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