SoftEther SecureNAT: DHCP ও NAT দুটি আলাদা সিদ্ধান্ত

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

একটি চেকবক্সের পেছনে দুটি সেবা

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

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

সিদ্ধান্ত 1: ঠিকানা কে দেয়

ভার্চুয়াল DHCP চালু থাকলে ক্লায়েন্টরা আপনার কনফিগার করা পুলে লিজ পাওয়া উচিত, গেটওয়ে হিসেবে ভার্চুয়াল হোস্ট ইন্টারফেস এবং রিজলভার হিসেবে আপনি যা দিয়েছেন। ক্লায়েন্টের স্ট্যাটাস লেখা নয়, লিজটি দেখুন, কারণ “সংযুক্ত” বলতে টানেল বোঝায়, ঠিকানা বণ্টন নয়:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

অন্য কিছু ডিবাগ করার আগে দুটি ব্যর্থতার ধরন জানা দরকার। পূর্বের ডিজাইনের পড়ে থাকা স্ট্যাটিক ঠিকানা থাকা ক্লায়েন্ট সেটিই ধরে রাখবে এবং লিজ উপেক্ষা করবে, যা দেখে মনে হয় DHCP উত্তর দিতে অস্বীকার করছে। আর ব্রিজড সেগমেন্টে দ্বিতীয় DHCP উৎস একই ক্লায়েন্টদের জন্য প্রতিযোগিতা করবে, যার ফলে ঠিকানা মাঝেমধ্যে বদলায় এবং সাপোর্ট কিউ সমস্যাটি পুনরুৎপাদন করতে পারে না।

ওভারল্যাপিং পুলও এখানে পড়ে। ভার্চুয়াল DHCP পুল হোস্টের LAN সাবনেট বা অন্য হাবের পুলের সাথে ওভারল্যাপ করলে ক্লায়েন্ট এমন ঠিকানা পায় যা অস্পষ্টভাবে রুট হয়, আর পরের প্রতিটি পরীক্ষা অনির্ণায়ক হয়ে যায়।

সিদ্ধান্ত 2: ভার্চুয়াল গেটওয়ের ওপারে কে পাঠায়

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

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

হোস্টের নিজের পথ তৃতীয় একটি বিষয়

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

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

ঠিকানা পরিবারগুলোর নিজস্ব যাচাই দরকার। কাজ করা IPv4 DHCP উদাহরণ প্রমাণ করে না যে আপনার বিল্ডে প্রতিটি IPv6 সক্ষমতা আছে, তাই দ্বৈত স্ট্যাক আচরণের প্রতিশ্রুতি দেওয়ার আগে আপনি যে সংস্করণ সত্যিই চালান তার ম্যানুয়াল পড়ুন। ম্যানুয়ালের SecureNAT অংশটি বর্তমান রিলিজের ভার্চুয়াল NAT ও DHCP কার্যাবলি কভার করে।

প্রতিটি সিদ্ধান্ত নিজের পরীক্ষায় যাচাই করুন

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

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

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