چرا جست‌وجوی نام‌ها در تونل مسیریابی‌شده OpenVPN شکست می‌خورد
تونل TUN مسیریابی‌شده فقط unicast IP حمل می‌کند، پس پرس‌وجوی نام از راه پخش هرگز مسیری به آن نداشت. پل‌سازی مرز را حذف می‌کند؛ هُل دادن DNS راه‌حل ارزان‌تری است.
یک میزبان به ping با نشانی پاسخ می‌دهد و در هر جست‌وجو با نام شکست می‌خورد. تونل بالاست و مسیر وجود دارد، پس نتیجه طبیعی این است که VPN بد پیکربندی شده است. نتیجه سودمندتر این است که جست‌وجو هرگز مسیریابی‌پذیر نبود: تونل مسیریابی‌شده unicast IP حمل می‌کند، در حالی که پرس‌وجو یک پخش بود که دنبال بخشی می‌گشت که آن طرف وجود ندارد. به‌محض اینکه ناهم‌خوانی لایه‌ها پیدا شود، راه‌حل‌ها خودشان بر اساس هزینه مرتب می‌شوند.
افسانه: تونل خراب است چون نام‌ها شکست می‌خورند
نشانه قانع‌کننده است چون همه‌چیز بالاتر از لایه نام کار می‌کند. نشانی‌ها مسیریابی می‌شوند، واسط بالاست و همتا به ping پاسخ می‌دهد. آنچه شکست خورد سازوکار کشفی است که هرگز مسیری از یک پیوند نقطه‌به‌نقطه نداشت، و این گزاره‌ای متفاوت از تونل خراب است. جدا کردن این دو گزاره بیشتر کار تشخیص است.
برخورد با آن به‌عنوان عیب تونل به ویرایش‌هایی در پروفایل می‌رسد که نمی‌تواند کمک کند. افزودن گزینه‌ها، تغییر رمزنگاری یا نصب دوباره کارخواه، پخش را دقیقاً همان‌جا که بود رها می‌کند.
پیش از نام‌گذاری راه‌حل، سازوکاری را که شکست خورد نام ببرید. جست‌وجویی که از پخش استفاده می‌کند به بخش نیاز دارد، در حالی که جست‌وجویی که از تحلیلگر نام استفاده می‌کند به نشانی‌ای برای پرسیدن نیاز دارد.
TUN چه چیزی را حمل می‌کند و چه چیزی را نه
دستگاه TUN یک واسط IP است و همین آن را مسیریابی‌پذیر می‌کند. OpenVPN به کارخواه نشانی و مجموعه‌ای از مسیرها می‌دهد و از آن پس کارخواه بسته‌های داده را به همتا می‌فرستد. هیچ‌چیز در آن مدل پیوند مشترکی نمی‌سازد که هر میزبان هر فریم را بشنود.
ترافیک کشف اصلاً با آن مدل جور درنمی‌آید. پرس‌وجوهای قدیمی نام در Windows، اعلان‌های SSDP و درخواست‌های mDNS به همه در یک بخش فرستاده می‌شوند نه به یک مقصد. پیوند مسیریابی‌شده «همه»ای برای فرستادن ندارد. هر یک از این سازوکارها رسانه مشترک را فرض می‌کند.
پس تونل می‌تواند سالم باشد در حالی که کشف کاملاً شکست بخورد. همان جمله را باید چسبید وقتی کسی گزارش می‌دهد که VPN قطع است.
پل‌سازی با حذف مرز کار می‌کند
دستگاه TAP فریم‌ها را حمل می‌کند و یک پل آن را به بخش واقعی LAN وصل می‌کند. آن‌گاه کارخواه نشانی‌ای در آن بخش دارد و ترافیک پخش آن را می‌شنود. به همین دلیل پل‌سازی به‌نظر مشکل نام را درمان می‌کند. همچنین کارخواه را برای نشانی‌دهی به آن بخش وابسته می‌کند.
درمان، حذف مرز مسیریابی است، نه توانایی تازه‌ای در نام‌گذاری درون تونل. هر چیزی که بخش پخش می‌کند اکنون از پیوند هم می‌گذرد.
برای یک آزمایشگاه کوچک این معامله منصفانه است. برای نیروی کاری پراکنده به‌ندرت.
هُل دادن DNS و WINS اصلاح باریک‌تر است
به کارخواه جایی مشخص برای پرسیدن بدهید. dhcp-option DNS و dhcp-option DOMAIN نام‌های داخلی را به کارسازی می‌فرستند که ناحیه را می‌شناسد، و کارخواه Windows که هنوز به NetBIOS تکیه دارد می‌تواند به همان روش یک کارساز WINS بگیرد. تونل مسیریابی‌شده می‌ماند و بخش در جای خودش می‌ماند.
دو شرط تعیین می‌کند که این کار بکند یا نه. کارساز نام‌برده باید برای ناحیه پاسخ بدهد و پرس‌وجو باید از تونل مجاز باشد.
تحلیلگر نام را از کارخواه آزمایش کنید نه از پوسته خود کارساز. تحلیلگری که محلی کار می‌کند هیچ چیزی درباره آنچه تونل حمل می‌کند نمی‌گوید.
بفهمید کدام لایه شکست خورد
نخست به نشانی ping بزنید، سپس نام را تحلیل کنید و بخوانید کدام کارساز پاسخ داد. پاسخ منفی از کارسازی که میزبان ناحیه نیست با پرس‌وجویی که هرگز از دستگاه بیرون نرفت متفاوت به‌نظر می‌رسد. نامی که تحلیل می‌شود اما اتصال‌ها را رد می‌کند مسئله سوم کاملاً دیگری است.
Multicast پشت همان دیوار است. گروهی مانند 224.0.0.251 به‌طور پیش‌فرض از تونل مسیریابی‌شده عبور داده نمی‌شود، و مسیر برای گروه بدون مسیری که multicast را بفهمد یا بازتابنده‌ای در LAN کافی نیست.