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

পরীক্ষাটি একটি সংকীর্ণ প্রশ্নের উত্তর দেয়: এই রূপান্তরের সময়, এই অ্যাপ্লিকেশনটি কি টানেলের বাইরের নেটওয়ার্কে পৌঁছাতে পারে? বাকি নীতিটি যুক্তিসঙ্গত কি না সে সম্পর্কে এটি কিছুই বলে না। পরিধিটি এত ছোট রাখুন, এবং ফলাফলটি লিখে রাখার যোগ্য।

ক্লায়েন্টে সুইচ ও তার পরিধি খুঁজুন

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

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

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

এমন ডিকয় গন্তব্য বাছুন যা টানেল ছাড়াও কাজ করে

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

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

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

নির্দিষ্ট ক্রমে রূপান্তরগুলো চালান

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

curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"
TransitionExpected with the block onFailure signature
Manual disconnectDecoy stops answering within secondsDecoy still returns 200
Server or path failureBlocked, with no exemption for the old endpointDirect access during the gap
Quit the appClient-dependent; record what happensBlock disappears with the process
Wi-Fi to EthernetBlock holds until the tunnel returnsTraffic flows mid-change

অ্যাপ বন্ধ করার সারিটি নিজের আলাদা চালনার যোগ্য, এমনকি স্বাভাবিক ব্যবহারে আপনি কখনো ক্লায়েন্ট বন্ধ না করলেও। যদি বেরোনোর সময় ব্লক ছেড়ে দেওয়া হয়, তবে একটি ক্র্যাশ বা জোরপূর্বক আপডেট আপনাকে একই ঝুঁকি দেয়, এবং এটি আপনার ধৈর্যের নয়, ডিপ্লয়মেন্টের বিষয়ে একটি তথ্য। Windows-এ সমতুল্য প্রোব হলো Resolve-DnsName decoy.example এবং curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/।

ভাঙা রিজলভার থেকে ব্লক আলাদা করুন

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

curl-এর প্রস্থান কোড ওই ঘটনাগুলো আলাদা রাখে: 6 হলো নাম-রিজলিউশন ব্যর্থতা, 7 মানে সংযোগ প্রত্যাখ্যাত হয়েছে, 28 হলো সময়সীমা। ব্লকড রুট সাধারণত একটি আক্ষরিক ঠিকানার বিরুদ্ধে সময়সীমা বা প্রত্যাখ্যান হিসেবে দেখা যায়। কেবল-DNS ব্লক 6 রেখে বাকি সব লুকায়। ক্যাশ করা পাতা বা ক্যাপটিভ পোর্টাল চোখকে বিভ্রান্ত করে, তাই প্রমাণ হলো প্রস্থান কোড, পর্দা নয়।

আক্ষরিক ঠিকানা দিয়ে IPv6-এ প্রোবটি পুনরাবৃত্তি করুন। যে ব্লক IPv4 কভার করে কিন্তু IPv6 উপেক্ষা করে তা এতটাই সাধারণ যে আপনার নোটে নিজের লাইন পাওয়ার যোগ্য, আর যে ক্লায়েন্ট টানেলের বাইরে IPv6 বন্ধ করে তার উভয় পরিবারেই পরিষ্কারভাবে ব্যর্থ হওয়া উচিত।

ফলাফল যে পরিধি কভার করে তা লিখুন

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

একটি চালনা একটি ক্লায়েন্ট বিল্ড, একটি প্রোফাইল, একটি রূপান্তর এবং একটি ঠিকানা পরিবার কভার করে। ফলাফলের সঙ্গে ওই চারটি লিখুন:

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

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

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