OpenConnect কীভাবে লগইন কুকিকে টানেলে বদলায়?

OpenConnect দুটি আলাদা বিনিময়কে একটি স্বল্পস্থায়ী মান দিয়ে যুক্ত করে: ওয়েব লগইন এবং VPN টানেল। প্রথম বিনিময়টি সাধারণ HTTPS: শংসাপত্র, একটি SAML যাত্রা বা একটি টোকেন গেটওয়েতে যায়, আর উত্তরটি একটি প্রমাণীকরণ কুকি বহন করে। দ্বিতীয় বিনিময়টি সেই কুকিটি একই গেটওয়ের কাছে প্রমাণ হিসেবে উপস্থাপন করে যে ওয়েব পর্যায় ইতিমধ্যে ঘটেছে, এবং কেবল তখনই টানেল ওঠে।

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

ক্লায়েন্ট ও গেটওয়ে ক্রমে কী বিনিময় করে

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

দ্বিতীয় পর্যায় হলো গেটওয়ের VPN প্রান্তে সেই কুকি সংযুক্ত করে একটি CONNECT অনুরোধ। গেটওয়ে এটি যাচাই করে, একটি ঠিকানা দেয়, এবং ক্লায়েন্ট TLS-এর উপর CSTP শুরু করে, সেশন তৈরি হলে DTLS ঐচ্ছিক দ্রুততর ডেটা পথ হিসেবে কাজ করে। কেবল এই বিন্দুতেই টানেল প্যারামিটার, রুট, DNS সেটিংস এবং সেশনের ট্রাফিক কী প্রতিষ্ঠিত হয়। কুকি ক্লায়েন্টকে দরজা পার করিয়েছে; এটি কিছুই এনক্রিপ্ট করেনি।

এই ক্রমটিই ব্যাখ্যা করে কেন openconnect --authenticate আছে। এটি চালান, আর এটি ওয়েব পর্যায় সম্পন্ন করে, COOKIE, HOST, CONNECT_URL ও FINGERPRINT-এর মতো শেল চলকের ছোট একটি ব্লক ছাপে, তারপর কোনো টানেল তৈরির আগেই বেরিয়ে যায়। এরপর একটি র্যাপার স্ক্রিপ্ট সেই মানগুলো দিয়ে আসল সংযোগ শুরু করতে পারে, এবং হেডলেস বা দুই-কনটেইনার স্থাপনার জন্য ঠিক এই বিভাজনই দরকার।

কুকি সেশনের বাহক, চাবি নয়

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

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

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

কপি না রেখে কুকি হস্তান্তর

লিনাক্সে সবচেয়ে নিরাপদ যান্ত্রিক হস্তান্তর হলো স্ট্যান্ডার্ড ইনপুট। --cookie-on-stdin মানটি stdin থেকে পড়ে, তাই কুকি কখনো প্রক্রিয়ার আর্গুমেন্ট তালিকায় দেখা যায় না, যেখানে যেকোনো স্থানীয় ব্যবহারকারী ps দিয়ে তা পড়তে পারেন। এক প্রক্রিয়ায় প্রমাণীকরণ করে অন্য প্রক্রিয়ায় টানেল খাওয়ানো পাইপলাইন মানটি ফাইল বা পরিবেশ চলকে নয়, পাইপে রাখে।

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

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

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

দ্বিতীয় পর্যায়ে যাচাই ও মেয়াদোত্তীর্ণ

দ্বিতীয় পর্যায়কে এখনো সার্ভার যাচাই করতে হয়। --authenticate যে FINGERPRINT ছাপে তা pin-sha256: আকারে একটি সার্টিফিকেট পিন, আর --servercert দিয়ে তা টানেল আহ্বানে দিলে যাচাইটি সেই গেটওয়েতে নোঙর থাকে যার বিরুদ্ধে আপনি প্রমাণীকৃত হয়েছেন। স্ক্রিপ্ট সরল করতে সার্টিফিকেট যাচাই বন্ধ করা একমাত্র প্রমাণটি সরিয়ে দেয় যে কুকি অভীষ্ট হোস্টকে দেওয়া হচ্ছে।

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

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