OpenVPN push-peer-info: অ্যাক্সেস না দিয়ে ক্লায়েন্ট লেবেল করা

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

এটি কার্যকর পথের জন্য একটি রানবুক, কোনটি সত্যিই পৌঁছেছে তা দেখানো যাচাই ধাপ, এবং এমন রোলব্যাক যা অর্ধ-কনফিগার করা কোনো হুক রেখে যায় না। এখানে কিছুই নতুন সার্টিফিকেট, নতুন প্লাগইন বা প্রোটোকল সম্প্রসারণ দাবি করে না।

ভেরিয়েবলটি সেট করুন এবং পথটি চালু করুন

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

setenv UV_DEPLOY field-support
push-peer-info

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

একটি ব্যবহারিক পরীক্ষা এখানেই প্রযোজ্য, শেষে নয়: নিশ্চিত করুন যে নির্দেশটি ক্লায়েন্ট বাইনারিতে পৌঁছাচ্ছে এবং কোনো র্যাপার তা গিলে ফেলছে না। নিজেই কমান্ড লাইন তৈরিকারী একটি গ্রাফিক্যাল ক্লায়েন্ট, বা সংরক্ষিত প্রোফাইল পুনরায় লোড করা একটি ম্যানেজমেন্ট ইন্টারফেস, চিনতে না পারা লাইন ফেলে দিতে পারে। সার্ভার কিছু না দেখলে এটি প্রথম যে জায়গায় খুঁজবেন।

সার্ভার হুক থেকে ফিল্ডটি পড়ুন

সার্ভারের দিকে, প্রাপ্ত পিয়ার তথ্য যাচাই করে সংযোগ কর্মপ্রবাহের এনভায়রনমেন্টে ঢোকানো হয়, আর সেটিই আপনার নিজের কোনো প্রোটোকল কাজ ছাড়াই এটিকে একটি হুক থেকে পাঠযোগ্য করে তোলে। সার্ভারকে কন্ট্রোল চ্যানেল পার্স করতে বা আপনার জন্য কিছু সংরক্ষণ করতে হয় না; সংযোগ তৈরি হওয়ার সময় মানটি কেবল উপস্থিত থাকে। প্রমাণিত নামের পাশে লেবেলটি লিখে রাখা একটি ন্যূনতম client-connect স্ক্রিপ্ট এমন দেখায়।

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

লগ পার্স করার বদলে এনভায়রনমেন্টের মাধ্যমে ভেরিয়েবলটি পড়ুন, এবং সর্বদা একটি ডিফল্ট দিন। ${UV_DEPLOY:-unset} এমন ক্লায়েন্টদের জন্যও স্ক্রিপ্টটি চালু রাখে যারা কখনো ফিল্ডটি পাঠায় না, যা ধাপে ধাপে মোতায়েনের সময় স্বাভাবিক অবস্থা। নামটি খুঁজতে গোটা এনভায়রনমেন্ট লগে ফেলে দেবেন না; এতে লেবেলের চেয়ে অনেক বেশি থাকে, যার মধ্যে আপনি সংরক্ষণ করতে চাননি এমন মানও থাকে।

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

আসলে কী পৌঁছেছে তা যাচাই করুন

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

সংযোগটির জন্য সার্ভার লগও দেখুন। পিয়ার তথ্য সেখানে দেখা দিতে পারে, যা ডিবাগিংয়ের জন্য সুবিধাজনক এবং মানগুলি নীরস রাখার একটি কারণ: কারও নাম নয়, টিকিট নম্বর নয়, লগ-পাঠক দেখলে আপনার খারাপ লাগতে পারে এমন কিছু নয়।

লেবেলকে দাবি হিসেবে ধরুন, পরিচয় হিসেবে নয়

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

পরিচ্ছন্নভাবে ফিরিয়ে নিন

ফিচারটি সরানো মানে দুটি মুছে ফেলা এবং একটি যাচাই। ক্লায়েন্ট প্রোফাইল থেকে setenv ও push-peer-info লাইন দুটি বাদ দিন, তারপর সার্ভারে হুকটি ও তার লগ লক্ষ্য সরান বা নিষ্ক্রিয় করুন।

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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