pull-filter লেখা মেলায়, সাবনেট নয়: এটিকে প্রিফিক্স হিসেবে পড়ুন
ফিল্টার প্রতিটি পুশ করা অপশনের শুরু আপনার লেখার সঙ্গে তুলনা করে। অনুপস্থিত স্পেস, আগের একটি বিস্তৃত নিয়ম এবং ভুল অ্যাকশন ভিন্ন ভিন্ন ত্রুটি তৈরি করে।
উদ্দেশ্য ছিল একটি পুশ করা রুট বাদ দেওয়া। পরিবর্তনের পরে আরেকটি রাউটিং অপশন অনুপস্থিত থাকে, বা ক্লায়েন্ট লুপে আবার সংযোগ করে। উভয় ফল আসে ফিল্টারটিকে সাবনেট নিয়ম হিসেবে পড়া থেকে, অথচ এটি লেখা তুলনা করে। ক্লায়েন্ট দেখে একটি পুশ করা অপশন আপনার দেওয়া অক্ষর দিয়ে শুরু হয় কি না, এবং কোনো পর্যায়েই ঠিকানার যুক্তি জড়িত নয়।
ফিল্টার আসলে কী মেলায়
প্রতিটি পুশ করা অপশন একটি নাম ও তার আর্গুমেন্টের সমন্বয়ে গঠিত লাইন হিসেবে আসে। ফিল্টার আপনার অক্ষরগুলিকে সেই লাইনের শুরুতে তুলনা করে, কোনো ঠিকানা পার্স হওয়ার আগে এবং কোনো রুট ইনস্টল হওয়ার আগে। তাই একটি নামের জন্য লেখা নিয়ম ওই অক্ষর দিয়ে শুরু হওয়া প্রতিটি অপশন ধরে, কেবল যেটি আপনি দেখছিলেন সেটি নয়। এজন্যই একটি ফিল্টার আলাদাভাবে সঠিক দেখাতে পারে এবং তবুও অসম্পর্কিত কিছু সরিয়ে দিতে পারে।
নেটওয়ার্ক রেঞ্জের মতো দেখতে একটি স্ট্রিং তবুও কেবল অক্ষর। এটি কোনো প্রিফিক্স বেছে নেয় না, নেটওয়ার্ক বিটে কোনো গণনা করে না এবং কয়েকটি গন্তব্যের সেট প্রকাশ করতে পারে না। যখন এমন নিয়ম কাজ করছে মনে হয় আর পরে থেমে যায়, তখন পুশ করা লেখাটি সাধারণত আকৃতি বদলেছে।
একটি স্পেস মিলের সেট বদলে দেয়
একই অপশন নাম শেষে বিভাজক থাকা ও না থাকা অবস্থায় ভিন্ন লাইন বেছে নেয়। বিভাজক ছাড়া মিল খোলা থাকে, আর বিভাজক থাকলে আর্গুমেন্ট শুরুর আগে অপশন নামটিকে ঠিক সেখানেই শেষ হতে হয়।
pull-filter ignore "route"
pull-filter ignore "route "
খোলা রূপটি এমন অপশনও ধরে যেগুলি কেবল একই অক্ষর দিয়ে শুরু হয়, এবং এভাবেই অসম্পর্কিত রাউটিং আচরণ আপনি যে রুট বাদ দিতে চেয়েছিলেন তার সঙ্গে অদৃশ্য হয়ে যায়। ফিল্টার লেখার আগে লগ থেকে পুশ করা লাইনটি কপি করুন। সম্পাদিতটির পাশে প্রোফাইলের একটি অপরিবর্তিত কপি রাখুন, কারণ বিস্তৃত মিল ফেরানো মেমোরি থেকে নয়, ফাইল থেকে সহজ।
ক্রম ও অ্যাকশন ভিন্ন লক্ষণ তৈরি করে
নিয়মগুলি ক্রমে মূল্যায়িত হয় এবং প্রথম মিলই ফল নির্ধারণ করে, তাই আগে রাখা বিস্তৃত নিয়ম পরের প্রতিটি নির্দিষ্ট নিয়মকে অপ্রাপ্য করে তোলে। অ্যাকশনও ব্যর্থতা বদলায়: মিল উপেক্ষা করলে অপশনটি বাদ পড়ে ও সেশন চলতে থাকে, আর প্রত্যাখ্যান করলে ত্রুটি ওঠে যা সংযোগ আবার শুরু করে। তাই বারবার পুশ হওয়া একটি লাইন প্রত্যাখ্যানকারী অ্যাকশনের সঙ্গে মিলে পুনঃসংযোগ চক্র তৈরি করে। সেই চক্রকে নেটওয়ার্ক ত্রুটি হিসেবে পড়া সহজ, এবং যে লগ লাইনটি মিলে যাওয়া অপশনের নাম বলে সেটিই দুটিকে আলাদা করে।
| Action | Effect on the session | How it gets reported |
|---|---|---|
| Ignore | Option dropped, session continues | Something is missing afterwards |
| Reject | Error raised, connection restarts | The VPN keeps dropping |
কোন লাইন মিলেছিল এবং কোন অ্যাকশন চলেছিল তা লিখে রাখুন। বাদ পড়া রুট আর পুনরায় চালুর চক্রের মেরামত আলাদা, এবং নোটে দুটিই খোলা রেখে না দিয়ে কোনটি ঘটেছে তা বলা উচিত।
হোস্ট কী ইনস্টল করেছে তা দেখুন
আবার সংযোগের পরে প্রয়োগ করা রুটগুলি পড়ুন এবং আপনি যে গন্তব্য ধরে রাখতে চেয়েছিলেন ও যে গন্তব্য সরাতে চেয়েছিলেন সে দুটিই পরীক্ষা করুন। পুশ করা রুট বাদ দিলে কোনো বিকল্প আসে না, তাই অপ্রয়োজনীয় রুটটি চলে যাওয়ার সময় একটি রিসোর্স অন্য পথে অপ্রাপ্য হতে পারে। এখন যদি কোনো নাম অন্যত্র রিজলভ হয়, তবে পুশ করা রিজলভার অপশনটি একই বিস্তৃত প্রিফিক্সে ধরা পড়েছে কি না দেখুন। যে পরিবর্তন আপনার চালানো পরীক্ষায় পাস করে কিন্তু যে পরীক্ষা আপনি চেয়েছিলেন তাতে ব্যর্থ হয়, এখানে সেটিই স্বাভাবিক ফল।
টিকিটে সেই পার্থক্য লিখুন: যে রুট আপনি সরিয়েছেন, যে রুট রাখার আশা করেছিলেন, এবং টেবিল এখন যা দেখাচ্ছে। পরের পরিবর্তন সেই রেকর্ডের বিপরীতে বিচার করা হবে।
এটিকে বিশ্বাসের সীমা হিসেবে ধরবেন না
লেখার উপর একটি ফিল্টার হলো কনফিগারেশনের সুবিধা, আপনি যে সার্ভারকে বিশ্বাস করেন না তার বিরুদ্ধে নিয়ন্ত্রণ নয়। কেবল ফরম্যাটের তারতম্যই এটিকে হারিয়ে দেয়, তাই ম্যানুয়াল সেই দাবিটি সীমিত রাখে। যখন সার্ভারটি আপনার সংস্থার, তখন স্থানীয় ব্যতিক্রম জমা না করে পুশ নীতি সংশোধন করা পরিষ্কারতর।
স্থানীয় ফিল্টারটি কেন আদৌ আছে তা লিখে রাখুন, যাতে পরের ব্যক্তি সিদ্ধান্ত নিতে পারে এটি এখনও দরকার কি না। কারণ চলে যাওয়ার অনেক পরে ফিল্টার জমতে থাকে।