VPN-এর পেছনে SaaS অ্যাডমিন এলাকা: কোন ঠিকানায় ভরসা করবেন?

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

টানেলের পরে অরিজিন আসলে কী পায়

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

curl -s https://ifconfig.me
dig +short admin.example.com

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

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

শুধু যে প্রক্সি ঠিকানাটি পুনর্লিখন করে তার উপর ভরসা করুন

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

প্রতিটি সুরক্ষিত অপারেশনে শর্তটি যুক্ত করুন

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

একই সীমাকে JSON API, এক্সপোর্ট, স্বাক্ষরিত ডাউনলোড URL এবং WebSocket হ্যান্ডশেকও কভার করতে হবে, কারণ এগুলোর কোনোটিরই আগে HTML পৃষ্ঠা অনুরোধ করার প্রয়োজন নেই। VPN চালু থাকার সময় তৈরি একটি ডাউনলোড লিংক পরে বৈধ থাকে, যদি না ডাউনলোড এন্ডপয়েন্ট আবার যাচাই করে। দীর্ঘস্থায়ী সেশনেও পুনর্মূল্যায়নের নিয়ম দরকার, নয়তো একটি প্রমাণীকৃত অনুরোধ স্থায়ী ছাড় হয়ে যায়। ডিফল্ট প্রত্যাখ্যানই একমাত্র সেটিং যা কর্মী বদলের পরেও টিকে থাকে।

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

আপনি এইমাত্র যে বাইপাসগুলো বন্ধ করলেন সেগুলো পরীক্ষা করুন

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

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