NAT VPN সার্ভারে নাকি রাউটারে? দুটোই কাজ করতে পারে

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

মিথ: ক্লায়েন্ট রুটই এক্সিট তৈরি করে

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

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

আগে উত্তরপথ আঁকুন

কোনো সেটিংয়ে হাত দেওয়ার আগে বাস্তব ঠিকানা দিয়ে পথটি লিখে ফেলুন এবং তার উপর দুটি সম্ভাব্য অনুবাদ বিন্দু চিহ্নিত করুন। এই ল্যাব 10.70.0.0/24 এর একটি VPN পুল ব্যবহার করে, যেখানে একটি ক্লায়েন্ট 10.70.0.37 এ, সার্ভারের LAN ঠিকানা 172.16.40.10, রাউটার 172.16.40.1 এ এবং পাবলিক এক্সিট 203.0.113.40 এ অবস্থিত।

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

বিকল্প A: VPN সার্ভারে অনুবাদ

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

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

বিকল্প B: পুলটি রাউটারে নিয়ে যাওয়া

দ্বিতীয় বিন্যাসে সার্ভার ক্লায়েন্টের আসল উৎস ঠিকানা ফরওয়ার্ড করে, আর রাউটার সেটি অনুবাদ করে। এটি প্রান্তে ক্লায়েন্ট পুল দৃশ্যমান রাখে, যা সাহায্য করে যদি রাউটারই ট্রাফিক নীতি, লগিং বা পরিদর্শনের জায়গা হয়। এর মানে রাউটারের 10.70.0.0/24 এর জন্য 172.16.40.10 এর দিকে নির্দেশ করা একটি ফেরত রুট দরকার, সাথে একটি ইন্টারনেট নীতি যা সত্যিই সেই প্রিফিক্স অন্তর্ভুক্ত করে; LAN সাবনেটের জন্য লেখা নিয়ম নীরবে পুল পর্যন্ত বিস্তৃত হয় না।

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

DNS, IPv6 এবং গ্রহণযোগ্যতা স্পষ্ট করুন

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

IPv6 ডিজাইনে নিজের অনুচ্ছেদ দরকার। কাজ করা IPv4 অনুবাদ IPv6 ক্লায়েন্টদের রুট, বৈধ পাবলিক উৎস বা টানেল পড়ে গেলে তাদের ব্লক করার নীতি আছে কি না তা নিয়ে কিছুই বলে না। এটি অকথিত রাখা মানে অর্ধেক ক্লায়েন্ট নীরবে গেটওয়ে এড়িয়ে যায় আর বাকি অর্ধেক কাজ করে।

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