macOS-এ OpenVPN TAP: ডিবাগ করার আগে ক্লায়েন্ট যাচাই করুন

পুরোনো প্রোফাইল একটি আধুনিক Mac-এ এসে পড়ে, ক্লায়েন্ট তা কোনো অভিযোগ ছাড়াই ইমপোর্ট করে, আর সংযোগটি কেটে যায় বা কখনও ট্রাফিক পার হয় না। সার্টিফিকেটে এক বিকেল নষ্ট করার আগে প্রোফাইলের ডিভাইস লাইনটি পড়ুন। যদি সেখানে dev tap লেখা থাকে, তাহলে আপনি ক্লায়েন্টের কাছে Ethernet-ধরনের ইন্টারফেস চাইছেন, আর macOS-এ বেশিরভাগ ক্ষেত্রে এই অনুরোধেই এসব সেশন শেষ হয়।

ধাপ 1: প্রোফাইল সত্যিই TAP চাইছে কি না নিশ্চিত করুন

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

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

ফাইলে যদি dev tap বা dev tap0 থাকে, তাহলে ক্লায়েন্টকে একটি TAP ইন্টারফেস বাস্তবায়ন করতে হবে। যদি dev tun থাকে, তাহলে এই নিবন্ধের বাকি অংশ প্রযোজ্য নয় এবং ব্যর্থতা অন্য জায়গায়।

ক্লায়েন্টের নাম ও সংস্করণ, macOS-এর সংস্করণ এবং প্রোফাইলটি কোথা থেকে এসেছে তা লিখে রাখুন। এই তিনটি তথ্যই ঠিক করে দেয় নিচের দুই পথের কোনটি আদৌ সম্ভব।

ধাপ 2: ডিভাইস মোড আসলে কী বদলায় তা জানুন

TUN ইন্টারফেস IP প্যাকেট বহন করে। ক্লায়েন্ট একটি IP সহকর্মীর ঠিকানায় পাঠানো প্যাকেট পড়ে ও লেখে, আর অপারেটিং সিস্টেম অন্য যেকোনো ইন্টারফেসের মতোই সেগুলো রুট করে।

TAP ইন্টারফেস Ethernet ফ্রেম বহন করে, যার মধ্যে ব্রডকাস্ট ও ARP-ও আছে। এটাই একটি ব্রিজড সার্ভারকে DHCP-র মাধ্যমে ঠিকানা বিতরণ করতে এবং ক্লায়েন্টকে চিৎকার করে ডিভাইস আবিষ্কার করতে দেয়, আর সেজন্যই কিছু পুরোনো নকশা এর উপর নির্ভর করে।

খরচটা হলো, TAP-এর জন্য এমন একটি ড্রাইভার দরকার যা সিস্টেমকে একটি Ethernet ইন্টারফেস দেখায়। অ্যাপল পুরোনো Mac TAP ড্রাইভারগুলো যে কার্নেল এক্সটেনশন মডেলের উপর নির্ভর করত তা অবসরে দিয়েছে, আর তার বিকল্প API এমন ক্লায়েন্টে জাদুকরভাবে হাজির হয় না যেগুলো কখনও এটি ব্যবহারের জন্য হালনাগাদ হয়নি। প্ল্যাটফর্মের সক্ষমতা আর বাজারে পাওয়া পণ্য দুটি আলাদা জিনিস।

ধাপ 3: সামঞ্জস্যপূর্ণ ক্লায়েন্ট আর মাইগ্রেশনের মধ্যে বেছে নিন

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

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

যা কাজ করে না তা হলো স্থানীয় কপিতে tap-কে tun করে দেওয়া আর আশা করা। সার্ভার তখনও ব্রিজ করছে, ক্লায়েন্ট এখন IP-তে কথা বলছে, আর কিছুই মিলছে না।

ধাপ 4: কাজ করা পরিষেবা বদলানোর আগে তথ্য সংগ্রহ করুন

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

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

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

ধাপ 5: দুই প্রান্ত থেকেই মাইগ্রেশন যাচাই করুন

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

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

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

তবু ব্যর্থ হলে প্রথম ত্রুটিটি পড়ুন

যে ক্লায়েন্ট ইন্টারফেস তৈরি করতে পারে না সে তার লগে তা বলে, সাধারণত প্রথম কয়েকটি লাইনেই। যে ক্লায়েন্ট এটি তৈরি করে এরপর প্রমাণীকরণে ব্যর্থ হয় সে ডিভাইসের প্রশ্নটি পুরোপুরি পার হয়ে গেছে, আর TAP-এর পিছনে ছোটা সেশন নষ্ট করা ছাড়া কিছু নয়।

প্রতিস্থাপন প্রমাণিত হওয়ার আগ পর্যন্ত মূল প্রোফাইল ও কাজ করা কনফিগারেশন রাখুন। ক্লায়েন্ট পরিবর্তন ফিরিয়ে নেওয়া দ্রুত; কেউ অনুমানের ভিত্তিতে ভেঙে ফেলা ব্রিজড নেটওয়ার্ক আবার গড়া তেমন নয়।