OpenVPN-এ আগে থেকে তৈরি tun: দুটি মালিকানা মডেলের তুলনা

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

নাম মানেই যুক্ত হওয়া নয়

dev tun1 ওই নামের ইন্টারফেসটি OpenVPN-এর কাছে চায়, আর প্রচলিত ব্যবহারকারী-স্পেস বিল্ড সেটি খোলার চেষ্টা করবে। নামটি যদি সাধারণ tun বা tap প্যাটার্ন অনুসরণ না করে, তবে প্রোফাইলের একটি মিলতি dev-type-ও দরকার, কারণ স্ট্রিং থেকে ধরন কখনও অনুমান করা হয় না। TAP ডিভাইস ভিন্ন লেবেলের TUN ডিভাইস নয়: ভুলটি যুক্ত করলে হয় সরাসরি ব্যর্থ হয়, নয়তো এমন লিংক তৈরি হয় যা কেউ প্রত্যাশা করে না এমন ফ্রেম বহন করে। অন্য সবকিছুর আগে ধরনটি যাচাই করুন, কারণ পরের প্রতিটি যাচাই ধরে নেয় দুই পক্ষ এতে একমত। এরপর নিশ্চিত করুন প্রসেসটি ডিভাইসটি সত্যিই খুলতে পারে, কেবল দেখতে পায় তা নয়।

dev tun1
dev-type tun

নেটওয়ার্ক ইন্টারফেস ও /dev/net/tun ভিন্ন বস্তু: একটি নেমস্পেসের ভেতরের লিংক, অন্যটি হলো ক্যারেক্টার ডিভাইস যা ব্যবহারকারী-স্পেস প্রোগ্রাম যুক্ত হওয়ার জন্য ব্যবহার করে। Linux TUN/TAP ডকুমেন্টেশন ওই যুক্ত হওয়ার পথ এবং স্থায়ী ডিভাইসের মালিকানার নিয়ম বর্ণনা করে। যে root শেল ip link চালাতে পারে, তা কেবল প্রমাণ করে শেলের বিশেষাধিকার আছে, ডেমনের আছে তা নয়। ডিভাইস নোডের মালিকানা, সার্ভিসের সক্ষমতার সেট এবং যে ব্যবহারকারী হিসেবে এটি চলে — সবকিছু মিলতে হবে খোলাটি সফল হওয়ার আগে।

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

লিংক কে কনফিগার করে: দুটি মালিকানা মডেল

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

ifconfig-noexec কেবল ঠিকানা কভার করে: রাউটিং টেবিল অক্ষত থাকে, আর রুট কনফিগারেশন route-noexec-এর। দুটি নির্দেশকে আলাদা নিয়ন্ত্রণ ও আলাদা মালিক হিসেবে ধরুন, কারণ একটি সেট করে অন্যটি ধরে নেওয়াই আধা-কনফিগার্ড লিংকের সাধারণ উৎস। প্রতিটি স্তরে ঠিক একজন মালিক বাছুন, ঠিকানা এক জায়গায় আর রুট এক জায়গায়। নেটওয়ার্ক ম্যানেজার ও VPN হেল্পার দুজনেই ঠিকানা লিখলে, বিচ্ছিন্ন হওয়ার সময় অন্য পক্ষের নির্ভর করা অবস্থা মুছে যায়।

যে নেমস্পেস গুরুত্বপূর্ণ, সেখান থেকেই ডিভাইস দেখুন

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

ip -details link show dev tun1
ip tuntap show

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

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

দুই ধরনের স্থায়িত্ব

কার্নেল-স্থায়িত্ব ও persist-tun এমন জীবনকাল বোঝায় যা গুলিয়ে ফেলা সহজ আর ভুল করা ব্যয়বহুল। স্থায়ী ডিভাইস যেকোনো প্রসেস থেকে স্বাধীনভাবে থাকে, তাই থামানোও টিকে যায় এবং পরের শুরুতে পুনরায় ব্যবহার করা যায়। persist-tun একটিমাত্র OpenVPN প্রসেসের ভেতরে সমর্থিত নরম রিসেটজুড়ে সম্পদ ধরে রাখে, অনেক ছোট পরিধি। কোনোটিই প্রতিশ্রুতি দেয় না যে সার্ভিস থামালে রুট ও ঠিকানা জায়গায় থাকে, আর দৃশ্যমান থাকা ইন্টারফেস কার্যকর এনক্রিপ্টেড সেশনের প্রমাণ নয়।

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

কেবল স্টার্টআপ পরীক্ষা করলে কী ভাঙে

মালিকানার সমঝোতা প্রথম পরীক্ষায় পাস করে শেষটিতে ব্যর্থ হতে পারে, আর এজন্যই স্টার্টআপ একা দুর্বল পরীক্ষা। বরং দুটি রূপান্তর লক্ষ্য করুন: একটি নরম রিসেট, এবং পূর্ণ থামানো তারপর শুরু।

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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