NAT-এর মধ্য দিয়ে L2TP/IPsec: আসলে কী ভাঙে এবং কেন

NAT যে L2TP/IPsec ভেঙে দেয়—এই দাবিটি অর্ধেক সত্য, তাই অকেজো। ঠিকানা অনুবাদ স্বাভাবিক, NAT ট্রাভার্সাল ঠিক তা টিকে থাকার জন্যই আছে, এবং প্রতিদিন কোটি ক্লায়েন্ট রাউটারের পেছন থেকে সংযোগ করে। যা ভাঙে তা হলো একটি নির্দিষ্ট বিনিময়ের একটি নির্দিষ্ট ধাপ: IKE কখনো উত্তর পায় না, এনক্যাপসুলেটেড টানেল এমন নীতি দ্বারা বাতিল হয় যা কেবল একটি প্রোটোকল অনুমোদন করে, অথবা টানেল নিষ্ক্রিয় থাকাকালীন ম্যাপিং মেয়াদোত্তীর্ণ হয়। আপনি কোন ধাপে আছেন তা জানলে সমাধান সাধারণত একটি নিয়ম বা একটি কিপঅ্যালাইভ, নতুন VPN ডিজাইন নয়।

মিথটাই ভুল প্রশ্ন

উপকারী প্রশ্ন হলো “NAT কি এটি ভাঙে” নয়, বরং “বিনিময়ের কোন অংশটি অনূদিত হচ্ছে, এবং যে ডিভাইসটি অনুবাদ করছে সে এটি নিয়ে কী করে”। L2TP/IPsec স্তরযুক্ত প্রোটোকল: IKE আলোচনা করে, ESP সুরক্ষা দেয়, আর L2TP সেই সুরক্ষার ভেতরে PPP বহন করে। ঠিকানা অনুবাদ প্রতিটি স্তরের সঙ্গে ভিন্নভাবে মিথস্ক্রিয়া করে, এবং ত্রুটির স্বাক্ষর আলাদা করা যায় যদি আপনি ত্রুটি ডায়ালগের বদলে আলোচনার ধাপটি দেখেন।

সফলভাবে ওয়েব ব্রাউজ করা একটি রাউটার কেবল প্রমাণ করে সোর্স পোর্ট অনুবাদসহ TCP কাজ করে। এটি UDP 500, UDP 4500 বা প্রোটোকল 50 সম্পর্কে কিছুই বলে না, আর এই স্থাপনা নির্ভর করে ঠিক এই তিনটির ওপর।

ধাপ 1: IKE-কে অন্তত উত্তর পেতেই হবে

প্রথম বিনিময় UDP 500-এ উত্তরদাতার কাছে যায়। কোনো উত্তর ফিরে না এলে বাকি কিছুই গুরুত্বপূর্ণ নয়: প্রি-শেয়ার্ড কী, প্রস্তাব ও শংসাপত্র সবই অপঠিত থেকে যায়। ক্লায়েন্টের টাইমআউট থেকে অনুমান না করে অনুরোধ ও উত্তরটি লক্ষ করুন:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

উত্তরহীন অনুরোধ সাধারণত বোঝায় একটি ফায়ারওয়াল বা আপস্ট্রিম ক্যারিয়ার প্যাকেটটি ফেলে দিচ্ছে, সার্ভার এটি প্রত্যাখ্যান করেনি। কোনো প্রস্তাব বা সার্টিফিকেট সমস্যার নাম উল্লেখ করা নোটিফাই পেলোডসহ উত্তর বোঝায় প্যাকেটগুলো পৌঁছেছে এবং আলোচনা কনটেন্টে ব্যর্থ হয়েছে, যা সম্পূর্ণ ভিন্ন একটি মেরামত।

যখন দুই পক্ষই অনুবাদের পেছনে থাকে, উৎসকে কেবল উত্তরদাতার কাছে পৌঁছাতে হয়, তাই বেশিরভাগ ক্লায়েন্ট-সাইড স্থাপনা ধাপ 1 থেকেই কাজ করে। সার্ভার-সাইড হোস্টিং হলো যেখানে ইনবাউন্ড সমস্যা শুরু হয়, আর এজন্যই দুই পরিস্থিতি কখনো এক হিসেবে আলোচনা করা উচিত নয়।

ধাপ 2: এনক্যাপসুলেশন বদলে দেয় ফায়ারওয়াল যা দেখে

ESP একটি IP প্রোটোকল, TCP বা UDP পোর্ট নয়, এবং সাধারণ পোর্ট ঠিকানা অনুবাদে পুনর্লিখনের জন্য কোনো পোর্ট ফিল্ড নেই। এজন্যই NAT ট্রাভার্সাল সুরক্ষিত পেলোডকে UDP 4500-এ নিয়ে যায়: এনক্যাপসুলেশন অনুবাদকারী ডিভাইসকে এমন কিছু দেয় যা সে অনুবাদ করতে জানে। এটি ঘটার পর, কেবল UDP 500-এর জন্য লেখা একটি ফায়ারওয়াল নিয়ম আলোচনা অনুমোদন করে টানেলটি ফেলে দেয়, ফলে বিভ্রান্তিকর ফল আসে যেখানে লগ সফল ধাপ 1 দেখায় আর কোনো ট্রাফিক দেখায় না।

NAT শনাক্ত হওয়ার পর IKE বিনিময় নিজেও UDP 4500-এ সরে যেতে পারে, যা তাদের অবাক করে যারা 500 অনুমোদন করেছেন আর কিছুই নয়। পথে দুই দিকেই দুই পোর্ট অনুমোদন করুন, এবং মনে রাখুন স্টেটফুল ফায়ারওয়াল কেবল ট্রাফিক দেখলেই প্রবাহ ধরে রাখতে পারে।

