openfortivpn কি বারবার DNS ওভাররাইট করছে? আসল মালিক খুঁজুন

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

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

সংযোগটি আসলে কী বদলেছে তা দিয়ে শুরু করুন

স্বাভাবিক কমান্ড দিয়ে একবার সংযোগ করুন এবং আগে ও পরে রেজলিউশন তুলনা করুন। systemd-resolved চালানো Linux হোস্টে resolvectl status প্রতি লিঙ্কের DNS সার্ভার ও অনুসন্ধান ডোমেইন দেখায়, এবং নিজের সার্ভার বহনকারী নতুন tun বা ppp লিঙ্ক ক্লায়েন্ট-সাইড হালনাগাদের আঙুলের ছাপ। macOS-এ scutil --dns রিজলভার কনফিগারেশন দেখায় যে ক্রমে অ্যাপ্লিকেশনগুলো তা দেখে।

এটি সেই ফাইলের সঙ্গে তুলনা করুন যা আপনার বদলানো উচিত ছিল বলে আপনি আশা করেছিলেন। প্রতি-লিঙ্ক দৃশ্যে সংযোগ-সংযুক্ত এন্ট্রি আর পুনর্লিখিত /etc/resolv.conf দুটি আলাদা ফলাফল, এবং দ্বিতীয়টি এমন একটি সিমলিঙ্ক হতে পারে যা সম্পূর্ণ ভিন্ন কিছু পরিচালনা করে। রিজলভার ঠিকানা, অনুসন্ধান ডোমেইন ও ইন্টারফেসের নাম একই মুহূর্তে লিখে রাখুন; তাদের যেকোনো একটির পরিবর্তন ভিন্ন লেখকের দিকে ইশারা করে। সেই ভিত্তিরেখা ছাড়া পরবর্তী প্রতিটি সংশোধনই একটি অনুমান যে তিনটি উপাদানের মধ্যে কোনটি নড়েছে।

দুটি সুইচ আর প্রতিটি যে লেখককে দমন করে

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

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ক্লায়েন্টকে গেটওয়ে থেকে শেখা DNS সার্ভার প্রয়োগ করা থেকে থামায়, আর --pppd-no-peerdns pppd-কে পিয়ার DNS সিস্টেমে ঠেলে দেওয়া থেকে থামায়। আপস্ট্রিম ডকুমেন্টেশন সতর্ক করে যে PPP-তে DNS হালনাগাদ ক্লায়েন্টের নিজস্ব DNS হালনাগাদের সঙ্গে দৌড়ে যেতে পারে, তাই দুটি সুইচই ফ্র্যাগমেন্টে থাকা উচিত, কোনো একটিকে যথেষ্ট ভাবা নয়।

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

কিছু নিষ্ক্রিয় করার আগে মালিক বেছে নিন

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

রুট মালিকানা ইচ্ছাকৃতভাবে আলাদা থাকে। রুট অপশনগুলো আপনার DNS বদলানোর কারণে প্রয়োজনীয় নয়, এবং বিকল্প না বসিয়ে রুট ইনস্টলেশন বন্ধ করা আপনি এইমাত্র যে রিজলভার বেছেছেন তাকে পৌঁছানো-অযোগ্য করে দিতে পারে। রাউটিং টেবিলে নির্দিষ্টভাবে রিজলভারের ঠিকানা দেখুন, শুধু আপনি দৈবাৎ পরীক্ষা করা অ্যাপ্লিকেশন সাবনেট নয়।

প্রতি লিঙ্কে রেজলিউশন দেখুন, প্রতি ফাইলে নয়

স্কোপড বা প্রতি-ডোমেইন রেজলিউশনযুক্ত হোস্টে অ্যাপ্লিকেশনগুলো আসলে কী ব্যবহার করে তার তালিকা একটি /etc/resolv.conf নয়, তাই প্ল্যাটফর্ম যেভাবে রিজলভার অবস্থা প্রকাশ করে সেভাবেই পড়ুন।

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

পুনঃসংযোগ করুন এবং বিচ্ছিন্ন অবস্থা নিশ্চিত করুন

সংযোগটি নামিয়ে দিন এবং দুটি প্রশ্নই পুনরাবৃত্তি করুন। বেছে নেওয়া মালিক যা ইনস্টল করেছে তা সেই মালিককেই সরাতে বা ফিরিয়ে আনতে হবে, আপনি যে ক্লায়েন্টকে চুপ করিয়েছেন সে রেখে যাবে না। টানেলের চেয়ে বেশি দিন বেঁচে থাকা পুরোনো প্রতি-লিঙ্ক এন্ট্রি ব্যক্তিগত প্রশ্ন পাঠাতে থাকে এমন ঠিকানায় যা আর পৌঁছানো যায় না।

তারপর আবার সংযোগ করুন এবং একই তিনটি মান পড়ুন: রিজলভার ঠিকানা, অনুসন্ধান ডোমেইন, ইন্টারফেস।

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