OpenVPN-এর pull-filter আপনার ইচ্ছার চেয়ে বেশি রুট মেলায়
pull-filter আপনার লেখাকে উপসর্গ হিসেবে পাঠানো অপশনগুলোর সঙ্গে মেলায়, তাই route আসলে route-gateway ও route-ipv6-ও ধরে ফেলে। আগে ক্রিয়াপদ দেখুন, তারপর রুট।
আপনি স্থানীয় ডিফল্ট রুট রাখতে একটি লাইন যোগ করেন, আর তারপর টানেল আর অভ্যন্তরীণ DNS সার্ভারে পৌঁছায় না। লাইনটি ছিল pull-filter ignore "route", যার মানে "এই রুট উপেক্ষা করো" নয়। এর মানে "যে পাঠানো অপশনের লেখা ওই পাঁচ অক্ষর দিয়ে শুরু হয়, সব বাদ দাও", আর সাধারণ সার্ভারে এর মধ্যে রুটগুলোর সঙ্গে route-gateway, route-metric ও route-ipv6-ও পড়ে। নিচের চেকলিস্টটাই আমি চালাই এমন কোনো প্রোফাইল ছোঁয়ার আগে, যা অন্য কাউকে ব্যবহার করতে হবে।
ফিল্টার শুধু পাঠানো অপশনেই কাজ করে
pull-filter কেবল টানেল প্রতিষ্ঠার পর সার্ভার যে অপশন-লাইনগুলো পাঠায় সেগুলোতেই কাজ করে, অন্য কিছুতেই নয়। আপনার স্থানীয় ফাইলে লেখা অপশন এতে প্রভাবিত হয় না, অ্যাপ্লিকেশন ট্রাফিকও নয়। আপনি যদি কোনো প্রসেসকে টানেল ব্যবহার থেকে থামানোর আশা করেন, তাহলে এটি সম্পূর্ণ ভুল যন্ত্র, আর কোনো ফিল্টার-সমাবেশই তা করবে না।
এই পরিধি কাজের, কারণ এর মানে আপনি সার্ভারের কনফিগারেশন অপরিবর্তিত রেখেও তার একটি অংশ স্থানীয়ভাবে প্রত্যাখ্যান করতে পারেন। এটি টিকিটে লেখার মতো একটি সীমাও: ফিল্টার বদলায় এই ক্লায়েন্ট কী গ্রহণ করে, সার্ভার কী দেয় তা নয়। একই প্রোফাইলের অন্য ব্যবহারকারীদের উপর এর কোনো প্রভাব নেই। অপশনটি না-বলা অন্য ক্লায়েন্টে গেলেও এটি টেকে না, যা এর উপর কোনো কর্মপ্রবাহ গড়ার আগে জানা দরকার।
প্যাটার্ন লেখার আগে সার্ভার আসলে কী পাঠায় তা নিশ্চিত করুন। বেশি ভার্বোসিটিতে ক্লায়েন্ট তার পাওয়া পাঠানো অপশন-স্ট্রিং প্রিন্ট করে, আর আপনি যে সঠিক লেখার সঙ্গে মেলাচ্ছেন তার একমাত্র সৎ উৎস এটিই:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpnপাঠানো লাইনটিকে কমা দিয়ে আলাদা করা অপশনের তালিকা হিসেবে পড়ুন, আর খেয়াল করুন অপশনের নাম ও তার আর্গুমেন্ট স্পেস দিয়ে আলাদা। আপনার ফিল্টার-লেখা এই স্রোতের সঙ্গে মেলানো হয়, তাই পরের ধাপে হোয়াইটস্পেস এত জরুরি।
মিলন একটি উপসর্গ, তাই হোয়াইটস্পেসই পুরো খেলা
তুলনাটি স্ট্রিং উপসর্গ, পার্স করা অপশন-নাম নয়। তাই "route" মেলে route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 ও route-metric 100-এর সঙ্গে। শেষে একটি স্পেস যোগ করলে তা সম্ভাব্য যে পরিবার বোঝাচ্ছেন তাতে সংকুচিত হয়, আর পুরো উপসর্গ যোগ করলে নির্দিষ্ট গন্তব্য পর্যন্ত সংকুচিত হয়।
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
শেষ সারিটাই স্প্লিট-টানেল কাজের সময় মানুষকে ধরে। নিজের রিজলভার রাখা বৈধ পছন্দ, আর এর মানে এখন প্রতিটি অভ্যন্তরীণ নাম এমন রিজলভারের উপর নির্ভর করে যা প্রাইভেট জোন দেখতে পায় না। এটি উৎপাদনে আবিষ্কার করার পার্শ্বপ্রতিক্রিয়া নয়, ইচ্ছাকৃতভাবে মেনে নেওয়ার পরিণতি।
উপসর্গ-মিলনের মানে আরও যে, নিয়ম পরে নীরবে বিস্তৃত হতে পারে। সার্ভার যখন আপনার লেখা দিয়ে শুরু হওয়া নতুন অপশন যোগ করে, তখন কেউ আপনার প্রোফাইল সম্পাদনা না করেই ফিল্টারটি তার উপর প্রয়োগ শুরু করে। এটাই সেই ব্যর্থতার ধরন যার বিরুদ্ধে নকশা করতে হয়, আর প্রশমন হলো অপশনের যতটা সম্ভব বেশি অংশ মেলানো, যতটা কম সম্ভব নয়।
তিনটি ক্রিয়াপদ, তিনটি আলাদা ফল
accept, ignore ও reject একই ধারণার তিনটি বানান নয়। মিলনের সময় ক্লায়েন্ট কী করে এবং কেউ তা জানতে পারে কি না—এ দুটোয় তারা আলাদা।
ignore মেলা অপশনটি নীরবে বাদ দেয়, যা ইচ্ছাকৃতভাবে বদলে দেওয়া সেটিংয়ের জন্য চান। reject এটি বাদ দেয় ও ক্লায়েন্টকে অভিযোগ করতে দেয়, যা চান যখন এর অনুপস্থিতি পরে আবিষ্কৃত হওয়ার বদলে লগে দেখা উচিত। accept হলো ইতিবাচক রূপ, ব্যবহৃত হয় যখন আলাদা আলাদা অপশন সরানোর বদলে অনুমোদন-তালিকা গড়েন।
যে ক্রিয়াপদই ব্যবহার করুন, ফিল্টারগুলো যেই ক্রমে আসে সেই ক্রমে প্রয়োগ হয়, তাই দুটি ওভারল্যাপিং নিয়ম ক্রম-নির্ভর ফল দেয় যা পর্যালোচনা করা খুব কঠিন। প্রতি উদ্দেশ্যে একটি নিয়ম রাখুন এবং প্রতিটিতে সবচেয়ে নির্দিষ্ট লেখাটি রাখুন। অনুমোদন-তালিকা দরকার হলে, একই কাজ করা ignore নিয়মের স্তূপের বদলে অল্প সংখ্যক accept নিয়মকে প্রাধান্য দিন। তখন পর্যালোচকেরা ফাইলটি উপর থেকে নিচে পড়ে ফল অনুমান করতে পারেন, আর এটাই একমাত্র পরীক্ষা যা স্কেল করে।
প্রয়োগ করা রুট ও রিজলভার দেখুন, প্রোফাইল নয়
ফাইলে সঠিক দেখানো একটি ফিল্টারও আপনাকে এমন টানেলে রেখে যেতে পারে যা কাজের মতো কিছু রাউট করে না। চলমান সিস্টেমে প্রভাব যাচাই করুন, যেখানে পাঠানো অপশন ইতিমধ্যে প্রয়োগ বা বাদ দেওয়া হয়েছে:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/প্রথম দুই লাইন আপনাকে বলে পাঠানো ডিফল্ট রুট এসেছে কি না এবং কতগুলো স্ট্যাটিক এন্ট্রি টিকে আছে। রিজলভার কোয়েরি দেখায় টানেল ইন্টারফেস আসলে কোন সার্ভার ব্যবহার করছে, আর সাধারণত সেখানেই DNS-এর চমক দেখা দেয়। শেষ লাইনটি ব্যবহারকারীর কাছে গুরুত্বপূর্ণ একমাত্র প্রশ্নের উত্তর দেয়।
সেখানে থাকতেই দুই দিক পরীক্ষা করুন। যে নিয়ম আপনার স্থানীয় ইন্টারনেট চালু রাখে কিন্তু অভ্যন্তরীণ নাম-সমাধান নীরবে ভাঙে, তা সামান্য পরীক্ষায় পাস করে প্রথম বাস্তব কাজে ব্যর্থ হয়, তাই একই পরীক্ষায় একটি অভ্যন্তরীণ রিসোর্স ও একটি পাবলিক সাইট রাখুন।
ব্যতিক্রমটি লিখে রাখুন, আর কে এর মালিক
ফিল্টার অপারেটরের নকশার একটি ব্যতিক্রম, তাই কারণ ও পর্যালোচনা-বিন্দুসহ এটি লিখে রাখুন। "স্থানীয় ডিফল্ট রাখতে পাঠানো রুট উপেক্ষা করে" পর্যালোচনাযোগ্য; প্রোফাইলে খালি একটি লাইন নয়, আর পরের ব্যক্তি সেটি মুছে দেবে বা অনুমানে বাড়াবে।
ভার্সনও এখানে গুরুত্বপূর্ণ। মিলনের আচরণ ও সঠিক গৃহীত সিনট্যাক্স OpenVPN 2.4, 2.5 ও 2.6 জুড়ে পরিমার্জিত হয়েছে, তাই পুরোনো সংস্করণ নিয়ে ফোরাম-পোস্টের বদলে আপনি যে বিল্ড পাঠান তার ম্যানুয়ালের সঙ্গে প্যাটার্নটি নিশ্চিত করুন। OpenVPN 2.6 ম্যানুয়াল অপশনটি ও তার মিলনের নিয়ম নথিভুক্ত করে।
শেষে, সার্ভার যে চালায় তার সঙ্গে ব্যতিক্রমটি একমত করুন। ইচ্ছাকৃত সার্ভার-নীতির বিরুদ্ধে যাওয়া ক্লায়েন্ট-পাশের ফিল্টার পরের অডিটের অপেক্ষায় থাকা একটি সাপোর্ট-ঘটনা, আর প্রোফাইল পাঠানোর আগে এটি মিটিয়ে ফেলা অনেক সস্তা—কারও রুটগুলো অনুপস্থিত লক্ষ করার পরে মিটানোর চেয়ে।