Pritunl-এ প্রাইভেট DNS কাজ করছে না? একটি সংকীর্ণ রিজলভার রুট যোগ করুন

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

নিশ্চিত করুন যে রিজলভার আপনার ক্লায়েন্ট পুল প্রত্যাখ্যান করছে

প্রমাণ দিয়ে শুরু করুন যে ব্যর্থতাটি উৎস সম্পর্কিত, পৌঁছানোযোগ্যতা নয়। সংযুক্ত ক্লায়েন্ট থেকে প্রাইভেট রিজলভারকে সরাসরি কুয়েরি করুন এবং দেখুন অনুরোধটি টাইম আউট হচ্ছে কি না প্রত্যাখ্যান হিসেবে ফিরছে। dig @10.40.0.53 intranet.example.net +time=2 +tries=1 টাইম আউট হচ্ছে যখন গেটওয়ে থেকে একই কুয়েরি সফল হয়, তা রিজলভারে একটি অ্যাক্সেস নীতি নির্দেশ করে। SERVFAIL উত্তর সম্পূর্ণ ভিন্ন জায়গায়, সাধারণত জোন বা আপস্ট্রিম ফরওয়ার্ডারে নির্দেশ করে।

পরীক্ষার আগে ক্লায়েন্টের ঠিকানা লিখে রাখুন। ক্লায়েন্টে ip -4 addr show tun0, বা কনসোলে দেখানো লিজ, আপনাকে বলে রিজলভার কোন পুল দেখছে।

তারপর নিশ্চিত করুন পথটি আদৌ আছে। যে রুট রিজলভারের ঠিকানাকে টানেলে পাঠায় তা পূর্বশর্ত, সমাধান নয়; যদি প্যাকেট কখনো না পৌঁছায়, উৎস নীতির কোনো পরামর্শই নেওয়া হয় না। ক্লায়েন্টে ip route get 10.40.0.53 দিয়ে এটি যাচাই করুন।

সবকিছু অনুবাদ করার বদলে একটি হোস্ট রুট যোগ করুন

Pritunl-এর প্রাইভেট-DNS নির্দেশিকা সংকীর্ণ সমাধান বর্ণনা করে: রিজলভার ঠিকানার জন্য NAT-সক্রিয় /32 রুট, সেই ঠিকানাটি ক্লায়েন্টদের DNS সার্ভার হিসেবে নির্বাচিত করে। রুটটি কেবল DNS ট্র্যাফিকের জন্য রিজলভার যে উৎস দেখে তা পরিবর্তন করে। অ্যাপ্লিকেশন ট্র্যাফিক আপনার বেছে নেওয়া উৎস-সংরক্ষণকারী নকশা ধরে রাখে।

সার্ভারের সমর্থিত রুট মালিকের মাধ্যমে এটি কনফিগার করুন, আগে বিদ্যমান রুটগুলো ওভারল্যাপের জন্য পর্যালোচনা করে। উপরের উদাহরণে গন্তব্য NAT-সক্রিয় 10.40.0.53/32, এবং ক্লায়েন্ট পুল 10.90.0.0/24 থাকে। একটি পরিষেবা ঠিক করতে পুরো প্রাইভেট পরিসর অনুবাদ করবেন না, কারণ ক্লায়েন্টের প্রকৃত ঠিকানার উপর নির্ভর করা প্রতিটি ডাউনস্ট্রিম নীতি এর বদলে গেটওয়ে দেখতে শুরু করবে। পরীক্ষামূলক লুকআপের সময় রিজলভারের কুয়েরি লগ দেখে নিশ্চিত করুন এটি আসলে কোন ঠিকানা পায়। কেবল একটি হোস্ট রুট অনুবাদ বা অনুমতি সম্পর্কে কিছুই প্রমাণ করে না।

রিজলভারকে এখনও UDP ও TCP-তে অনূদিত উৎস অনুমোদন করতে হবে, এবং এর উত্তর ফিরে আসতে সক্ষম হতে হবে। উৎস পরিবর্তন করে অনুপস্থিত জোন বা রেকর্ড তৈরি করা যায় না।

সার্ভার না ক্লায়েন্ট কুয়েরি পাঠায় তা নির্ধারণ করুন

Pritunl আরও একটি DNS-প্রক্সি ব্যবস্থা নথিভুক্ত করে যা VPN Client DNS Mapping-এর সাথে যুক্ত, যেখানে সার্ভার ক্লায়েন্টদের পক্ষে আপস্ট্রিম কুয়েরি ফরওয়ার্ড করে। সেই মডেলে আপস্ট্রিম উৎস সার্ভারের নিজস্ব নেটওয়ার্ক প্রসঙ্গের অন্তর্গত, এবং ক্লায়েন্ট-সাইড ব্যতিক্রম ভুল সমাধান।

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

একটি প্রাইভেট লুকআপ পরীক্ষা করুন, পাবলিক ওয়েব পেজ নয়

পরিবর্তন প্রয়োগ করে আবার সংযোগ করার পর, ক্লায়েন্টের কার্যকর রিজলভার কনফিগারেশন পরীক্ষা করুন, তারপর এমন একটি নাম রিজলভ করুন যা আপনি জানেন কেবল প্রাইভেট জোনে আছে। স্পষ্ট সার্ভার ছাড়া dig intranet.example.net দেখায় ক্লায়েন্ট আসলে কী ব্যবহার করে। এরপর সেই লুকআপ যে ঠিকানা ফিরিয়েছে সেখানে অনুরোধ পাঠান, কারণ রিজলিউশন ও পরিষেবা অ্যাক্সেস আলাদা ধাপ। DNS-over-HTTPS-এর মাধ্যমে পাবলিক সাইট লোড করা ব্রাউজার অপারেটিং সিস্টেমের প্রাইভেট রিজলভার পথ সম্পর্কে কিছুই প্রমাণ করে না। একটি পাবলিক সেকেন্ডারি রিজলভারও অভ্যন্তরীণ জোনের জন্য কর্তৃত্ব নয়।

সার্ভার নোটে রিজলভার ঠিকানা, /32 রুট এবং ক্লায়েন্ট DNS সেটিং একসাথে লিখুন। সেই কনফিগারেশনের অর্ধেক একা পুনরুদ্ধার করলে মূল ব্যর্থতা পুনরুৎপাদন হয়।

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