মেইল VPN ছাড়াই সার্ভারে পৌঁছায়: নিয়ম কোথায় প্রয়োগ করবেন

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

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

উপসর্গটি Mac-এর মতো দেখায়, কিন্তু লিক সার্ভারও হতে পারে

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

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

সেই উত্তরই বলে দেয় পরিষেবাটি আদৌ VPN ক্লায়েন্টদের আলাদা করতে পারে কি না। যদি প্রতিটি ক্লায়েন্ট একই প্রক্সি ঠিকানা দিয়ে আসে, তাহলে উৎসভিত্তিক প্রবেশ অনুমতি তাদের আলাদা করতে পারে না, আর প্রয়োজনীয়তাটি প্রমাণীকরণ বা ক্লায়েন্ট প্রান্তে সরাতে হবে।

সার্ভার প্রবেশ: অ্যাপ নয়, উৎস প্রত্যাখ্যান করুন

হোস্ট বা নেটওয়ার্ক ফায়ারওয়াল প্রমাণীকরণ ও TLS অপরিবর্তিত রেখে মেইল লিসেনারকে অনুমোদিত উৎস পরিসরে সীমাবদ্ধ করতে পারে। দূরবর্তী ঠিকানা, সাবনেট বা পরিসর মেলানো নিয়ম-শর্তই সাধারণ নির্মাণ-ব্লক; সঠিক সিনট্যাক্স সার্ভারের ফায়ারওয়াল পণ্যের, মেইল অ্যাপের নয়।

প্রয়োজনীয়তাটি যখন «পরিষেবা সরাসরি ক্লায়েন্টদের সেবা দিতে পারবে না» তখন এটি সবচেয়ে শক্ত সীমানা। ব্যবহারকারী অন্য মেইল ক্লায়েন্ট ইনস্টল করলেও এটি টেকে, কারণ প্রত্যাখ্যান প্রমাণীকরণের আগেই ঘটে। এটি এমন Mac-ও সহ্য করে যা নিজের VPN নীতি উপেক্ষা করে।

এর সীমাটিও সমান গুরুত্বপূর্ণ। প্রত্যাখ্যাত সংযোগ প্রমাণ করে পরিষেবাটি সেশন প্রত্যাখ্যান করেছে; এটি প্রমাণ করে না যে Mac কোনো চেষ্টা করেনি। DNS রিজলিউশন, আগের লোড ব্যালেন্সারকে একটি TCP SYN এবং ব্যর্থতার পর পুনরায় চেষ্টা — সবই সার্ভারের নিয়মে পৌঁছানোর আগে ঘটতে পারে। প্রয়োজনীয়তাটি প্রবেশের বদলে চেষ্টার প্রকাশ নিয়ে হলে সার্ভার প্রবেশ নিয়ন্ত্রণের অর্ধেক মাত্র।

ক্লায়েন্ট প্রান্তে প্রয়োগ: শুধু টানেল নয়, চেষ্টাটি আটকান

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

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

দুই ঠিকানা-পরিবার ও বিদ্যমান সেশন ঢাকুন। যে নীতি নতুন IPv4 সংযোগ আটকায় কিন্তু IPv6 বা প্রতিষ্ঠিত সকেট অক্ষত রাখে, তা অনিয়মিত সিঙ্ক তৈরি করে যা এলোমেলো দেখায়। নেটওয়ার্ক পরিবর্তন ও স্লিপ চক্র একই পরীক্ষার অংশ।

অ্যাপ-স্তর ও গন্তব্য-স্তরের নিয়মের প্রভাবের পরিধি আলাদা

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

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

প্রয়োজনীয়তার ভাষা অনুযায়ী বেছে নিন। «এই কাজের অ্যাকাউন্টটি সরাসরি সংযুক্ত হতে পারবে না» গন্তব্য-পরিধির দিকে ইশারা করে। «এই Mac VPN-এর বাইরে মেইল চালাতে পারবে না» বিস্তৃত অ্যাপ-নিয়মকে ন্যায্য করে, যদি মালিক ব্যক্তিগত অ্যাকাউন্টের পার্শ্বপ্রতিক্রিয়া মেনে নেন।

প্রত্যাখ্যান ও অনুপস্থিতি আলাদাভাবে পরীক্ষা করুন

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

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

প্রয়োগের মালিক, সার্ভার প্রকৃতপক্ষে যে উৎস ঠিকানা দেখে এবং ব্যবহৃত পরীক্ষা-অ্যাকাউন্ট লিখে রাখুন। পরের নেটওয়ার্ক বা প্রক্সি পরিবর্তন সেই উৎসকে সরাতে পারে, আর পর্যবেক্ষিত মান উল্লেখ করা টীকা আরেক দফা অনুমানের চেয়ে দ্রুত যাচাই হয়।