Windows NAT-T رجسٹری ویلیو: پہلے ٹوپولوجی دیکھیں

Windows VPN کنکشن ناکام ہوتا ہے، تلاش ایک رجسٹری ویلیو واپس کرتی ہے اور وہ ویلیو ری بوٹ کے ساتھ ڈال دی جاتی ہے۔ یہ ترتیب کبھی کبھی کام کرتی ہے اور کبھی کچھ نہیں سمجھاتی۔ زیرِ بحث سیٹنگ سرور NAT ڈیوائس کے مقابلے میں کہاں ہے، اس ایک سوال کا جواب دیتی ہے، اور جب تک آپ نہ جان لیں کہ کون سا پروٹوکول کس مرحلے پر ناکام ہوا، یہ بے معنی ہے۔

ویلیو دراصل کیا منتخب کرتی ہے

AssumeUDPEncapsulationContextOnSendRule طے کرتا ہے کہ Windows کا IPsec نفاذ NAT ڈیوائس کے پیچھے موجود ساتھی کے ساتھ تعلقات قائم کرنے کی کوشش کرے گا یا نہیں۔ دستاویزی ڈیفالٹ 0 اس صورت کی اجازت نہیں دیتا، 1 اس وقت اجازت دیتا ہے جب سرور NAT کے پیچھے والا پہلو ہو، اور 2 دونوں سروں کے ترجمے کو محیط ہے۔ یہ ٹوپولوجی کے بارے میں بیانات ہیں—کون کہاں ہے۔

ترتیب کے طور پر پڑھیں تو اعداد بڑھتی ہوئی بھروسے مندی نہیں بلکہ بڑھتا ہوا ترجمہ بیان کرتے ہیں۔ ایسے نیٹ ورک پر 2 مقرر کرنا جہاں کچھ بھی ترجمہ نہیں ہوتا، کنکشن کو تیز یا زیادہ مستحکم نہیں کرتا، اور تصدیق کی ناکامی بھی درست نہیں کرتا۔ Microsoft کی L2TP/IPsec کے لیے NAT رہنمائی پالیسی اور اس کے تاریخی پلیٹ فارم سیاق و سباق کی دستاویز کرتی ہے۔ اس سیاق کو اس Windows ورژن اور کردار کے ساتھ موازنہ کریں جو آپ واقعی چلاتے ہیں، کیونکہ کئی ریلیزز سے بچ جانے والی دستاویز ہر موجودہ بلڈ کے بارے میں بیان نہیں ہے۔

عدد سے پہلے ٹوپولوجی ملائیں

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

یہ دعویٰ کہ موجودہ Windows Server ورژن سیدھے NAT traversal بند کے ساتھ آتے ہیں، کارروائی کے لیے بہت وسیع ہے۔ اہم یہ ہے کہ آپ کے سسٹم پر پالیسی کیا ہے، اس کے سامنے کی ٹوپولوجی کیا ہے اور کون سا تبادلہ ناکام ہوا—اسی ترتیب میں۔ اگر دونوں سروں کے پتے عوامی ہیں تو سیٹنگ آپ کا مسئلہ نہیں ہے۔ اس کے بجائے تجویز، سرٹیفکیٹ یا اکاؤنٹ دیکھیں، اور رجسٹری چھوڑ دیں۔

پہلے ناکامی کا مرحلہ دیکھیں

L2TP/IPsec کم از کم تین مختلف ناکامیاں پیدا کرتا ہے: ساتھی تک رسائی نہیں، IPsec تحفظ قائم نہیں ہو سکتا، اور سرنگ موجود ہونے کے بعد PPP صارف کی تصدیق مسترد کر دی جاتی ہے۔ مسترد شدہ اکاؤنٹ NAT پالیسی بدل کر درست نہیں ہوتا، اور تجاویز کی عدم مطابقت ری بوٹ سے درست نہیں ہوتی۔

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

HTTPS پر SSTP اور مقامی IKEv2 کے اپنے لاگز اور اپنے کنٹرول ہیں۔ صرف Windows پر چلنے کی وجہ سے ان میں سے کوئی NAT-traversal کیس نہیں بنتا۔

واپسی کے راستے کے ساتھ تبدیلی کریں

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

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