যাচাই করুন স্প্লিট টানেল কাজ করে: একটি IP ফলাফল কোনো পরীক্ষা নয়
কোন প্রবাহগুলি টানেল ব্যবহার করবে এবং কোনগুলি সরাসরি থাকবে তা লিখুন, তারপর দুই দিক, DNS বিভাজন এবং ব্যর্থতার ক্ষেত্র যাচাই করুন।
একটি ব্রাউজার পৃষ্ঠা যা IP ঠিকানা দেখায় স্প্লিট টানেল সম্পর্কে প্রায় কিছুই প্রমাণ করে না। দৃশ্যমান ঠিকানা ভুল কারণে সঠিক হতে পারে, এবং বাদ দেওয়া প্রবাহ এটি দিয়ে কখনো পরীক্ষা হয় না। পরীক্ষার আগে প্রত্যাশিত ফলাফল লিখুন: কোন অ্যাপ্লিকেশন বা গন্তব্য টানেল ব্যবহার করবে, কোনটি সরাসরি থাকবে এবং টানেল ব্যর্থ হলে কী থামবে। সেই পরিকল্পনা ছাড়া যেকোনো বিশ্বাসযোগ্য সংখ্যা সাফল্যের মতো দেখায়।
মিথ: ঠিকানা অনুসন্ধান কভারেজ প্রমাণ করে
IP যাচাই একটি প্রশ্নের উত্তর দেয়: বাইরের বিশ্ব একটি মুহূর্তে একটি অ্যাপ্লিকেশন থেকে কী দেখে। এটি অভ্যন্তরীণ উপসর্গ, দ্বিতীয় ব্রাউজার প্রোফাইল বা এমন নাম সম্পর্কে কিছুই বলে না যা ব্যক্তিগতভাবে সমাধান হওয়া উচিত। এটি ব্যর্থতা সম্পর্কেও কিছুই বলে না, এবং এটিই স্প্লিট টানেল নকশার সেই অর্ধেক যা উৎপাদনে ভেঙে যায়।
ঠিকানা পৃষ্ঠা পথ, রিজলভার বা ব্যর্থতার নীতি দেখাতেও পারে না। এটিকে একটি পর্যবেক্ষণ হিসাবে ধরুন, রায় হিসাবে নয়।
অন্তর্ভুক্ত এবং বাদ দেওয়া প্রবাহ পরীক্ষা করুন
যে অ্যাপ্লিকেশনটি অন্তর্ভুক্ত হওয়া উচিত তা থেকে নিরীহ অনুরোধ পাঠান, অথবা যে উপসর্গটি টানেল দিয়ে যাওয়ার প্রত্যাশা করেন সেখানে, এবং উৎস, গন্তব্য, ঠিকানা পরিবার এবং পর্যবেক্ষিত পথ লিপিবদ্ধ করুন। সরাসরি থাকা প্রবাহের জন্যও একই করুন। বাদ দেওয়া দিকটিই মানুষ এড়িয়ে যায়, এবং এটিই একমাত্র প্রমাণ যে বিভাজন ইচ্ছাকৃত, দুর্ঘটনাজনিত নয়। একটি সহায়ক প্রক্রিয়া আলাদা নীতি পরিচয় বহন করতে পারে, তাই যে প্রক্রিয়া সকেটের মালিক সেখানে পরীক্ষা করুন।
flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct
তাই ভুল অ্যাপ্লিকেশনে পরীক্ষা নকশার উদ্দেশ্যের বিপরীত দেখাতে পারে। কোনো সিদ্ধান্তে পৌঁছানোর আগে দুই দিকের চারটি ক্ষেত্র লিখুন।
DNS এবং ব্যর্থতার ক্ষেত্র যোগ করুন
সিস্টেম রিজলভার এবং অ্যাপ যে রিজলভার ব্যবহার করে তা জিজ্ঞাসা করুন, তারপর সেই উত্তরগুলি সাইট যে প্রস্থান ঠিকানা জানায় তার সাথে তুলনা করুন। দুই স্তর ইচ্ছাকৃতভাবে ভিন্ন হতে পারে, এবং একটি ব্রাউজার অনুসন্ধান অপারেটিং সিস্টেমের নীতি পরীক্ষা করে না। একটি শেল তুলনাটিকে পুনরাবৃত্তিযোগ্য করে: টানেলটি ইচ্ছাকৃতভাবে ভাঙুন, তারপর এমন অনুরোধ করুন যা ব্রাউজার ক্যাশ করেনি; ক্যাশ থেকে দেওয়া পৃষ্ঠা ব্যাকআপ কোন দিকে গেছে সে সম্পর্কে কিছুই বলে না। যা সত্যিই ঘটেছে তা লিপিবদ্ধ করুন, নকশা যা পূর্বাভাস দিয়েছে তা নয়।
curl -s https://ifconfig.me
nslookup intranet.example
বন্ধভাবে ব্যর্থ হওয়া স্প্লিট টানেল এবং খোলাভাবে ব্যর্থ হওয়া টানেল একই রকম দেখায় যতক্ষণ না আপনি টানেলটি ইচ্ছাকৃতভাবে ভাঙেন। কোন আচরণ আপনি পর্যবেক্ষণ করেছেন তা লিপিবদ্ধ করুন, কোনটি প্রত্যাশা করেছিলেন তা নয়।
অবস্থা বদলানোর পরে পুনরাবৃত্তি করুন
পুনরায় সংযোগ, নেটওয়ার্ক পরিবর্তন এবং প্রাসঙ্গিক অ্যাপ্লিকেশন আপডেটের পরে একই পর্যবেক্ষণ পুনরাবৃত্তি করুন। সংরক্ষিত বাদ একটি পথ বা অ্যাপ্লিকেশন পরিচয়ের দিকে নির্দেশ করতে থাকতে পারে যা আর নেই, এবং নকশা নীরবে তার নথির সাথে মিলতে থেমে যায়। সেই তিনটি ঘটনাই সেই জায়গা যেখানে স্প্লিট টানেলগুলি সরে যায়, এবং প্রতিটিই আবার পরীক্ষা করা সস্তা। যে পরীক্ষা কেবল একবার স্থাপনার সময় চলে তা এমন কনফিগারেশন বর্ণনা করে যা আর নেই।
যদি কোনো ফলাফল আলাদা হয়, তবে একসাথে কয়েকটি সেটিং বদলানোর আগে নিয়মের মালিক এবং প্রক্রিয়াকরণের ধাপ খুঁজুন। পাঁচটি জিনিস বদলে একটি ফলাফল দেখা রোগনির্ণয় নয়, এটি নতুন কনফিগারেশন।
ফলাফল কী প্রতিষ্ঠা করা উচিত
পর্যবেক্ষণগুলিকে সেই নীতি এবং ক্লায়েন্ট সংস্করণের সাথে যুক্ত করুন যা আপনি সত্যিই পরীক্ষা করেছেন। লক্ষ্য হল দেখানো যে এই স্থাপনা তার দাবি করা কভারেজের সাথে মেলে, এটি নয় যে প্রতিটি ভবিষ্যতের অ্যাপ্লিকেশন ব্যক্তিগত হবে। এটি আরও সংকীর্ণ দাবি, এবং এটিই আপনি সত্যিই প্রমাণ দিয়ে সমর্থন করতে পারেন। দাবি, সংস্করণ এবং চার ক্ষেত্রের ফলাফল পরিবর্তন রেকর্ডে লিখুন।
তারপর পরবর্তী পর্যালোচক বলতে পারেন নকশা বদলেছে নাকি পরীক্ষা। স্প্লিট টানেল যাচাই হয় যখন দুই দিক, রিজলভারের বিভাজন এবং ব্যর্থতার আচরণ আপনার শুরুতে লেখার সাথে মেলে। একটি IP ফলাফল এর কোনোটিই যাচাই করে না।