সার্ভার নাকি ক্লায়েন্ট: দ্বৈত ভূমিকার Pi-তে কোন OpenVPN ইউনিট

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

ইউনিটের নামটি যে ডিরেক্টরি লোড করে তার সঙ্গে মিলিয়ে নিন

Upstream 2.6 দুটি টেমপ্লেট ইউনিট দেয়, [email protected] এবং [email protected]। সার্ভার টেমপ্লেট /etc/openvpn/server-এ শুরু হয় এবং সেখান থেকে %i.conf লোড করে। ক্লায়েন্ট টেমপ্লেট /etc/openvpn/client-এ শুরু হয়। roaming নামের একটি ইনস্ট্যান্স একইসঙ্গে দুই জায়গায় থাকতে পারে, সার্ভার ও ক্লায়েন্ট হিসেবে, দুটি সম্পর্কহীন কনফিগারেশন নিয়ে এবং স্ট্রিং ছাড়া তাদের মধ্যে কোনো যোগসূত্র নেই।

ফাইলসিস্টেমের বদলে systemd-কে জিজ্ঞাসা করুন, কারণ প্যাকেজ নির্মাতারা এমন ড্রপ-ইন যোগ করেন যা কাজের ডিরেক্টরি বা বাইনারি যে আর্গুমেন্ট পায় তা বদলে দিতে পারে।

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

প্যাকেটের দিক দিয়ে সিদ্ধান্ত নিন, ইন্টারফেসের নাম দিয়ে নয়

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

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

তত্ত্ব করার আগে সকেট দেখুন। udp/1194-এ বাঁধা একটি সার্ভার লিসেনিং সকেট দেখায়। ক্লায়েন্টটি প্রোভাইডারের ঠিকানার সঙ্গে একটি অ্যাসোসিয়েশন দেখায় এবং শোনার মতো কিছুই দেখায় না।

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

একটি ইনস্ট্যান্সের ডিফল্ট রুট অন্যটির উত্তর কেড়ে নিতে পারে

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

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

টানেলের অবস্থার বদলে স্থানীয় সিদ্ধান্ত পরীক্ষা করুন, কারণ কার্নেল OpenVPN প্যাকেট দেখার আগেই উৎস ও ইন্টারফেস বেছে নেয়।

ip route get 203.0.113.44
ip rule show

একটি ভূমিকা পুনরায় চালু করুন এবং অন্যটি টিকে গেছে তা প্রমাণ করুন

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

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

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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