ddclient ভিপিএন এক্সিট প্রকাশ করে: ডিসকভারি সোর্স ঠিক করুন

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

নামটি কী পর্যন্ত পৌঁছানোর কথা তা নিশ্চিত করুন

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

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

ইন্টারফেস ঠিকানাগুলোও ব্যাখ্যা দাবি করে। হোম রাউটারের পেছনের ল্যাপটপ ঠিকানা পাবলিক WAN ঠিকানা নয়, এবং রাউটারের WAN ঠিকানাও ক্যারিয়ার-গ্রেড NAT-এর পেছনে থাকতে পারে, যেখানে তা প্রকাশ করে ইনবাউন্ড নাগাল পাওয়া যায় না।

কিছু বদলানোর আগে মানটি পুনরুৎপাদন করুন

দুটি পথ আলাদাভাবে পর্যবেক্ষণ করুন। টানেল চালু থাকলে প্রোব এক্সিট রিপোর্ট করে; টানেল বন্ধ থাকলে, বা প্রোবটি ফিজিক্যাল ইন্টারফেসে বাঁধা থাকলে, এটি হোম ঠিকানা রিপোর্ট করে: curl --interface eth0 https://ifconfig.me. এই দুটি উত্তর আলাদা হলে, আপনি আপডেটার স্পর্শ না করেই ত্রুটিটি পুনরুৎপাদন করেছেন।

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

ডিসকভারি বাছাই করা পথে পরিচালনা করুন

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

রাউটার-স্ট্যাটাস পথের জন্য নতুন ddclient রিলিজ usev4 ও fwv4 অপশন পরিবার ব্যবহার করে, সঙ্গে আশপাশের পৃষ্ঠা টেক্সটের জন্য ঐচ্ছিক স্কিপ প্যাটার্ন। আপনার ইনস্টল করা সংস্করণের README দেখুন, কারণ পুরোনো রিলিজ একই ধারণা use ও fw দিয়ে লেখে, আর ভুল রিলিজ থেকে কপি করা অপশন নাম চালুর সময় ব্যর্থ হয়।

আপনি ওয়েব ডিসকভারি রাখলে মনে রাখবেন, প্রোব রাউটিং আর আপডেট API কল রাউটিং দুটি আলাদা সিদ্ধান্ত। আপডেট কল রেকর্ডটি পৌঁছে দেয়; প্রোব ঠিক করে কোন মান পৌঁছাবে।

গোপন তথ্য ও সংস্করণ ঠিক রাখুন

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

ddclient README-এ ডিসকভারি পদ্ধতিগুলো ও তাদের অপশন নাম নথিভুক্ত আছে। একই রেকর্ডে IPv4 ও IPv6 ফলাফল মিশাবেন না, আর একটি রিলিজে থাকা অপশন অন্যটিতেও আছে বলে ধরে নেবেন না।

মান যাচাই করুন, তারপর নাগাল

লাইভ আপডেট অনুমোদনের আগে প্রস্তাবিত ঠিকানাটি অভীষ্ট এন্ডপয়েন্টের সঙ্গে মিলিয়ে দেখুন, তারপর একটি অনুমোদিত আপডেটের পরে authoritative DNS পরীক্ষা করুন এবং রিজলভার ক্যাশের হিসাব রাখুন। কম TTL অপেক্ষা কমায়; ভুল মানকে সঠিক করে না।

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