স্প্লিট-টানেল ডকুমেন্টে প্রতিটি রুটের পাশে DNS নিয়ম দরকার
রুট ঠিক করে ঠিকানায়, রিজলভার ঠিক করে নামে। প্রতিটি ফ্লোতে দুটি সিলেক্টরই লিখুন, প্রতিটির জন্য একটি পরীক্ষা, নইলে DNS সরে গেলে নোটটি ব্যর্থ হয়।
যে স্প্লিট-টানেল নোটে বলা হয় "অফিস ট্রাফিক VPN-এর মধ্য দিয়ে যায়", সেটি একটি সিদ্ধান্ত নথিভুক্ত করেছে এবং আরও তিনটি নিহিত রেখেছে। প্যাকেট স্তরে একটি রাউটিং টেবিল গন্তব্য ঠিকানা দিয়ে ইন্টারফেস বেছে নেয়; নাম স্তরে একটি রিজলভার কোয়েরি দিয়ে সার্ভার বেছে নেয়, এবং দুটি পছন্দ স্বাধীনভাবে করা হয়। এই কারণেই সঠিকভাবে নথিভুক্ত একটি প্রিফিক্স এমন মেশিন তৈরি করতে পারে যা একটি অভ্যন্তরীণ নামকে পাবলিক ঠিকানায় রিজলভ করে, বা কিছুই রিজলভ করে না যখন রুটটি নিখুঁত দেখায়।
দুটি সিলেক্টর, একটি সংযোগের প্রচেষ্টা
যখন একটি অ্যাপ্লিকেশন files.corp.example -এ সংযোগ করে, প্যাকেট তৈরির আগে দুটি লুকআপ ঘটে। রিজলভার ঠিক করে কোন সার্ভার কোয়েরি পাবে, সার্চ ডোমেইন, প্রতি-লিঙ্ক রাউটিং ডোমেইন বা স্পষ্ট প্রোফাইল নিয়ম ব্যবহার করে। তারপর রাউটিং টেবিল ঠিক করে ফলাফল ঠিকানাটি কোথায় যাবে, গন্তব্যের বিপরীতে দীর্ঘতম-প্রিফিক্স মিল ব্যবহার করে।
কোনো কিছুই ওই দুটি সিদ্ধান্তকে সংযুক্ত করে না। একটি ব্যক্তিগত জোন উত্তর দিতে পারে 10.20.4.11 দিয়ে, যখন রাউটিং টেবিল পাঠায় 10.20.0.0/16 টানেলে, এবং সংযোগটি কাজ করে। যেকোনো একটি উল্টে দিলে এটি অন্যটির মতো দেখতে ব্যর্থ হয়: সঠিক DNS নীতি এবং অনুপস্থিত রুট একটি রিজলভ হওয়া নাম ও টাইমআউট দেয়, আর সঠিক রুট ও পাবলিক রিজলভার এমন ঠিকানা দেয় যা পরিষ্কারভাবে ভুল জায়গায় রাউট হয়।
স্প্লিট-হরাইজন DNS এটিকে আরও তীক্ষ্ণ করে। একই নাম অভ্যন্তরীণ রিজলভার থেকে ব্যক্তিগত ঠিকানা এবং ইন্টারনেটমুখী রিজলভার থেকে পাবলিক ঠিকানা ফেরত দিতে পারে, তাই শুধু প্রিফিক্স লিখে রাখা নোট ভবিষ্যদ্বাণী করতে পারে না ক্লায়েন্ট আসলে কোন ঠিকানা ব্যবহার করবে। রিজলভারের পথ লিখুন, নইলে ঠিকানাটি একটি অনুমান।
শুধু-রুট নোট কী বাদ দেয়
শুধু-রুট রেকর্ড সবচেয়ে সাধারণ স্প্লিট-টানেল ব্যর্থতার জন্য অকেজো: নাম। ব্যবহারকারী জানান যে ইন্ট্রানেট লোড হয় না, টানেল চালু আছে, এবং প্রিফিক্স উপস্থিত। যে টিকিটটি নেয় তার কাছে কোন রিজলভারের উত্তর দেওয়া উচিত ছিল তার কোনো রেকর্ড নেই, ভুল সার্চ সাফিক্সকে ব্লক করা সার্ভার থেকে আলাদা করার উপায় নেই, এবং তুলনার জন্য কোনো বেসলাইন নেই।
দ্বিতীয় বাদ দেওয়াটি হলো ব্যতিক্রমের তালিকা। একটি স্প্লিট-টানেল নকশা টানেলের বাইরে কী থাকে তার দ্বারাও ততটাই নির্ধারিত হয় যতটা ভেতরে কী ঢোকে, এবং বাদ দেওয়া রেঞ্জগুলোই সাধারণত আগে ভাঙে, কারণ আরও নির্দিষ্ট স্থানীয় রুট বা ক্লায়েন্ট-সাইড ফিল্টার প্রোফাইল স্পর্শ না করেই উদ্দেশ্যকে অতিক্রম করতে পারে।
তৃতীয়টি হলো টানেলের দূরপ্রান্ত। ক্লায়েন্ট রুট শুধু প্যাকেটটিকে তারে তোলে; গেটওয়েকে এখনও এটি ফরওয়ার্ড করতে হবে এবং ফেরার পথ থাকতে হবে। strongSwan-এর ফরওয়ার্ডিং নির্দেশিকা মনে করিয়ে দেয় যে গেটওয়েতে ফরওয়ার্ডিং ও ফায়ারওয়াল নিয়ম বৈশিষ্ট্যের অংশ, এমন প্লাম্বিং নয় যা আপনি ধরে নিতে পারেন।
যে ক্ষেত্রগুলো নোটটিকে কার্যকর করে
প্রতি ফ্লোতে একটি সারি, আর ফ্লো মানে গন্তব্য যোগ নাম যোগ মালিক। এগুলোই সেই ক্ষেত্র যা বাস্তব ঘটনার সংস্পর্শে টিকে থাকে:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"এটি কোথায় থাকে" সারিটিই মানুষ এড়িয়ে যায়। সার্ভারের পাঠানো প্রিফিক্স, ক্লায়েন্ট প্রোফাইলের যোগ করা রুট এবং শেলে টাইপ করা রুট—এগুলো কে বদলাতে পারে এবং পুনঃসংযোগে টিকে থাকে কি না তাতে ভিন্ন। ওই ক্ষেত্র ছাড়া পরবর্তী প্রকৌশলী বুঝতে পারবেন না তিনি তিনটির কোনটি দেখছেন।
প্রতি নিয়মে একটি পরীক্ষা, প্রতি টানেলে নয়
প্রতিটি সারিতে দুটি নিরীহ যাচাই দরকার: একটি রুটটি চালায়, অন্যটি নামটি। রুটের জন্য, এমন কিছু চান যা টানেল অতিক্রম করবে এবং পৌঁছানোর বদলে পথটি নিশ্চিত করুন, উদাহরণস্বরূপ tracert -d 10.20.4.11 Windows-এ বা ip route get 10.20.4.11 Linux-এ। নামের জন্য, ব্যক্তিগত নামটি কোয়েরি করুন এবং কোন সার্ভার উত্তর দিয়েছে তা রেকর্ড করুন, নোটে নাম দেওয়া রিজলভারের বিরুদ্ধে resolvectl query files.corp.example বা dig files.corp.example ব্যবহার করে।
একটি নেতিবাচক প্রত্যাশাও যোগ করুন: টানেল বন্ধ থাকলে কী হওয়া উচিত। VPN ছাড়া ব্লক চালু থাকা Android বা iOS ডিভাইসে বাদ দেওয়া অ্যাপ্লিকেশনের আদৌ কোনো সংযোগ নাও থাকতে পারে, আর ডেস্কটপ ক্লায়েন্ট টানেল পুনঃসংযোগের সময়ও একই অ্যাপটিকে কাজ করতে দিতে পারে। অভীষ্ট উত্তর রেকর্ড করা "VPN আমার অ্যাপ ভেঙেছে"-কে একটি যাচাইযোগ্য বাক্যে বদলে দেয়।
কনফিগারেশনের সঙ্গে রেকর্ড রাখুন
নোটটি যে প্রোফাইল বর্ণনা করে তার পাশে সংরক্ষণ করুন এবং সেই প্রোফাইলের সঙ্গে সংস্করণ দিন। উইকিতে থাকা যে নথি কেউ হালনাগাদ করে না তা গুজব; চালিত রুট ও রিজলভার নীতির মতো একই ভান্ডারে থাকা টেবিল একই পরিবর্তনে পর্যালোচনা করা যায়।
কিছু ভাঙলে, আরেকটি ব্যতিক্রম যোগ করার আগে প্রয়োগ করা রুট ও কার্যকর রিজলভার রেকর্ডের সঙ্গে তুলনা করুন। তিনটি সাধারণ কারণের দুটি — পুরোনো নেমস্পেস নিয়ম এবং অ্যাপ নীতির বাইরের সহায়ক প্রক্রিয়া — ঠিক VPN ত্রুটির মতো দেখায় এবং নোট শুধু প্রিফিক্স তালিকাভুক্ত করলে অদৃশ্য থাকে।
নোটটি সমাপ্ত বলার আগে নিশ্চিত করুন যে এটি লিখিতভাবে এগুলোর উত্তর দেয়: কোন প্রিফিক্স, কোন ঠিকানা পরিবারের জন্য; কোন ব্যক্তিগত নেমস্পেস, কোন রিজলভার উত্তর দেয়; কোন নাম ইচ্ছাকৃতভাবে পাবলিক থাকে; প্রতিটি নিয়ম কোথায় কনফিগার করা এবং কার মালিকানা; এবং যে একটি কমান্ড রুটটি প্রমাণ করে আর যে একটি নামটি প্রমাণ করে। এর কোনোটি অনুপস্থিত থাকলে পরবর্তী ঘটনাটি শূন্য থেকে নির্ণয় করতে হবে।