تونل تقسیم‌شده شما به برنامه می‌رسد اما به سرور DNS آن نه
تونل تقسیم‌شده می‌تواند زیرشبکه برنامه را مسیریابی کند و با این حال حل‌کننده کنار آن را از دست بدهد. مسیر میزبان را بیفزایید، سپس بررسی کنید که Windows در واقع کدام سرور را برمی‌دارد.
مسیریابی زیرشبکه برنامه بخش آشکار یک تونل تقسیم‌شده است و تمام کار نیست. حل‌کننده اغلب روی نشانی متفاوت از برنامه‌ای است که به آن خدمت می‌کند، پس تونلی که کار می‌کند می‌تواند جست‌وجو را بیرون آن بگذارد. پروفایلی که 10.80.0.0/16 را حمل می‌کند و چیز دیگری نه، پرس‌وجوی 10.90.0.53 را از رابط محلی می‌فرستد، جایی که هیچ ناحیه خصوصی وجود ندارد. مسیر حل‌کننده را بیفزایید، سپس نیمه دوم مسئله را ببینید: کدام سرور را کارخواه در واقع برمی‌گزیند.
افسانه: یک مسیر کل سرویس را پوشش می‌دهد
تونل تقسیم‌شده فهرستی از مقصدهایی است که از اتصال می‌گذرند، نه توصیفی از یک سرویس. زیرشبکه برنامه و نشانی حل‌کننده دو مقصد هستند و پروفایل می‌تواند یکی را بدون دیگری حمل کند. وقتی چنین می‌شود، برنامه با نشانی در دسترس است در حالی که نامش شکست می‌خورد، که بیشتر شبیه خطای DNS به نظر می‌رسد تا شکافی در مسیریابی.
زیرشبکه پیرامون حل‌کننده هم به‌طور خودکار پوشش داده نمی‌شود. مسیر میزبان به یک نشانی برای آن حل‌کننده کافی است و همسایه‌هایش را باز نمی‌کند. معنای مسیر میزبان همین است: به‌طرز طراحی باریک، و آسان برای فراموش کردن وقتی سرویس بعدی در همان زیرشبکه ظاهر می‌شود.
برای کارکردن جست‌وجو سه چیز باید برقرار باشد: کارخواه نشانی حل‌کننده را از تونل مسیریابی کند، دروازه آن درخواست را بپذیرد و بفرستد، و حل‌کننده منبعی را که می‌گیرد بپذیرد. پاسخ هم باید از مسیر توافق‌شده بازگردد. اگر یکی از اینها نباشد، نشانه یکسان است، از این رو ارزش دارد جدول نشانی‌ها را پیش از دست‌زدن به پیکربندی بنویسید.
مشخص کنید پروفایل باید کدام نشانی‌ها را حمل کند
مقصدها را به ترتیب فهرست کنید: شبکه برنامه، نشانی حل‌کننده و نقطه پایانی عمومی که خود تونل را پایان می‌دهد. سومی هرگز نباید به درون تونل مسیریابی شود، چون اتصال بیرونی به مسیری نیاز دارد که پیش از تونل وجود دارد.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
هم UDP و هم TCP را برای DNS بگنجانید، چون از پیاده‌سازی‌ها انتظار می‌رود TCP را در کنار UDP پشتیبانی کنند، و مسیر TCP مسدود خرابی‌های کند و جزئی پدید می‌آورد نه خرابی‌های پاک. اگر ناحیه خصوصی از طریق IPv6 هم سرویس داده شود، استثنای میزبان معادل از نشانی و پیشوند IPv6 استفاده می‌کند و ورودی جداگانه‌ای است.
پیش از افزودن چیزی ثبت کنید که پروفایل از پیش چه چیزی را پوشش می‌دهد. مسیر تکراری بی‌ضرر است، اما مسیر موجود غیرمنتظره به شما می‌گوید پروفایل برای طرح نشانی متفاوتی از آنچه گرفته‌اید طراحی شده است.
مسیر میزبان را از طریق مالک اتصال بیفزایید
برای پروفایل بومی Windows که به‌طور محلی مدیریت می‌شود، مسیر به اتصال تعلق دارد نه به جدول مسیریابی سراسری ماشین. نخست افزودن را پیش‌نمایش کنید، سپس آن را با همان دامنه‌ای که پروفایل استفاده می‌کند اعمال کنید.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
فرمان نخست تغییر را بدون نصب چیزی پیش‌نمایش می‌کند و دومی مسیرهایی را فهرست می‌کند که پروفایل اکنون حمل می‌کند. مرجع Add-VpnConnectionRoute از Microsoft دامنه‌های تک‌کاربره و همه‌کاربره را مستند می‌کند؛ پروفایل همه‌کاربره به پارامتر دامنه خودش نیاز دارد، و فرمان تک‌کاربره در برابر پروفایل همه‌کاربره شکست می‌خورد یا در جای اشتباه می‌افتد.
وقتی پروفایل مدیریت می‌شود یا از کارخواه فروشنده می‌آید، تغییر به آن مالک تعلق دارد. انباشتن یک مسیر سیستمی دائمی روی یک سیاست اتصال کار می‌کند تا وقتی سیاست دوباره اعمال شود و مسیر از میان برود، که معمولاً در یک تماس پشتیبانی رخ می‌دهد نه در آزمون. آن خرابی خاموش است: مسیر ناپدید می‌شود، نام از حل‌شدن باز می‌ماند و کسی دو رویداد را به هم وصل نمی‌کند. تغییر را در سابقه خود مالک بگذارید تا اعمال دوباره بعدی آن را حمل کند نه پاک کند.
پس از اعمال، پروفایل را دوباره وصل کنید نه اینکه فرض کنید مسیر اثر کرده است. تغییرات مسیر روی اتصال زنده همیشه برداشته نمی‌شوند، و اتصال دوباره همان وضعیتی را هم بازتولید می‌کند که کاربران شما در واقع خواهند داشت.
بررسی کنید کارخواه در واقع کدام حل‌کننده را به کار برده است
مسیر بسته‌های نشانی‌گرفته به حل‌کننده را کنترل می‌کند. تصمیم نمی‌گیرد کدام نام‌ها باید به آنجا فرستاده شوند، و آن گزینش سازوکاری جداگانه است. در Windows، قواعد مؤثر فضای نام می‌توانند برای هر دامنه حل‌کننده‌ای برگزینند، در حالی که تنظیمات DNS پروفایل یک پیش‌فرض فراهم می‌کند. این دو لایه می‌توانند بدون تولید هیچ خطایی ناسازگار باشند، از این رو پرس‌وجوی مستقیم تنها نیمی از شاهد است.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
فرمان نخست سیاست فضای نام جاری را چاپ می‌کند و دومی مستقیماً از حل‌کننده خصوصی نام برنامه را می‌پرسد. پاسخ مستقیم اثبات می‌کند که مسیر و حل‌کننده کار می‌کنند؛ اثبات نمی‌کند که جست‌وجوی خود برنامه همان سرور را برگزیده است. آن را با یک جست‌وجوی عادی از همان نام و با پاسخی که برنامه می‌گیرد مقایسه کنید.
نهانگاه‌ها و DNS امن در سطح مرورگر را در نظر بگیرید، که می‌تواند برای نام‌های تایپ‌شده توسط کاربر حل‌کننده سیستم را به‌کلی دور بزند. پسوند جست‌وجو سرنخ گمراه‌کننده دیگری است: نام کوتاه را به نامی کاملاً واجد شرایط گسترش می‌دهد و هیچ ربطی به اینکه کدام سرور پاسخ می‌دهد ندارد.
در پایان دوباره وصل شوید و جست‌وجوی عادی را تکرار کنید، سپس تأیید کنید که مرور معمولی هنوز سیاست تأییدشده‌اش را دنبال می‌کند. جایگزین‌کردن حل‌کننده خصوصی با یک حل‌کننده عمومی تا نامی نامرتبط حل شود، اصلاح نیست و پرس‌وجوهای خصوصی را بی‌صدا به جایی می‌برد که هرگز قرار نبود بروند.