Windows-এ OpenVPN অ্যাডাপ্টার বারবার ওঠানামা করছে? ডুপ্লিকেট IP পরীক্ষা করুন
Windows-এ বারবার ওঠানামা করা অ্যাডাপ্টার প্রায়ই ঠিকানার দ্বন্দ্ব, ড্রাইভারের বাগ নয়। ইভেন্ট 4198 ও 4199 পড়ুন, দ্বিতীয় মালিককে খুঁজুন, তারপর অনন্য ঠিকানা পিন করুন।
Windows-এ একটি OpenVPN অ্যাডাপ্টার যে ঠিকানা নেয়, তা ছেড়ে দেয় এবং প্রতি কয়েক সেকেন্ডে তা পুনরাবৃত্তি করে, সাধারণত DHCP বাগ নয়। অ্যাডাপ্টারকে এমন একটি ঠিকানা ব্যবহার করতে বলা হয় যার জন্য ইতিমধ্যে অন্য কিছু উত্তর দিচ্ছে, তাই Windows এটি অকেজো হিসেবে চিহ্নিত করে এবং ক্লায়েন্ট আবার শুরু করে। ক্লায়েন্ট লগ শান্ত থাকে কারণ দ্বন্দ্বটি তার নিচে, অপারেটিং সিস্টেমের নিজস্ব নেটওয়ার্ক স্ট্যাকের ভিতরে সমাধান হয়।
এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ টানেল কনফিগারেশনের দিকে লক্ষ্য করা প্রতিটি সমস্যা-সমাধান ধাপ সার্ভার দিকের ডুপ্লিকেট ঠিকানা মিস করবে।
ক্লায়েন্ট লগ নয়, Windows ইভেন্ট লগ দিয়ে শুরু করুন
Windows ঠিকানার দ্বন্দ্ব সিস্টেম লগে ইভেন্ট আইডি 4198 এবং 4199 দিয়ে নথিভুক্ত করে। প্রথমটি একটি ঠিকানার জন্য শনাক্ত হওয়া দ্বন্দ্ব জানায়, দ্বিতীয়টি জানায় যে একটি ইন্টারফেস তার কনফিগার করা ঠিকানা ব্যবহার করতে পারেনি। কোনোটিই OpenVPN উল্লেখ করে না, ঠিক সে কারণেই সেগুলো সহজে চোখ এড়িয়ে যায়।
সাম্প্রতিক ইভেন্টগুলো টেনে আনুন এবং তাদের টাইমস্ট্যাম্প অ্যাডাপ্টারের নবায়ন চক্রের সঙ্গে তুলনা করুন: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap। প্রতি পনেরো সেকেন্ডে একটি দ্বন্দ্ব এমন ক্লায়েন্টের সঙ্গে মেলে যে একই ঠিকানা এমন মালিকের বিরুদ্ধে আবার চেষ্টা করে যে তার জন্য উত্তর দিতে থাকে। সংযোগের সময়ে একক দ্বন্দ্ব বরং এককালীন সংঘর্ষের দিকে ইঙ্গিত করে। যেভাবেই হোক, পরের প্রশ্নটি হলো ঠিকানাটি আর কে ধরে রেখেছে।
তিনটি বিন্যাস দুটি হোস্টকে এক ঠিকানায় বসায়
সার্ভারকে জিজ্ঞাসা করুন সে মনে করে ঠিকানাটি কার কাছে আছে, তারপর নেটওয়ার্ককে জিজ্ঞাসা করুন এর জন্য কে উত্তর দেয়। grep -H ifconfig-push /etc/openvpn/ccd/* প্রতিটি পিন করা টানেল ঠিকানা এবং যে সার্টিফিকেটের সঙ্গে এটি যুক্ত তার তালিকা দেয়। ip -4 neigh show dev tap0 ব্রিজটি দ্বিতীয় স্তরে কী শিখেছে তা দেখায়। এই দুটি তালিকা তুলনা করলে বেশিরভাগ ডুপ্লিকেট এক মিনিটেরও কম সময়ে ধরা পড়ে।
তিনটি বিন্যাস প্রায় সবগুলোর ব্যাখ্যা দেয়: একটি client-config-dir এন্ট্রি দুটি সার্টিফিকেটের জন্য একটি ঠিকানা পিন করে, একটি ব্রিজকৃত tap সেগমেন্ট এমন একটি মেশিনকে ঠিকানা দেয় যা অন্য হোস্ট ইতিমধ্যে স্ট্যাটিকভাবে ধরে আছে, অথবা একটি পুরনো লিজ ফাইল এমন ঠিকানা ফিরিয়ে দেয় যা এখনও সংযুক্ত ক্লায়েন্ট নিজের বলে মনে করে। তৃতীয় ঘটনাটি সবচেয়ে ধূর্ত, কারণ ifconfig-pool-persist পরিচিত ক্লায়েন্টদের জন্য ইচ্ছাকৃতভাবে ঠিকানা পুনরায় ব্যবহার করে।
ঠিকানার জন্য দৌড়ানোর বদলে এটিকে অনন্য করুন
বুট ক্রম কেবল আজ কে জিতবে তা ঠিক করে, তাই রিস্টার্টের ক্রমভিত্তিক যেকোনো সমাধানকে সাময়িক হিসেবে ধরুন। প্রতিটি ক্লায়েন্টকে তার নিজের ifconfig-push লাইন দিন, অথবা এমন পরিসর থেকে স্ট্যাটিক ঠিকানা বরাদ্দ করুন যা কোনো ব্রিজ বা সার্ভার ইন্টারফেস স্পর্শ করে না। ক্লায়েন্ট তালিকায় ডুপ্লিকেট সাধারণ নামও যাচাই করুন, কারণ duplicate-cn দুটি সেশনকে একটি পরিচয় এবং তাই একটি পিন করা ঠিকানা ভাগ করতে দেয়। যদি ব্রিজকৃত ডিভাইসের সত্যিই একটি নির্দিষ্ট ঠিকানা দরকার হয়, তবে এটিকে তার নিজের সাবনেটে সরান বা সার্ভার যে জায়গায় নথিভুক্ত করে সেখান থেকে পুলে সংরক্ষিত রাখুন।
persist ফাইলটি কেবল তখনই মুছুন যখন আপনি জানেন এটি কোন লিজগুলো ধরে রেখেছে, নইলে পরের পুনঃসংযোগ আবার একই ঠিকানাগুলো দিয়ে দেবে।
সঠিক ক্রমে রিস্টার্ট করুন এবং প্রতি ঠিকানায় একজন মালিক নিশ্চিত করুন
পরিবর্তনটি আগে সার্ভারে প্রয়োগ করুন, তারপর ক্লায়েন্টগুলো পুনঃসংযোগ করুন, যাতে প্রতিটি অংশগ্রহণকারী সংশোধিত পুলের বিরুদ্ধে নিবন্ধিত হয়। ক্লায়েন্টগুলো আগে রিস্টার্ট করলে তারা এমন ঠিকানা ধরে থাকে যা সার্ভার এখনও দখল করা মনে করে। রিস্টার্টের পরে স্ট্যাটাস ফাইল পড়ুন এবং নিশ্চিত করুন প্রতিটি সাধারণ নাম একবার এক ঠিকানায় দেখা যায়। এক নামে দুটি এন্ট্রি মানে পুরনো সেশন কখনও বন্ধ হয়নি, পুল ভাঙা নয়।
যদি কোনো ক্লায়েন্ট এখনও তার ঠিকানা ধরে রাখতে না পারে, তবে দেখুন একই হোস্টের কোনো ব্রিজ ইন্টারফেস এটি বহন করছে কি না। যে ব্রিজ ভেন্ডর ডিভাইস থেকে ঠিকানা উত্তরাধিকারে পেয়েছে সেটি ARP-এ তার উত্তর দেবে, এমনকি যখন VPN সার্ভার ইতিমধ্যে সেই ঠিকানা একটি ক্লায়েন্টকে দিয়ে দিয়েছে।
টিকিট বন্ধ করার আগে একটি পূর্ণ নবায়ন চক্র ধরে পর্যবেক্ষণ করুন
একটি পরিষ্কার পাঠ কিছুই প্রমাণ করে না। অন্তত দশ মিনিট অ্যাডাপ্টারটি পর্যবেক্ষণ করুন এবং মাঝপথে একটি পুনঃসংযোগ জোর করুন: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState। ঠিকানাটি পুনঃসংযোগ টিকে থাকবে এবং পছন্দের অবস্থায় থাকবে।
তারপর প্রথম ধাপের ইভেন্ট কোয়েরিটি আবার চালান এবং নিশ্চিত করুন এটি নতুন কিছু ফেরত দেয় না। পুনঃসংযোগ জুড়ে শান্ত লগই প্রমাণ যে দ্বন্দ্ব চলে গেছে, অন্যদিকে এক সংযোগের পরে শান্ত লগ কেবল বোঝায় দৌড়টি এখনও ঘটেনি। শেষে, যে রিসোর্সের জন্য টানেলটি আছে তা পরীক্ষা করুন, কারণ যে ব্রিজ তার ঠিকানা হারিয়েছে সেটি ভেন্ডর পথ ভাঙতে পারে, যদিও VPN নিজে সুস্থ দেখায়।
পুলের পরিসর, প্রতিটি পিন করা ঠিকানা এবং এটি যার অধীনে সেই হোস্ট সার্ভারের নোটে লিখুন। তাহলে পরের সংঘর্ষটি ধরতে কয়েক মিনিট লাগবে, পুরো এক দুপুর লাগবে না।