OpenVPN পুনরায় চালু হলে IPv6 আউটগোয়িং বন্ধ হয়ে যায়: প্রিফিক্সের মালিকানা দেখুন
টানেল নতুন করে তৈরি হওয়ার পর IPv6 মরে যায়। কিছু পুনরায় চালু করার আগে নির্ধারণ করুন কে ডেলিগেট করা প্রিফিক্স, ক্লায়েন্ট ঠিকানা ও ফেরতের রুটের মালিক।
IPv6 যখন OpenVPN পুনরায় চালু হয় ঠিক তখনই ট্রাফিক পার করা বন্ধ করে দেয়, আর IPv4 কাজ করতে থাকে। টানেল ইন্টারফেসটি নতুন করে তৈরি হয়েছিল, এবং এর IPv6 অবস্থা পরিচালনা করা অন্য কিছু হয় ঠিকানাটি হারিয়েছে, নয়তো যে রুটটি প্রিফিক্সকে পৌঁছানোর উপযোগী করে তা হারিয়েছে। এখানে তিনটি আলাদা অবস্থার অংশ জড়িত, এবং প্রতিটির আলাদা মালিক আছে: প্রোভাইডারের ডেলিগেট করা প্রিফিক্স ও তার আয়ু, VPN ক্লায়েন্টদের দেওয়া ঠিকানা, এবং আপস্ট্রিম রুট যা ওই ক্লায়েন্ট প্রিফিক্সকে সার্ভারে ফেরত পাঠায়। যেকোনো ডেমন স্পর্শ করার আগে প্রতিটির মালিক চিহ্নিত করুন, কারণ ভুলটিকে পুনরায় চালু করলে সমস্যাটি এক দিনের জন্য লুকিয়ে যায় এবং পরের সংযোগে ফিরে আসে।
IPv6 অবস্থার তিনটি অংশ, তিন মালিক
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
টানেলের ভিতরে বৈশ্বিক পরিধির একটি ঠিকানা একা যথেষ্ট নয়। আপস্ট্রিম রাউটারগুলিকে এখনও সেই প্রিফিক্স VPN সার্ভারের দিকে ফেরত পাঠাতে হয়, এবং সার্ভারের কাছে তার একটি ঠিকানা আছে বলেই তারা তা করবে না।
এই কারণেই একটি পাবলিক /64 টানেল পুলে কপি করা ঝুঁকিপূর্ণ। সার্ভারে রাউট করা প্রিফিক্স আর আপস্ট্রিম যেটিকে on-link হিসেবে দেখে সেই প্রিফিক্স এক নয়, এবং প্রতিবেশী আবিষ্কার এই ফাঁক পূরণ করবে না।
কিছু বদলানোর আগে সার্ভারের অবস্থা পড়ুন
অবস্থাটি দুইবার ধারণ করুন, একবার IPv6 কাজ করার সময় আর একবার পুনরায় চালু করার পরে, তারপর তুলনা করুন। শুধু পড়ার ভিউই যথেষ্ট, এবং রক্ষণাবেক্ষণ উইন্ডোতে এতে কিছু খরচ হয় না:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingতিনটি নির্দিষ্ট পার্থক্য খুঁজুন: একটি রুট যা হারিয়ে গেছে, একটি ঠিকানা যা বাতিল বা অবৈধ আয়ুতে চলে গেছে, এবং একটি প্রিফিক্স যা পুনরায় ডেলিগেশনের পরে বদলেছে অথচ VPN কনফিগারেশন এখনও পুরোটির বিজ্ঞাপন দিচ্ছে।
যদি ঠিকানাটি হারিয়ে যায় কিন্তু প্রিফিক্স অপরিবর্তিত থাকে, তাহলে যে ডেমনটি তা বরাদ্দ করে সে ইন্টারফেস পরিচালনা করা বন্ধ করেছে। যদি প্রিফিক্স বদলায় কিন্তু ঠিকানাগুলি না বদলায়, ক্লায়েন্ট কনফিগারেশন পুরনো। দুটি ব্যর্থতা ব্রাউজার থেকে একই রকম দেখায় এবং এদের মধ্যে কিছুই মিল নেই।
dhcpcd কি টানেল পরিচালনা করবে তা ঠিক করুন
dhcpcd ইন্টারফেস আবিষ্কার করতে পারে এবং DHCPv6 প্রিফিক্সের অংশ ডাউনস্ট্রিম ইন্টারফেসে ডেলিগেট করতে পারে, আর তার কনফিগারেশন ডেলিগেশনের লক্ষ্যগুলি স্পষ্টভাবে নাম দিতে পারে। স্পষ্ট লক্ষ্য ছাড়া তার নথিভুক্ত আচরণ অন্য ইন্টারফেস জড়িত করতে পারে, এবং এভাবেই একটি টানেলে এমন ঠিকানা এসে পড়ে যা কেউ পরিকল্পনা করেনি।
দুটি শর্ত আপনাকে টানেলের স্ট্যাটিক অ্যাড্রেসিং OpenVPN-এর হাতে ছাড়ার দিকে ঠেলবে: সার্ভার তার কনফিগারেশনে নির্দিষ্ট ঠিকানা পাঠায়, এবং পুনঃসংযোগে টানেলের নাম বদলায়। দুটোই সত্যি হলে, ডেলিগেশন ডেমন থেকে টানেলটিকে সচেতনভাবে বাদ দিন, কেন তা বলা একটি মন্তব্যসহ।
যদি বরং টানেলে ডেলিগেশন ইচ্ছাকৃত হয়, প্রিফিক্স পরিবর্তনের ব্যবস্থাপনা বাস্তবায়ন করুন। এর মানে হলো ডেলিগেট করা প্রিফিক্স বা তার আয়ু বদলালে সাড়া দেওয়া, সার্ভারের বিজ্ঞাপিত ক্লায়েন্ট প্রিফিক্স হালনাগাদ করা, এবং রুটটি আবার যোগ করা। ওই নকশায় ইন্টারফেস বাদ দিলে নতুন প্রিফিক্স সম্পর্কে জানা একমাত্র উপাদানটিই সরে যায়।
dhcpcd পুনরায় চালু করলে অবস্থা নতুন করে তৈরি হয় বলে কিছু ঠিক হয়েছে বলে মনে হতে পারে, কিন্তু এটি আপনার মাথায় না থাকা ইন্টারফেসের জন্যও কনফিগারেশন নবায়ন বা প্রত্যাহার করে। ওই পুনরুদ্ধার এটিকে প্রতিটি VPN পুনরায় চালুর পরে আবশ্যক করে না। এটি প্রমাণ হিসেবে ব্যবহার করা কাউন্টারগুলিও শূন্য করে দেয়। আপনি সত্যিই যে ইন্টারফেস বদলেছেন তার লক্ষ্যযুক্ত রিলোডকে অগ্রাধিকার দিন।
IPv6 যাচাই করুন IPv4 NAT থেকে আলাদাভাবে
ফরওয়ার্ডিং সক্রিয় আছে এবং আপস্ট্রিম রুটটি প্রকৃত ক্লায়েন্ট প্রিফিক্সের দিকে আছে তা নিশ্চিত করুন, তারপর একটি নতুন অনুমোদিত IPv6 সংযোগ করুন। ক্লায়েন্টের নিজের IPv6 রুট টেবিলও দেখুন, কারণ পাবলিক ঠিকানা দেখানো কোনো ক্লায়েন্ট প্রমাণ করে না যে তার অনুরোধ টানেল ব্যবহার করেছে।
IPv4 মাস্করেডিং ভিন্ন একটি সমস্যার সমাধান করে: ব্যক্তিগত উৎসের জন্য ফেরতের পথ। প্রত্যাহৃত IPv6 প্রিফিক্সের জন্য এটি কিছুই করে না, এবং এটি যোগ করলে IPv6 ফিরে আসবে না।
মালিকানার রেকর্ড দিয়ে শেষ করুন: কোন উপাদান প্রিফিক্স ডেলিগেট করে, কোনটি ক্লায়েন্ট ঠিকানা বরাদ্দ করে, কোনটি ফেরতের রুট ধরে রাখে, এবং পুনঃসংযোগে প্রতিটির কী হয়। রানবুকে চারটি লাইন পরের মানুষটিকে যে ডেমনটি আসলে গুরুত্বপূর্ণ ছিল তা খুঁজতে তিনটি ডেমন পুনরায় চালু করা থেকে বাঁচায়।