দুই প্রান্তে একই সাবনেট: দূরবর্তী LAN-কে একটি মুক্ত রেঞ্জে ম্যাপ করুন

বাড়ি ও অফিস দুটোই 192.168.1.0/24 ব্যবহার করে, তাই 192.168.1.1-এ একটি অনুরোধের দুটি সম্ভাব্য উত্তর থাকে এবং ক্লায়েন্ট না জিজ্ঞেস করেই একটি বেছে নেয়। একটি চালু অফিস নেটওয়ার্ক পুনঃসংখ্যায়ন খুব কমই জনপ্রিয়, আর রাউটারের ঠিকানাগুলো প্রায়ই প্রিন্টার, ক্যামেরা ও নথিতে গেঁথে থাকে। ক্লায়েন্ট-সাইড ঠিকানা ম্যাপিং এর বদলে দূরবর্তী নেটওয়ার্ককে একটি মুক্ত রেঞ্জের অধীনে উপস্থাপন করতে পারে, এবং হোস্ট অংশ একই থাকতে পারে যাতে 192.168.1.20 10.203.41.20 হিসেবে দেখা যায়। ফাঁদ হলো কেবল কিছু ক্লায়েন্ট এটি বাস্তবায়ন করে, আর এটি ফেরার পথের জন্য কিছুই করে না।

একই হোস্টের দুই রূপ

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

বাড়ির স্থানীয় ডিভাইসগুলো নিজেদের 192.168.1.x ঠিকানা রাখে, আর এটাই এই অনুশীলনের উদ্দেশ্য। পাশের ঘরের প্রিন্টারটি নাগালে থাকে, অফিসটি এমন রেঞ্জের অধীনে দেখা যায় যা সংঘর্ষ করে না।

আর্গুমেন্টের ক্রমই পুরো কৌশল

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

রুটই ক্লায়েন্টের নতুন রেঞ্জের প্যাকেটগুলো টানেলে পাঠায়; অনুবাদটি যাওয়ার পথে গন্তব্য পুনর্লিখন করে। 192.168.1.20 থেকে উত্তরটি 10.203.41.20-এ ফিরিয়ে লেখা হয় যাতে ক্লায়েন্টের সকেট সামঞ্জস্যপূর্ণ থাকে। পূর্ণ-দৈর্ঘ্যের মাস্ক দিয়ে একক হোস্টও একইভাবে কাজ করে, যতক্ষণ রুট ও ম্যাপিং একই ঠিকানা বর্ণনা করে।

এটি ঠিকানা ম্যাপিং, পোর্ট ম্যাপিং নয়। একটি হোস্টে দুটি সেবা এটি দিয়ে আলাদা করা যায় না, আর যে প্রোটোকল তার পেলোডের ভিতরে IP ঠিকানা এমবেড করে সেটি এখনও আসল ঠিকানাগুলোই দেখবে।

ম্যাপিং ফেরার পথ তৈরি করে না

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

সার্ভার-সাইড নিয়মগুলোর উচিত অনুবাদের পরে সার্ভারে বিদ্যমান ঠিকানাগুলো বর্ণনা করা, ক্লায়েন্ট-দৃশ্যমান রেঞ্জ নয়। উপনামটি একটি অনুমোদন নিয়মে অনুলিপি করা একটি বিকেল নষ্ট করে, কারণ ওই দিকের কোনো প্যাকেটই এটি বহন করে না।

এমন উপনাম রেঞ্জ বেছে নিন যা ক্লায়েন্ট যে অন্য কিছুর দিকে রুট করে তার সঙ্গে সংঘর্ষ না করে: অন্য একটি VPN, একটি কন্টেইনার নেটওয়ার্ক, দ্বিতীয় অফিস। এখানে সংঘর্ষ মূল অস্পষ্টতাকে ভিন্ন সংখ্যার অধীনে ফিরিয়ে আনে এবং দেখা আরও কঠিন, কারণ ঠিকানাগুলো অপরিচিত দেখায়।

নাম ও পেলোড অনুবাদ পার হয়ে টিকে থাকে

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

রিডাইরেক্ট, এমবেডেড URL এবং যে অ্যাপ্লিকেশনগুলো নিজের ঠিকানা পেলোডে দেয় সেগুলো এমনভাবে ভেঙে যেতে পারে যা কোনো প্যাকেট ম্যাপিং ঠিক করতে পারে না। এগুলোকে অ্যাপ্লিকেশনের সমস্যা হিসেবে ধরুন এবং পুনঃসংখ্যায়ন অপ্রয়োজনীয় বলে প্রতিশ্রুতি দেওয়ার আগে শ্রমটা সেই অনুযায়ী নির্ধারণ করুন।

প্রতিশ্রুতির আগে তিনটি যাচাই

প্রথমে, ক্লায়েন্ট বাস্তবায়ন নিশ্চিত করুন। Community OpenVPN এই অপশনটি সমর্থন করে; OpenVPN 3 কোডবেস এটি অসমর্থিত বৈশিষ্ট্যের তালিকায় রাখে, তাই Connect-ধাঁচের ক্লায়েন্টে পাঠানো একটি প্রোফাইল এটিকে কেবল উপেক্ষা করতে পারে। যে নির্দেশ গৃহীত হয় কিন্তু কখনও প্রয়োগ হয় না তা ত্রুটির চেয়েও খারাপ, কারণ টানেলটি সুস্থ দেখায়।

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

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