OpenVPN client-connect ব্যর্থতা: disconnect পরিষ্কার করা কি নিশ্চিত?
প্রত্যাখ্যাত ক্লায়েন্ট কোনো ফায়ারওয়াল নিয়ম বা লেখা রেকর্ড ফিরিয়ে নেয় না। কলব্যাক চুক্তির সঙ্গে আপনার হুককে নিজে যে রোলব্যাক করতে হবে তার তুলনা করুন।
যখন একটি client-connect স্ক্রিপ্ট অশূন্য কোডে শেষ হয়, OpenVPN ক্লায়েন্টকে প্রত্যাখ্যান করে, এবং অপারেটররা সাধারণত ধরে নেন সংশ্লিষ্ট client-disconnect স্ক্রিপ্ট সব গুছিয়ে দেবে। প্রায়ই তা কখনো চলে না, কারণ disconnect প্রক্রিয়া নির্ভর করে connect পর্যায় কী সম্পূর্ণ করতে পেরেছে তার উপর। প্রত্যাখ্যান ও রোলব্যাককে একটাই কৌশল ভাবাই ব্যর্থ লগইনকে ফাঁস হওয়া ফায়ারওয়াল নিয়ম বা এতিম রেকর্ডে পরিণত করে। এগুলো দুটি আলাদা দায়িত্ব, এবং কেবল একটি স্বয়ংক্রিয়। সার্ভারকে অবস্থা ফেলে যাওয়ার জন্য দোষ দেওয়ার আগে হুকের নিজের প্রস্থান পথটি পড়ুন।
অশূন্য প্রস্থান ক্লায়েন্টকে প্রত্যাখ্যান করে; আপনার কাজ ফিরিয়ে নেয় না
client-connect-এর প্রস্থান স্ট্যাটাস একটি ভর্তি সিদ্ধান্ত। শূন্য মানে ভর্তি, অন্য যেকোনো কিছু মানে ইনস্ট্যান্স সম্পূর্ণ প্রতিষ্ঠিত হওয়ার আগেই তা ভেঙে ফেলা। সেই চুক্তিতে কিছুই যাচাই করে না স্ক্রিপ্ট বাইরের জগতে ইতিমধ্যে কী করেছে। স্ক্রিপ্ট যদি iptables নিয়ম যোগ করে, একটি সারি লেখে বা একটি কাউন্টার বাড়ায়, সেই পরিবর্তনগুলো প্রত্যাখ্যানের পরেও টিকে থাকে।
একই অসমতা প্লাগইনেও প্রযোজ্য, যেখানে একটি ইনস্ট্যান্সের জন্য একাধিক connect ফাংশন চলতে পারে। পরের ব্যর্থতা আগের সফলতাকে পিছনের তারিখে বাতিল করে না, এবং আগের ফাংশনের জানার কোনো উপায় থাকে না যে সহোদর ফাংশনটি ব্যর্থ হয়েছে।
প্রত্যাখ্যান স্বয়ংক্রিয়, পরিষ্কার করা নয়
OpenVPN 2.6 ম্যানুয়াল client-disconnect প্রক্রিয়াকে আগের connect প্রক্রিয়া সফল হওয়ার সঙ্গে বেঁধে দেয়। একটি নথিভুক্ত ব্যতিক্রম ক্যাসকেড চেইন কভার করে: যদি একটি connect ধাপ ইতিমধ্যে সফলতা ফিরিয়ে দেয়, ইনস্ট্যান্স ভাঙার সময় সংশ্লিষ্ট disconnect ধাপগুলো তবুও চলে, যদিও পরের connect ধাপ ব্যর্থ হয়েছে। সেই ব্যতিক্রম সংকীর্ণ এবং কতগুলো কলব্যাক কনফিগার করা হয়েছে তার উপর নির্ভরশীল, তাই একটি shell স্ক্রিপ্ট পরীক্ষা করে চেইন সম্পর্কে আপনি কিছুই জানতে পারেন না।
নকশা করার আগে প্রকৃত কনফিগারেশনটি ম্যাপ করুন: কোন স্ক্রিপ্ট, কোন প্লাগইন এবং কোন ক্রমে চলে। নিচের সারণিতে অর্ধসম্পূর্ণ সেটআপ কী রেখে যায় তা তালিকাভুক্ত করা হয়েছে।
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
প্রতিটি সারি ক্লায়েন্টের জন্য একইভাবে এবং হোস্টের জন্য ভিন্নভাবে শেষ হয়। কোনটি ঘটেছে তা ক্লায়েন্ট বলতে পারে না, তাই ব্যর্থতার স্ট্যাটাস ফেরানোর আগে হুককে তার করা কাজ ফিরিয়ে নিতে হয়।
যে স্ক্রিপ্ট ব্যর্থ হয়েছে তার ভেতরেই ক্ষতিপূরণ দিন
শেয়ার করা অবস্থা স্পর্শ করার আগে যা সম্ভব যাচাই করুন: সার্টিফিকেটের ক্ষেত্র, ঠিকানার প্রাপ্যতা, ক্লায়েন্ট যে গ্রুপের অন্তর্গত। সবচেয়ে সস্তা প্রত্যাখ্যান হলো সেটি যা কোনো বরাদ্দের আগেই ঘটে। একবার সেটআপ একাধিক বাহ্যিক ক্রিয়াকলাপ জুড়ে গেলে, কোনগুলো সম্পন্ন হয়েছে তার রেকর্ড রাখুন এবং ব্যর্থতার স্ট্যাটাস ফেরানোর আগে উল্টো ক্রমে সেগুলো ফিরিয়ে নিন।
একটি নির্দিষ্ট উদাহরণ: স্ক্রিপ্টটি প্রতি-ক্লায়েন্ট ফায়ারওয়াল এন্ট্রি তৈরি করে, তারপর সেটি বর্ণনা করা অবস্থা-সারিটি লিখতে ব্যর্থ হয়। ব্যর্থ শাখাটির উচিত সদ্য তৈরি করা এন্ট্রিটি সরিয়ে ফেলা এবং তারপর অশূন্য কোডে প্রস্থান করা। এমন disconnect ইভেন্টের জন্য অপেক্ষা করা যা কখনো শিডিউল নাও হতে পারে—সেটাই একটি নিয়মকে তার উদ্দিষ্ট সেশনের চেয়ে বেশি বাঁচিয়ে রাখার উপায়।
ক্ষতিপূরণকে ইডেম্পোটেন্ট ও মালিকানাধীন করুন
পরিষ্কার করা দুইবার চালানো নিরাপদ হতে হবে এবং কী মুছতে পারে সে বিষয়ে নিখুঁত হতে হবে। আগের প্রয়াসের একটি দেরি করা ইভেন্ট কেবল এই কারণে নতুন সেশনের বরাদ্দ মুছে ফেলবে না যে দুটিই একটি সাধারণ নাম বা পুনর্ব্যবহৃত টানেল ঠিকানা ভাগ করে। নির্দিষ্ট হ্যান্ডেল বা অপারেশন আইডি সম্পদের সঙ্গে রেকর্ড করুন এবং নাম দিয়ে নয়, সেই কী দিয়ে মুছুন। ডেটাবেস লেনদেন কেবল ডেটাবেসের নিজের পরিবর্তনে সাহায্য করে; সেই সীমানার বাইরের ফায়ারওয়াল নিয়মের জন্য সুস্পষ্ট ক্ষতিপূরণ ধাপ দরকার।
ধরে নিন যে প্রক্রিয়াটি পরিবর্তন ও পরিষ্কারের মধ্যে মরে যেতে পারে, এবং একটি সমন্বয়কারী যোগ করুন যা নির্ধারিত সময়ে বাহ্যিক অবস্থাকে ভর্তি হওয়া ক্লায়েন্ট তালিকার সঙ্গে তুলনা করে।
যে তিনটি পথ সত্যিই আলাদা তা পরীক্ষা করুন
তিনটি ক্ষেত্রে অনুশীলন করুন: কিছু বরাদ্দ হওয়ার আগে প্রত্যাখ্যান, আংশিক বরাদ্দের পরে প্রত্যাখ্যান, এবং একটি স্বাভাবিক ভর্তি সেশন যা পরে শেষ হয়। এই তিনটি ভিন্ন লগ লাইন ও ভিন্ন অবশিষ্টাংশ তৈরি করে। প্রতিটির পরে বাহ্যিক অবস্থার উপর যাচাই করুন, কেবল ক্লায়েন্টের ব্যর্থতার বার্তার উপর নয়, কারণ তিনটির দুইটিতে ক্লায়েন্টের ব্যর্থতাই প্রত্যাশিত ফলাফল।
হুকের পর্যায়, প্রস্থান স্ট্যাটাস এবং কী বরাদ্দ বা মুক্তি পেয়েছে তা লগ করুন, শংসাপত্র বাদ দিয়ে। যে হুক লগ তার তৈরি সম্পদের নাম বলে, সেটাই ছয় মাস পরে ফাঁস হওয়া নিয়ম খুঁজে পাওয়া সম্ভব করে।