چرا DNS پس از اتصال OpenVPN در Windows از کار می‌افتد

حل‌کننده هنوز به ping پاسخ می‌دهد در حالی که پورت 53 به جایی نمی‌رسد. بررسی کنید آیا block-outside-dns فیلتر می‌کند، سپس حل‌کننده‌ای بدهید که تونل بتواند به آن برسد.

Ping به حل‌کننده دفتر پس از اتصال "OpenVPN" هنوز پاسخ می‌گیرد، و با این حال هر جستجوی نامی شکست می‌خورد. نشانی قابل دسترس است در حالی که پورت نیست، ترکیبی که وقتی بدانید Windows می‌تواند DNS را بر اساس آداپتور فیلتر کند منطقی می‌شود. با وجود block-outside-dns در پروفایل، همان فیلتر نخستین مظنون است و جدول مسیریابی جای اشتباهی برای جستجو است. دو آزمون زیر لایه‌ها را در چند ثانیه جدا می‌کند.

نشانی قابل دسترس، پورت مرده

یک ping موفق ثابت می‌کند که میزبان روشن است و مسیری وجود دارد. اما درباره اجازه رسیدن به پورت 53 چیزی نمی‌گوید، چون فیلتر مورد بحث در لایه‌ای دیگر کار می‌کند و به آداپتور گره خورده است. به همین دلیل همان ماشین می‌تواند به ICMP پاسخ دهد و هر پرسشی که به همان نشانی فرستاده شود را رد کند. هر دو آزمون را در یک نشست پیش از تغییر هر تنظیمی اجرا کنید.

ping <resolver-ip>
nslookup <name> <resolver-ip>

همین جفت تشخیص است. ترافیک معمولی به زیرشبکه ادامه دارد در حالی که تجزیه نام می‌میرد، و مردم نتیجه می‌گیرند که سرور خراب است یا DNS هرگز فرستاده نشده. دنبال کردن هر دو توضیح پرهزینه است، و شواهد به جایی باریک‌تر اشاره می‌کند. پیش از دست زدن به هر تنظیمی جفت را تأیید کنید.

این گزینه قاعده‌ای از سکوی فیلتر است

مرجع OpenVPN گزینه block-outside-dns را محدودیتی در Windows Filtering Platform توصیف می‌کند که برنامه‌ها را از رسیدن به DNS روی آداپتورهای بیرون تونل باز می‌دارد. این محدودیت TCP و UDP روی پورت 53 را پوشش می‌دهد. چون فیلتر در WFP زندگی می‌کند و نه در فهرست معمول قواعد دیوار آتش، افزودن قاعده اجازه در جای دیگر لزوماً نتیجه را عوض نمی‌کند. به همین دلیل توصیه رایج به اجازه دادن DNS همچنان شکست می‌خورد.

تنظیم می‌تواند از پروفایل واردشده یا از سرور بیاید، و فایلی که آخرین بار ویرایش کردید "دلیل آنچه کلاینت بارگذاری کرده نیست". پیکربندی مؤثر و گزارش اتصال را با هم بخوانید. این گزینه مخصوص Windows هم هست، و برخورد با آن به عنوان گزینه‌ای قابل حمل توصیه‌هایی می‌دهد که صدق نمی‌کند.

به جای افزودن قواعد بیشتر، مؤلفه کلاینتی را که مالک این محدودیت است جستجو کنید. مالک همان چیزی است که واقعاً می‌تواند آن را بردارد.

فیلتر حل‌کننده نیست

مسدود کردن ترافیک بیرون تونل، حل‌کننده‌ای کارا در درون آن نصب نمی‌کند. این گزینه یک مسیر را برمی‌دارد و پیکربندی DNS تونل را به هر کسی که پروفایل را ساخته واگذار می‌کند. پروفایلی که هرگز حل‌کننده‌ای نفرستاده اکنون هیچ‌کدام را ندارد.

سه بررسی را به ترتیب انجام دهید. نخست، برنامه شکست‌خورده واقعاً از کدام حل‌کننده استفاده می‌کند. دوم، آیا کلاینت تنظیمات DNS مربوط به VPN را اعمال کرده است. سوم، کدام رابط ترافیک را به آن حل‌کننده می‌برد.

  1. حل‌کننده در استفاده: Resolve-DnsName -Server <resolver-ip> <name> را با سرورهای DNS که ipconfig /all فهرست می‌کند مقایسه کنید.
  2. DNS مربوط به VPN اعمال‌شده: ورودی‌های DNS آداپتور تونل را در همان خروجی ipconfig /all بررسی کنید.
  3. رابط استفاده‌شده: Find-NetRoute -RemoteIPAddress <resolver-ip> رابط خروجی برای آن مقصد را نام می‌برد.

حل‌کننده LAN تحت این سیاست بر اساس طراحی غیرقابل دسترس می‌شود، حتی وقتی ترافیک دیگر LAN کار می‌کند. این همان گزینه است که کار خود را می‌کند. اگر طراحی به DNS از طریق VPN نیاز دارد، ثبت حل‌کننده و مسیر تونل را درست کنید؛ اگر DNS تقسیم‌شده با استثناهای محلی لازم است، مالک پیکربندی باید آن استثناها را به شکلی پشتیبانی‌شده بیان کند.

آنچه این گزینه پوشش نمی‌دهد

پورت 53 تمام تجزیه نام نیست. DNS over HTTPS و DNS over TLS از حامل‌های متفاوتی استفاده می‌کنند، و برخی برنامه‌ها منطق حل‌کننده خودشان را مستقل از تنظیمات سیستم اجرا می‌کنند. بنابراین مرورگر می‌تواند نام‌ها را حل کند در حالی که خط فرمان نمی‌تواند.

این تفاوت را تشخیص بگیرید نه تناقض. پیش از آنکه نتیجه بگیرید حل‌کننده سیستم خراب است، هر دو را مقایسه کنید.

هنگام نوشتن، نتیجه را باریک نگه دارید. این گزینه یک حامل روی یک سکو را محدود می‌کند، و بقیه مسیر تجزیه پرسشی طراحی جداگانه با مالک خودش است.

وضعیت را پیش و پس از قطع اتصال بررسی کنید

همان جستجو را در طول اتصال و دوباره پس از قطع اتصال کلاینت مالک اجرا کنید. اولی باید برای حل‌کننده بیرونی هنگامی که تونل برپاست شکست بخورد، و دومی باید پس از برداشتن فیلتر موفق شود. اگر پس از قطع اتصال هنوز شکست می‌خورد، فیلتر پاک نشده است.

ipconfig /displaydns
nslookup <name> <resolver-ip>

راه‌اندازی دوباره سرویس کلاینت یا ماشین معمولاً فیلتر کهنه را پاک می‌کند. این تشخیص را تأیید می‌کند بدون آنکه اصلاحی دائمی ثابت کند. آنچه دیدید را ثبت کنید، چون فیلتری که از قطع اتصال جان سالم به در می‌برد باز هم همین کار را می‌کند، و همین ثبت است که گزارش باگ را توجیه می‌کند.

تنها پس از این بررسی‌ها جایگزینی حل‌کننده یا بازسازی سیاست دیوار آتش معنا پیدا می‌کند. هر دو تغییراتی بزرگ‌تر از آن هستند که شواهد پشتیبانی می‌کند.

مقالات مرتبط