LAN হোস্টনেম VPN-এর ওপর কাজ করে না: সাফিক্স, mDNS নাকি জোন?

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

নামটি কোন প্রক্রিয়ার ওপর নির্ভর করে তা শনাক্ত করে শুরু করুন।

তিন ধরনের নাম যা ভিন্নভাবে আচরণ করে

fileserver-এর মতো একক-লেবেলের নাম সাধারণত রেজলভার যে DNS সার্চ সাফিক্স যোগ করে তার ওপর নির্ভর করে। ওই সাফিক্স প্রায়ই স্থানীয় DHCP লিজের সঙ্গে আসে, তাই VPN থেকে ঠিকানা পাওয়া কোনো দূরবর্তী ক্লায়েন্টের এটি জানার কোনো কারণ নেই। রুট যোগ করলে সাফিক্স পৌঁছায় না। সংক্ষিপ্ত নামটি কেবল নাম হিসেবে থাকাই বন্ধ করে দেয়, যদিও এর পেছনের ঠিকানাটি নাগালে আছে।

.local-এ শেষ হওয়া নাম সাধারণত স্থানীয় লিঙ্কে মাল্টিকাস্ট DNS দিয়ে সমাধান হয়, যেমন RFC 6762 বর্ণনা করে। মাল্টিকাস্ট রুটেড টানেল পেরোয় না, যদি না কিছু সচেতনভাবে সেতু বা প্রক্সি করে, তাই আপনি সেগমেন্ট ছাড়ার মুহূর্তেই নামটি সমাধান হওয়া বন্ধ করে দেয়।

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

রুট বদলানোর আগে রেজলভার পড়ুন

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

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

সঠিক নাম ক্লায়েন্টের কাছে আনুন

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

ফলাফল গেটওয়েতে নয়, ক্লায়েন্টে যাচাই করুন। সার্ভারে প্রয়োগ করা কোনো সেটিং যা কখনও ক্লায়েন্টে পৌঁছায় না, কিছুই বদলায় না।

সার্টিফিকেট পরিচয় অক্ষুণ্ন রাখুন

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

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