mDNS درون VPN: چرا نام‌های .local حل نمی‌شوند

چاپگر دفتر شما در هر برنامه‌ای روی میزتان ظاهر می‌شود و در VPN ناپدید می‌گردد، هرچند می‌توانید نشانی را که می‌دانید دارد پینگ کنید. هیچ چیز در تونل خراب نیست: کشف و دسترسی‌پذیری دو سرویس جداگانه‌اند و به‌طور پیش‌فرض فقط یکی از آن‌ها از تونل مسیریابی‌شده عبور می‌کند. بررسی‌های زیر پیش از افزودن مسیرها آن‌ها را جدا می‌کنند. یک مسیر نمی‌تواند پرس‌وجویی را که هرگز پیوند را ترک نکرده درست کند.

بررسی کنید امروز چه چیزی حل می‌شود و چه چیزی فقط حل‌شده به نظر می‌رسد

نخست دو پرسش را جدا کنید: پرس‌وجوی unicast برای نام میزبان از یک resolver می‌پرسد، در حالی که جست‌وجوی _ipp._tcp از پیوند محلی می‌پرسد. در Linux، avahi-browse -a نشان می‌دهد multicast DNS چه می‌بیند، و resolvectl query name.local نشان می‌دهد پشته resolver با آن نام چه می‌کند. در macOS، dns-sd -B _ipp._tcp سرویس‌های کشف‌شده را بدون نیاز به نشانی فهرست می‌کند.

اگر نشانی پاسخ دهد و نام نه، مسیریابی کار می‌کند و کشف نه. نام .local را می‌توان روی خود میزبان نیز از طریق nss-mdns پاسخ داد بدون آنکه avahi-browse نصب باشد، پس getent یا ping موفق به آن نام دلیلی بر عبور کشف از تونل نیست؛ نتیجه جست‌وجو و نتیجه resolver دو مدرک متفاوت‌اند. برنامه‌ها آنچه کشف کرده‌اند را در حافظه پنهان نگه می‌دارند، به همین دلیل خطا غالباً ساعت‌ها پس از اتصال رخ می‌دهد نه هنگام اتصال. برنامه را ببندید و دوباره باز کنید، سپس بررسی کنید ورودی پنهان‌شده نام دارد یا نشانی، زیرا نشانی مدت زیادی پس از توقف کشف کار می‌کند.

چرا پرس‌وجو هرگز از تونل عبور نمی‌کند

multicast DNS پرس‌وجوها را به 224.0.0.251، درون بلوک کنترل شبکه محلی، روی پورت UDP 5353 می‌فرستد. مسیریاب‌ها نشانی‌های آن بلوک را ارسال نمی‌کنند، بنابراین پرس‌وجو در همان پیوندی می‌ماند که به آن فرستاده شد. فرستنده‌ها نیز TTL پروتکل IP یا حد پرش IPv6 را روی 255 می‌گذارند تا گیرنده بتواند بسته‌ای را که پیش‌تر از مسیریاب گذشته رد کند؛ این‌گونه پروتکل جعل بیرون از پیوند را تشخیص می‌دهد، نه اینکه این‌گونه محلی بماند. محلی‌بودن از نشانی مقصد می‌آید، نه از TTL یک‌پرشی.

نوع تونل هم مهم است. رابطی با سبک tun فقط بسته‌های IP را حمل می‌کند و بس، پس هیچ گروه multicast از آن جان سالم به در نمی‌برد. پلی با سبک tap خودِ دامنه پخش را گسترش می‌دهد، به همین دلیل برخی طراحی‌های قدیمی به‌جای مسیریابی پل زدند و هر مشکلی را که پل می‌آورد به ارث بردند.

استثنای LAN مورد اعتماد هیچ‌کدام از این‌ها را تغییر نمی‌دهد، زیرا تعیین می‌کند کدام ترافیک می‌تواند از تونل استفاده کند، نه اینکه به تونل آموزش دهد multicast را ارسال کند. بسته هنوز هیچ بخش مشترکی برای شنیده شدن ندارد.

طراحی نام‌گذاری‌ای برگزینید که بتوانید پشتیبانی کنید

برای منابع شرکت، پاسخ پایدار یک نام میزبان مسیریابی‌شده است که resolver تحت فشار VPN ارائه می‌کند، همراه با DNS تفکیک‌شده تا نام‌های داخلی به سرورهای داخلی بروند و بقیه نروند. Windows آن را به‌صورت جدول خط‌مشی حل نام ارائه می‌دهد، macOS از resolverهای محدودشده به‌ازای هر رابط استفاده می‌کند و بیشتر کارخواه‌ها تنظیم فشار معادلی دارند. دستگاه نام معمول خود را در DNS داخلی نگه می‌دارد و کشف دیگر بخشی از مسیر نیست.

یک پروکسی کشف یا بازتابنده mDNS می‌تواند این شکاف را پل بزند و طراحی واقعی با میزبان، مواجهه و نیازهای کارخواه خودش است. به این دلیل که مسیری افزوده‌اید ظاهر نمی‌شود. هرگز پرس‌وجوهای .local را به resolver عمومی نفرستید: این دامنه طبق RFC 6762 برای استفاده محلی multicast رزرو شده است و فرستادن آن به بیرون شکست‌های کند و افشای بی‌دلیل داده ایجاد می‌کند.

سرویس را بررسی کنید، نه نام را

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

کشف نام‌ها را به‌شدت در حافظه پنهان نگه می‌دارد، پس یک ورودی کهنه می‌تواند موفقیت به نظر برسد. اگر گواهی یا درخواست احراز هویت ظاهر شود، آن لایه بعدی و مسئله‌ای جداست. بنویسید کدام سازوکار را تغییر داده‌اید، resolver یا کشف، تا نفر بعد مجبور نشود کل پرسش را دوباره باز کند.