টানেল চালু আছে, তাহলে ব্যক্তিগত নামটি কেন এখনও ব্যর্থ হয়?

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

অনুরোধটি কোন রিজলভারে পৌঁছেছিল?

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

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

ক্লাউড নেটওয়ার্ক সত্যিই যে ঠিকানায় উত্তর দেয় সেটি ব্যবহার করুন

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

যদি সরাসরি অনুরোধ নেটওয়ার্কের ভেতর থেকে উত্তর দেয় কিন্তু টানেলের ওপারে না, তাহলে রিজলভার ঠিক আছে আর দুটি বিন্দুর মধ্যের পথ ঠিক নেই। সেই ফলাফল তদন্তকে ক্লায়েন্ট প্রোফাইলের বদলে রাউট, ফরওয়ার্ডিং ও অ্যাক্সেস নিয়মের দিকে সরিয়ে দেয়।

টানেল নামের জগৎ বহন করে না

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

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

সীমাগুলো ক্রমানুসারে হাঁটুন

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

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

শৃঙ্খলটি রাখুন যেখানে পরের মানুষ এটি খুঁজে পাবে

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

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