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 ডিভাইসকে এখনো এনক্যাপসুলেটেড ট্রান্সপোর্ট ও ফেরত ট্রাফিক বহন করতে হয়। রেজিস্ট্রি মান কোনো ফরওয়ার্ডিং নিয়ম তৈরি করে না, কোনো প্রস্তাব মেলায় না এবং কোনো পরিচয় যাচাই করে না, তাই পরিবর্তনের পর কাজ শুরু করা সংযোগ সম্পূর্ণ ভিন্ন কারণে কাজ করতে পারে। মূল টপোলজি দিয়ে মূল প্রোটোকল আবার পরীক্ষা করুন, তারপর লিখুন কোন ধাপ ব্যর্থ হয়েছিল এবং কেন মানটি তা সমাধান করার কথা ছিল। সেই বাক্যটিই ইন্টারনেট গুজবকে একটি রক্ষণযোগ্য কনফিগারেশনে বদলে দেয়।