আপসযুক্ত হোস্টে কিল সুইচ কী কী ঢাকে তা পরীক্ষা করার উপায়

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

সার্ভার থেকে নয়, ক্লায়েন্ট থেকে শুরু করুন

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

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

প্রথম ধাপ: আপনি যে পথগুলি ঢাকা বলে মনে করেন সেখানে ব্লকটি নিশ্চিত করুন

ক্লায়েন্টে নয়, দূরের প্রান্তে টানেল নামিয়ে দিন, যাতে ক্লায়েন্ট এখনও মনে করে তার সংযুক্ত থাকা উচিত। তারপর একজন ব্যক্তি সত্যিই যা চেষ্টা করবে তা চেষ্টা করুন:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

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

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

দ্বিতীয় ধাপ: DNS এবং IPv6 কে আলাদা পথ হিসেবে পরীক্ষা করুন

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

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

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

ব্রাউজারগুলি বাইরে থেকে এটি পড়া আরও কঠিন করে, কারণ DNS over HTTPS এর জন্য কনফিগার করা ব্রাউজার একটি HTTPS অনুরোধের মাধ্যমে কোয়েরি সমাধান করে: কোয়েরিটি কেবল সেই প্রান্তে পোর্ট 443 যতটা আটকানো ততটাই আটকানো। যে হোস্টে নীতি স্থানীয় সাবনেট অনুমোদন করে, সেখানে সেই অনুরোধ এখনও LAN এর একটি রিজলভারে পৌঁছাতে পারে।

তৃতীয় ধাপ: নেটওয়ার্ক এক্সপোজারকে এন্ডপয়েন্ট এক্সপোজার থেকে আলাদা করুন

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

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

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

চতুর্থ ধাপ: আপনার পরীক্ষা যে দাবিকে সমর্থন করে তা লিখুন

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

দুটি সমস্যা আলাদা রাখুন এবং প্রত্যেকটিকে নিজস্ব নিয়ন্ত্রণ দিন:

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

পরবর্তী আপডেটের পরে ক্রমটি আবার চালান, কারণ কিল সুইচ এমন কনফিগারেশন যা সংস্করণের সঙ্গে চলে। পরীক্ষাই আপনার একমাত্র প্রমাণ যে আপনি যে আচরণের উপর নির্ভর করেন তা এখনও সেই আচরণই যা আপনি পান।