DNS خصوصی Pritunl کار نمی‌کند؟ یک مسیر باریک ریزولور اضافه کنید

نام‌های خصوصی برای همه در شبکه سازمانی حل می‌شوند و برای همه در 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 روی کلاینت بررسی کنید.

به‌جای ترجمه همه چیز یک مسیر میزبان اضافه کنید

راهنمای DNS خصوصی Pritunl درمان باریک را توصیف می‌کند: یک مسیر /32 با NAT فعال برای آدرس ریزولور، با انتخاب همان آدرس به‌عنوان سرور DNS کلاینت‌ها. مسیر فقط برای ترافیک DNS مبدأیی را که ریزولور می‌بیند تغییر می‌دهد. ترافیک برنامه طراحی حفظ مبدأ را که برای آن انتخاب کرده‌اید نگه می‌دارد.

آن را از طریق مالک مسیر پشتیبانی‌شده سرور پیکربندی کنید، پس از بررسی مسیرهای موجود از نظر همپوشانی. در مثال بالا مقصد 10.40.0.53/32 با NAT فعال است و استخر کلاینت 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 همچنان مقصد برنامه را مسیریابی می‌کند. مسیر، دسترسی به سرویس و احراز هویت از حل نام مستقل می‌مانند و یک جستجوی کارآمد چیزی درباره توان عبوری نمی‌گوید. اگر صفحه خصوصی کند است اما حل می‌شود، ریزولور کار خود را کرده و مشکل به مسیر منتقل شده است.