SSL VPN নাকি TLS র‍্যাপার? যে সীমা ব্যর্থ হয়েছে তা তুলনা করুন

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

আপনি যে সংযোগটি সত্যিই কনফিগার করেছেন তা দিয়ে শুরু করুন

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

নেটওয়ার্ক নকশার চুক্তি ভিন্ন, এবং তা রুট ও নীতিতে প্রকাশ পায়, পোর্ট জোড়ায় নয়।

এই দুটি বর্ণনার মধ্যে কোনটি আপনার চিত্রের সঙ্গে মেলে তা লক্ষ্য করুন। উত্তর যদি মাঝখানে সার্টিফিকেটসহ একটি পোর্ট ম্যাপিং হয়, তবে পণ্যের নাম VPN বললেও আপনার কাছে র‍্যাপার আছে। উত্তর যদি টানেল ইন্টারফেস ও রুট পরিবর্তন হয়, তবে 443-এ চললেও আপনার কাছে নেটওয়ার্ক নকশা আছে।

র‍্যাপারটি কীসের সঙ্গে সংযুক্ত হয় তা পরীক্ষা করুন

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

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

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

প্রথম কমান্ডটি দেখায় ক্লায়েন্টকে আসলে কোন সার্টিফিকেট দেওয়া হচ্ছে, আর দ্বিতীয়টি দেখায় হোস্টে কী শুনছে। অন্য কিছু পড়ার আগে সেই সার্টিফিকেটের নাম আপনার প্রত্যাশিত নামের সঙ্গে তুলনা করুন।

নকশাটি কোন ট্রাফিক বহন করে তা পরীক্ষা করুন

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

পণ্যের লেবেল বলে না আপনি এই মডেলগুলির কোনটি কিনেছেন, আর পোর্ট নম্বর আরও কম বলে।

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

ব্যর্থ সীমা পরীক্ষা করুন, লেবেল নয়

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

443 পোর্ট একটি রীতি যা মিডলবক্সের মধ্য দিয়ে TLS যেতে দেয়। এটি স্বেচ্ছাচারী ট্রাফিককে নীতি ডিভাইসের কাছে ওয়েব অনুরোধের মতো করে না।

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