openfortivpn সংযোগ করার সময় রুট ও DNS-এর মালিকানা কার থাকা উচিত?

একটি কার্যকর openfortivpn সেশনে চারটি ধাপ একটির উপর আরেকটি সাজানো থাকে। ক্লায়েন্ট গেটওয়েতে প্রমাণীকরণ করে এবং একটি TLS সংযোগ শুরু করে, তারপর সেই সংযোগের ভিতরে PPP চালায়, এরপর একটি ঠিকানা ও DNS তথ্য পায়, এবং শেষে হোস্ট রুট ও রিজলভার সেটিংস প্রয়োগ করে। প্রতিটি ধাপ সচল থাকতে পারে যখন পরেরটি থাকে না, তাই সাপোর্ট থ্রেডে “সংযুক্ত” এত পিচ্ছিল শব্দ।

বেশিরভাগ বিভ্রান্তি দূর করে যে সিদ্ধান্ত, তা হলো শেষ ধাপের মালিক কে। হয় VPN ক্লায়েন্ট নিজেই হোস্টের পরিবর্তন প্রয়োগ করে, নয়তো অন্য একটি উপাদান তা করে, আর দুটিকে অর্ধেক পথে মিশিয়ে দেওয়াই রুট ও রিজলভার ফাইলকে ভিন্ন সেশন বর্ণনা করিয়ে দেয়।

চারটি ধাপ যা একটিমাত্র সংযোগের মতো দেখায়

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

দ্বিতীয় ধাপটি PPP লিংক। ক্লায়েন্ট টানেল ডিভাইসের বিরুদ্ধে একটি PPP প্রক্রিয়া চালু করে, এবং দুই পক্ষ লিংক অপশন ও ঠিকানা নিয়ে আলোচনা করে। এরপরেই হোস্ট জানে সেশনটি কোন স্থানীয় ও দূরবর্তী ঠিকানা ব্যবহার করে, আর তখনই টানেলের দিকে নির্দেশ করা একটি রুট অর্থবহ হতে পারে।

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

কে রাউটিং টেবিল সম্পাদনা করে

ডিফল্টভাবে ক্লায়েন্টই মালিক। এটি ভৌত ইন্টারফেসের মাধ্যমে গেটওয়ের দিকে একটি রুট, টানেলের সমকক্ষের জন্য একটি রুট, এবং সেশনটি যে নেটওয়ার্কগুলো ব্যবহার করতে পারে সেগুলোর রুট যোগ করে, তারপর প্রক্রিয়া শেষ হলে সেগুলো সরিয়ে দেয়। এই ডিফল্টটি একটি নেটওয়ার্ক ম্যানেজারযুক্ত এবং অন্য কোনো VPN সফটওয়্যারবিহীন ল্যাপটপে সুবিধাজনক।

হ্যান্ডওভার বেছে নিন কেবল তখনই যখন অন্য কিছু সত্যিই রাউটিংয়ের মালিক। একটি নেটওয়ার্ক ম্যানেজার ইন্টিগ্রেশন, একটি কন্টেইনার নেটওয়ার্ক নেমস্পেস, বা সাইট-ব্যাপী রাউটিং এজেন্ট একই প্রিফিক্সগুলো ইনস্টল ও পরিষ্কার করার পদ্ধতি ইতিমধ্যে জানতে পারে। no-routes অপশন দিয়ে দেওয়া তখন দুই লেখককে একই টেবিল নিয়ে লড়তে বাধা দেয়, যা একটি দৌড় যা পরিষ্কার ব্যর্থতার বদলে একটি সাবনেটের মাঝে মাঝে হারিয়ে যাওয়া হিসেবে দেখা দেয়।

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

পরিষ্কার করা তৃতীয়টি। যে ক্লায়েন্ট তার রুট সরানোর আগে ক্র্যাশ করে, সে একটি কালো গর্ত রেখে যায় যা সেশনের চেয়ে বেশি বাঁচে, এবং পরের সংযোগ তার উপরে একটি নকল যোগ করতে পারে। রাউটিংয়ের মালিকই পুরোনো এন্ট্রিগুলো গেছে কিনা যাচাইয়েরও মালিক। সেই যাচাইকে স্টার্টআপ পথের অংশ করুন, ঐচ্ছিক পরিষ্কার ধাপ নয়।

কে DNS ও রিজলভার ফাইলের মালিক

DNS একই সিদ্ধান্ত, আরও ধারালো প্রান্তে। ক্লায়েন্ট গেটওয়ে বা PPP সমকক্ষ যে DNS সার্ভার জানায় তা গ্রহণ করে হোস্ট রিজলভার কনফিগারেশনে লিখতে পারে। সাধারণ মেশিনে এটাই আপনি চান, কারণ অভ্যন্তরীণ নাম তখনই সমাধান হয় যখন টানেল চালু থাকে।

আধুনিক Linux হোস্টে রিজলভার একটি স্থানীয় স্টাব দ্বারা পরিচালিত হতে পারে, আর সেই স্টাবের পিছনে রিজলভার ফাইল পুনর্লিখন এমন কনফিগারেশন তৈরি করে যা সঠিক দেখায় কিন্তু অসামঞ্জস্যপূর্ণ আচরণ করে। হোস্ট ইতিমধ্যে একটি রিজলভার ম্যানেজার চালালে, তাকে DNS-এর মালিক হতে দিন এবং তার সমর্থিত ইন্টারফেসের মাধ্যমে টানেলের সার্ভারগুলো তাকে দিন। ক্লায়েন্টের no-dns অপশন সেখানে সঠিক পছন্দ, কোনো কাজের চারপাশ নয়।

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

বিশেষাধিকার, প্রস্তুতি ও হ্যান্ডওভার

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

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

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