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

আপনার হাতে যা এখনো আছে তা ঘুরে দেখুন

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

PathDepends onUsually fails when
Provider consoleAccount access and the provider's own APICredentials live in a wiki only reachable over the tunnel
Management subnetA second interface and its own routingThe bad change was a global route or firewall policy
Second tunnelA different listener, port and credentialsBoth listeners were changed in the same edit
Physical or local consoleBeing in the buildingNobody has been in the building for a year

তৃতীয় কলামটিকে বিমূর্ততা নয়, ব্যর্থতার তালিকা হিসেবে পড়ুন। এই পথগুলোর দুটি সাধারণত একই কারণে ব্যর্থ হয়। ছকটি ঠিক সেই জিনিস যা দিয়ে আপনি বিপর্যয় আপনাকে বুঝিয়ে দেওয়ার আগেই বিষয়টি লক্ষ্য করেন।

স্বাধীনতা নির্ভরতার প্রশ্ন

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

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

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

একটি নিয়ন্ত্রিত পরিবর্তনের জন্য দ্বিতীয় পথ ব্যবহার করুন

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

এটি করার সময় পুনরুদ্ধার সেশনটি খোলা রাখুন। দ্বিতীয় পথের পুরো মূল্য এই যে এটি আপনার বদলানো জিনিসটিই টিকে থাকে, তাই আগে বন্ধ করলে সেটিই সরিয়ে ফেলেন যা এটিকে কাজে লাগিয়েছিল।

মনে রাখা নয়, পুনরুদ্ধারের পথ থেকে যাচাই করুন

আসল যাচাই হলো স্বাভাবিক পথটি ফিরে আসে কি না, আর পুনরুদ্ধার সেশনেই আপনি এটি ক্রমানুসারে নিশ্চিত করেন:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

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

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

ইনভেন্টরি হালনাগাদ রাখুন

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

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

সম্পর্কিত নিবন্ধ