অনুবাদহীন পথে এবং যেখানে মধ্যবর্তী বক্স এটি অনুমোদনের জন্য কনফিগার করা আছে এমন পথে প্রোটোকল 50 এখনো গুরুত্বপূর্ণ। আপনি যদি বাদ দিয়ে নির্ণয় করেন, তবে নিয়ম স্তূপ করে যোগ না করে অনুকল্পটি বন্ধ করুন: 500, 4500 ও ESP অনুমোদন করুন, টানেল ওঠে কিনা নিশ্চিত করুন, তারপর যা অপ্রয়োজনীয় প্রমাণিত হয় তা সরান। যে নিয়ম কেউ ব্যাখ্যা করতে পারে না, সেটি এমন নিয়ম যা পরের বিভ্রাটের কারণ হলে কেউ সরাবে না। সংকোচনটি পরিবর্তন-রেকর্ডে যে ধাপটি ঠিক করেছে তার সঙ্গে লিখুন, যাতে পরের প্রকৌশলী একই আনুমানিক নিয়ম থেকে নয়, আপনার প্রমাণ থেকে শুরু করেন।

ধাপ 3: ম্যাপিং মেয়াদোত্তীর্ণ হয় আর টানেল মরে

অনুবাদকারী ডিভাইস যে প্রবাহগুলো এগিয়ে পাঠায় তার জন্য অবস্থা রাখে, আর সেই অবস্থার একটি আয়ু আছে। কেউ ব্যবহার না করলে L2TP/IPsec টানেল সামান্য ট্রাফিক বহন করে, তাই নিষ্ক্রিয় টানেল তার ম্যাপিংয়ের চেয়ে বেশি বাঁচতে পারে এবং ফেরত ট্রাফিক পাওয়া বন্ধ করতে পারে। ক্লায়েন্ট নিশ্চিত থাকে সে সংযুক্ত, সার্ভার কিছুই দেখে না, আর প্রথম উপসর্গ সাধারণত VPN ত্রুটি নয়, একটি অ্যাপ্লিকেশনের টাইমআউট।

ডেড পিয়ার ডিটেকশন ও NAT কিপঅ্যালাইভ এজন্যই আছে, এবং দুই প্রান্তকেই তা পাঠাতে রাজি থাকতে হবে। আপনার সার্ভার অনুবাদের পেছনে থাকলে Windows-এর দিকে প্রয়োজন হলো একটি নথিভুক্ত রেজিস্ট্রি সেটিং যা সার্ভারকে তার নিজের আউটবাউন্ড প্যাকেটের জন্য UDP এনক্যাপসুলেশন ধরে নিতে বাধ্য করে; এটি ছাড়া উত্তরদাতা ESP পাঠায় যা অনুবাদকারী ডিভাইস ফিরিয়ে ম্যাপ করতে পারে না। এটি সার্ভার কনফিগারেশনের বিষয়, ক্লায়েন্টের নয়।

WAN ঠিকানা পরিবর্তন ভিন্ন দিক থেকে একই ফল দেয়: নতুন ঠিকানার চারপাশে ম্যাপিং নতুন করে গড়া হয়, আর পুরোনো নিরাপত্তা সংযোগ এখন এমন টিউপলে নির্দেশ করে যা আর নেই। পুনঃসংযোগের আচরণ ক্লায়েন্ট বাস্তবায়নের, এজন্যই “রাউটার রিবুটের পর আবার সংযোগ” এক ক্লায়েন্টে কাজ করে আর অন্যটিতে হাতে টগল দরকার।

ক্যারিয়ার-গ্রেড NAT-এর পেছনে হোস্টিং ভিন্ন সমস্যা

আপনি যদি বাড়িতে L2TP/IPsec সার্ভার হোস্ট করে বাইরে থেকে পৌঁছাতে চান, প্রয়োজন হলো অনুরোধহীন ইনবাউন্ড পৌঁছানোযোগ্যতা, আর NAT ট্রাভার্সাল তা দেয় না। আপনার রাউটারের সামনে ক্যারিয়ার-গ্রেড NAT মানে এমন কোনো পোর্ট নেই যা ফরওয়ার্ড করে আপনাকে পৌঁছানোযোগ্য করবে, কারণ পাবলিক ঠিকানা ভাগ করা এবং ম্যাপিং কেবল আউটবাউন্ড।

কোনো IPsec পাস-থ্রু চেকবক্স এটি বদলায় না, আর কোনো ক্লায়েন্ট কনফিগারেশন এর ক্ষতিপূরণ দেয় না। সমর্থিত উত্তর হলো সত্যিই পৌঁছানোযোগ্য ঠিকানা, হোস্ট করা এন্ডপয়েন্ট, অথবা এমন স্থাপত্য যেখানে প্রতিটি অংশগ্রহণকারী আউটবাউন্ড সংযোগ করে। UDP এনক্যাপসুলেশন স্পেসিফিকেশন বিদ্যমান প্রবাহের জন্য অনুবাদ সমস্যা সমাধান করে; ক্যারিয়ার যেখানে সরবরাহ করে না সেখানে এটি ইনবাউন্ড পথ তৈরি করে না।

তাই অনুমান না করে নেটওয়ার্ক তুলনা করুন। একই ডিভাইস ও প্রোফাইল আরেকটি অনুমোদিত নেটওয়ার্কে নিয়ে যান এবং দেখুন সেখানে কোন ধাপ ব্যর্থ হয়। অন্যত্র কাজ করলে পার্থক্য পথে, আর এটি পুরো কনফিগারেশনের বদলে উপরের তিন ধাপে অনুসন্ধান সংকুচিত করে।