কেন একটি Azure OpenVPN টানেল প্রায় প্রতি ষাট সেকেন্ডে ভেঙে পড়ে

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

কোনো টাইমার স্পর্শ করার আগে সেই লাইনটি পড়ুন।

কিংবদন্তি: পথের মধ্যে কিছু টানেল আটকাচ্ছে

যদি পোর্ট আটকানো থাকত, সংযোগ শুরুতে ব্যর্থ হতো এবং ব্যর্থই থাকত। পুনরাবৃত্ত চক্র মানে নিয়ন্ত্রণ বার্তা প্রবাহিত হচ্ছে, সেশন প্রতিষ্ঠিত হচ্ছে, এবং কথোপকথনের পরের দিকে কিছু একটা বারবার মেয়াদোত্তীর্ণ হচ্ছে। আটকানো নীরবতা তৈরি করে, আর এটি ছন্দ তৈরি করে।

ছন্দই দরকারি সূত্র। টাইমার এটি তৈরি করে; প্যাকেট হারানো খুব কমই করে।

টাইমারের আগে ডিসকানেক্টের কারণ পড়ুন

OpenVPN তার কারণের নাম দেয়, এবং প্রতিটি নাম ভিন্ন একটি সাবসিস্টেমের দিকে ইশারা করে। Session invalidated: KEEPALIVE_TIMEOUT হলো একটি টাইমার মেয়াদোত্তীর্ণ হওয়া, তাই দুই প্রান্তে ping ও ping-restart মান মিলিয়ে দেখুন। AUTH_FAILED হলো পরিচয়পত্র বা সার্টিফিকেটের অবস্থা, এবং কোনো টাইমার পরিবর্তন কাজে আসবে না। একটি TLS ত্রুটি মানে দুই পক্ষ কখনোই keepalive পর্যায়ে পৌঁছায়নি।

সংযোগের সময়, ডিসকানেক্টের সময় এবং বিরতিটি সেকেন্ড পর্যন্ত স্থির কি না তা লিখে রাখুন। এই একক পরিমাপ একটি কনফিগার করা সময়সূচিকে কাকতালীয় ঘটনা থেকে আলাদা করে।

স্থির বিরতি মানে টাইমার। সরে যাওয়া বিরতি বেশি সম্ভবত পথের সমস্যা বা স্থানচ্যুত সেশন।

দুটি keepalive টাইমার যা কখনো একমত হয়নি

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

দুটি মান একই নিয়ন্ত্রণ নয়। ping হলো ক্লায়েন্ট কত ঘন ঘন প্রতিধ্বনি পাঠায়, আর ping-restart হলো কিছু না শুনে কতক্ষণ অপেক্ষা করার পর সে টানেল ভেঙে ফেলে। যে প্রোফাইল সংক্ষিপ্ত ping-restart সেট করে আর যে গেটওয়ে ধীরে উত্তর দেয়, তারা প্রতিটি নীরব সময়ে পুনরায় চালু হবে, যা ঠিক এক মিনিটের চক্রের আকার।

ক্লায়েন্টের দিকে ন্যূনতম পরিবর্তন হলো প্রোফাইলের শীর্ষ স্তরে, প্রতিটি ইনলাইন ব্লকের বাইরে, টাইমারগুলিকে নিষ্ক্রিয় করা:

keepalive 0 0

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

সার্টিফিকেটের নাম আপনার পায়ের নিচ থেকে সরে যেতে পারে

Azure সার্টিফিকেট প্রমাণীকরণ নির্ভর করে ক্লায়েন্ট আজ গেটওয়ে যে নাম উপস্থাপন করে তাতে বিশ্বাস রাখে কি না। পুরোনো একটি ডাউনলোডে থাকা verify-x509-name লাইন এমন একটি নাম পিন করতে পারে যা গেটওয়ে পুনর্নির্মাণ বা সার্টিফিকেট নবায়ন এর মধ্যে বদলে ফেলেছে, আর অমিলটি স্পষ্ট ত্রুটি নয়, পুনঃসংযোগ চক্র হিসেবে দেখা দেয়। লাইনটি মুছে ফেললে সংযোগ ফিরে আসে, যা এটিকে ভালো রোগনির্ণয় এবং খারাপ স্থায়ী সমাধান করে, কারণ এটি যাচাইকরণও সরিয়ে দেয়। টানেল টিকে গেলে, গেটওয়ে যে নাম সত্যিই উপস্থাপন করে সেই নাম দিয়ে লাইনটি পুনরুদ্ধার করুন।

গেটওয়ে সম্পাদনার আগে একই মেশিনে দ্বিতীয় প্রজন্মের ক্লায়েন্ট পরীক্ষা করুন। যদি একটি ক্লায়েন্ট চক্রে পড়ে আর অন্যটি টেকে, তবে প্রোফাইল সমস্যা নয়।

কী বদলাবেন, আর কোন ক্রমে

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

তারপর কয়েক মিনিট ধরে অবিরাম ট্রাফিক চালিয়ে নিষ্ক্রিয় পথটি পরীক্ষা করুন। ট্রাফিক চলার সময় পড়া বন্ধ হলে, গুরুত্বপূর্ণ টাইমারটি পথের NAT ডিভাইস বা লোড ব্যালান্সারের, OpenVPN-এর নয়।

কেবল এই চারটি পরীক্ষার পরেই গেটওয়ে সেটিংস বদলানো উচিত।