নিজেকে বাইরে আটকে না রেখে ফায়ারওয়াল পরিবর্তন পরীক্ষা করা
নিয়মটি প্রয়োগ করার আগে আপনার পুনরুদ্ধারের পথগুলো ক্রমে সাজান, তারপর বেঁচে যাওয়া সেশন নয়, বরং নতুন নীতি যাকে মূল্যায়ন করবে এমন একটি ফ্লো দিয়ে যাচাই করুন।
নিয়মটি প্রয়োগ হয়, আপনার কাছে থাকা টার্মিনালটি উত্তর দিতে থাকে, আর পরের লগইন প্রত্যাখ্যাত হয়। যে সংযোগটি আপনি বদলাচ্ছেন তার ওপর দিয়ে ফায়ারওয়াল পরিবর্তন পরীক্ষা করার পুরো কঠিনতাই ওই ফাঁকটুকু। সংযোগ ট্র্যাকিং একবার সিদ্ধান্ত নেয় এবং তারপর দেখা বন্ধ করে দেয়, তাই প্রতিষ্ঠিত ফ্লোই হলো সেই একমাত্র প্রোব যা নতুন নীতি দেখতে পায় না। এরপর তিনটি ফেরার পথ তুলনা করা হবে, তারপর ঠিক করা হবে কোন ক্রমে নিয়মগুলো বদলাতে ও যাচাই করতে হবে।
কেন বেঁচে যাওয়া সেশনটিই দুর্বলতম প্রমাণ
স্টেটফুল ফায়ারওয়াল একটি ফ্লোর প্রথম প্যাকেট মূল্যায়ন করে এবং এন্ট্রিটি যতদিন থাকে ততদিন সেই রায় ধরে রাখে। পরে যোগ করা নিয়মগুলো পরবর্তীতে শুরু হওয়া ফ্লোগুলোর ওপর প্রযোজ্য, তাই আপনি যে উইন্ডোতে টাইপ করছেন সেটি ব্যবহারযোগ্য থাকে, অথচ বাকি সবাই প্রত্যাখ্যাত হয়। ওটি থেকে আপনি যা শেখেন তা কয়েক মিনিট আগে বলবৎ থাকা নীতিটিরই বর্ণনা। এমনকি সেই ফ্লোতে নেওয়া ক্যাপচারও শুধু একটা সিদ্ধান্ত দেখায় যা মেশিন আগেই নিয়েছে।
কর্মরত সেশনটিকে পরিমাপ নয়, বরং জরুরি বেরোনোর পথ হিসেবে দেখুন। প্রতিটি কাজের পরীক্ষাকে নতুন নিয়ম যে উৎসকে মূল্যায়ন করবে সেখান থেকে একটি নতুন ফ্লো খুলতে হবে, আর প্রথম পরীক্ষাটি হওয়া উচিত যেটি ব্যর্থ হলে সবচেয়ে বেশি কষ্ট দেবে। যখন ওই সেশনটিই ভেতরে যাওয়ার একমাত্র পথ, তখন পরিবর্তনটি করার জন্য প্রস্তুত নয়।
ফেরার তিনটি পথ, প্রতিটি কীসের ওপর নির্ভর করে সেই অনুসারে সাজানো
বিকল্পগুলোকে পরীক্ষাধীন ডিভাইসের ওপর কতটা নির্ভর করে তা দিয়ে সাজান, কারণ নিয়মটি ভুল প্রমাণিত হলে আপনি ঠিক এই ক্রমটিই ধরেন। যে কনসোল কখনও ফায়ারওয়ালের ভেতর দিয়ে যায় না সেটি স্বাধীন, অনুশীলন করা রোলব্যাক প্রায় তেমনই, আর ইতিমধ্যে খোলা সেশনটি নয়।
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
পরিবর্তনের আগে কনসোল দিয়ে লগইন করে প্রমাণ করুন যে এটি কাজ করে, কারণ যে আউট-অব-ব্যান্ড পথ আপনি কখনও ব্যবহার করেননি তা ফলব্যাক নয়, শুধু একটি নকশা। রোলব্যাক তার জায়গা পায় কেবল সেই প্ল্যাটফর্মে, সেই নিয়মসেট দিয়ে, অনুমোদিত প্রক্রিয়া অনুসরণ করে করা অনুশীলনের পরেই, লাইভ বক্সে তাৎক্ষণিক বুদ্ধি খাটানোর বদলে। ধাপগুলো লিখে রাখুন এবং অন্য কাউকে সেগুলো পড়ে শোনাতে বলুন। যদি ক্রমটি শেষ করতে আপনার স্মৃতির প্রয়োজন হয়, তবে এটি কোনো পরিকল্পনা নয়।
একটি পরিবর্তন, তারপর এমন একটি সংযোগ যা মূল্যায়ন করতে হবে
লাইভ নিয়মসেট এবং যে ফাইলটি সেটির মালিক তা সংরক্ষণ করুন, তারপর একটি মাত্র সংকীর্ণ সম্পাদনা করুন। প্রতি পরীক্ষায় একটি পরিবর্তন ফলাফলকে আরোপযোগ্য রাখে; একসঙ্গে দুটি করলে একটি সচল মেশিন হাতে থাকে কিন্তু কোন সম্পাদনা কাজটি করেছে তা জানা যায় না। যেখানে প্ল্যাটফর্ম লোড না করেই কনফিগারেশন বিশ্লেষণ করতে পারে, সেখানে সেটি আগে করুন, যাতে কোনো টাইপো এই অবস্থায় ধরা পড়ে যখন কিছুই ঝুঁকিতে নেই।
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
তারপর কনসোলটি যখন এখনও যুক্ত, তখন এমন একটি উৎস থেকে নতুন সেশন শুরু করুন যেটির ওপর পরিবর্তিত নিয়ম মিলবে। সফল হলে একবার পুনরাবৃত্তি করুন, কারণ প্রথম প্রচেষ্টাটি এমন এন্ট্রিতে গিয়ে পড়তে পারে যা টেবিলে আগেই ছিল। ব্যর্থ হলে আপনার ভেতরে যাওয়ার পথ ও ফিরিয়ে নেওয়ার সিদ্ধান্ত দুটোই থাকে, আর এটাই সবচেয়ে কম খরচের খারাপ ফল।
কাউন্টার, স্টেট আর ফাইল ভিন্ন ভিন্ন প্রশ্নের উত্তর দেয়
তিনটি পর্যবেক্ষণের প্রত্যেকটি এককভাবে বিশ্বাসযোগ্য দেখাতে পারে এবং অন্য দুটি সম্পর্কে আপনাকে বিভ্রান্ত করতে পারে। কাউন্টার দেখায় আপনি এইমাত্র যে ফ্লো তৈরি করেছেন সেটি সম্পাদিত নিয়মে পৌঁছেছে কি না। স্টেট টেবিল দেখায় মেশিন কোন ফ্লোগুলোকে ইতিমধ্যে প্রতিষ্ঠিত মনে করে, আর এভাবেই একটি নষ্ট নিয়মও সুস্থ দেখাতে পারে। সংরক্ষিত ফাইলটি দেখায় পরের রিলোডের পর ডিভাইসটি কী করবে, আর তা এখন চলমান নিয়মসেট যা করছে তার থেকে আলাদা হতে পারে।
ss -tn state established
কাউন্টারকে মোট নয়, বরং ডেল্টা হিসেবে পড়ুন, কারণ একমাত্র গুরুত্বপূর্ণ সংখ্যাটি হলো যেটি আপনার পরীক্ষা ফ্লো সরিয়েছে। যে নিয়মের কাউন্টার কখনও বাড়ে না সেটি মেলে না, কাগজে যতই সঠিক দেখাক। প্রত্যাখ্যানের ঘটনাটিও নিশ্চিত করুন: যে নীতি কখনও কিছু প্রত্যাখ্যান করেনি সে কখনও প্রমাণ করেনি যে আপনি যা ব্লক করতে চেয়েছিলেন তা প্রত্যাখ্যান করে। ডিপ্লয়মেন্ট যে পরিবারগুলোকেই আসলে বহন করে, তার প্রত্যেকটিতে একটি ইন্টারফেস নিয়ে কাজ করুন, কারণ v4 নিয়ম v6 ফ্লো সম্পর্কে কিছুই বলে না।
সংরক্ষিত নিয়মসেট থেকে পুনরুদ্ধার করুন, তারপর ফাইলটিকে মিলিয়ে নিন
পরিবর্তন ব্যর্থ হলে, লগইন আবার কাজ না করা পর্যন্ত অনুমতিদায়ক নিয়ম যোগ করার বদলে সংরক্ষিত নিয়মসেট লোড করুন। প্রতিটি অতিরিক্ত অনুমতি উপসর্গকে শান্ত করে এবং এমন একটি ফুটো রেখে যায় যা ঘটনাটি ও তার স্মৃতির চেয়ে বেশি দিন টিকে থাকে। পুনরুদ্ধার করুন, আবার সংযোগ করুন, তারপর ব্যর্থ তুলনাটি আপনি কী চেষ্টা করেছিলেন তার রেকর্ডের পাশে রাখুন।
সফল পরিবর্তনের পর ডিস্কের ফাইলটি যেন চলমান নিয়মসেটের বর্ণনা দেয়, এবং যাচাই করুন যে একটি রিলোড সেটি পুনরুৎপাদন করে। যে লাইভ নিয়মসেট নিজের কনফিগারেশন ফাইল থেকে বিচ্যুত হয়েছে সেটি পরের রিবুটের জন্য পাতা একটি ফাঁদ।