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

DNS যা বলে তা নয়, প্রোফাইল কী ডায়াল করে তা দেখুন

আপনি আসলে যে সংযোগ ব্যবহার করছেন সেটি খুলুন এবং remote লাইনটি পড়ুন। সেখানে থাকা সংখ্যাসূচক ঠিকানা কখনও হোস্টনেম আপডেট অনুসরণ করে না, রেকর্ড যতই সঠিক হোক।

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

দুটি ফাইল, একটি এন্ডপয়েন্ট — এখানে এটাই স্বাভাবিক পাওয়া।

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

ক্লায়েন্টের পরবর্তী সংযোগের চেষ্টাটি পড়ুন

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

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

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

আপনি কোন রিস্টার্ট করছেন তা জানুন

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

স্থায়িত্বের সেটিংসও গুরুত্বপূর্ণ, কারণ সেগুলি নতুন ঠিকানার পিছনে ছোটার জন্য নয়, যা প্রমাণিত হয়েছে তা ধরে রাখার জন্য তৈরি।

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

চারটি বিকল্প ও তাদের আলাদা কাজ

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

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

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

ক্লায়েন্টকে দোষ দেওয়ার আগে নতুন এন্ডপয়েন্ট নিশ্চিত করুন

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

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

আপনার প্রশাসনিক প্রবেশাধার বহনকারী টানেলটি রিস্টার্ট করার আগে সার্ভারে ঢোকার একটি আউট-অব-ব্যান্ড পথ রাখুন। এই একটি সতর্কতাই এই পরিস্থিতি থেকে জন্মানো বেশিরভাগ ঘটনা প্রতিরোধ করে।

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