Bölünmüş tuneliniz tətbiqə çatır, amma onun DNS serverinə yox
Bölünmüş tunel tətbiq alt şəbəkəsini marşrutlaşdıra, lakin yanındakı həlledicini düşürə bilər. Host marşrutunu əlavə edin, sonra Windows-un hansı serveri seçdiyini yoxlayın.
Tətbiqin alt şəbəkəsini marşrutlaşdırmaq bölünmüş tunelin aşkar hissəsidir və işin hamısı deyil. Həlledici çox vaxt xidmət etdiyi tətbiqdən fərqli ünvanda oturur, buna görə işləyən tunel axtarışı ondan kənarda qoya bilər. 10.80.0.0/16 daşıyan və başqa heç nə daşımayan profil 10.90.0.53 üçün sorğunu yerli interfeysdən göndərir, orada isə heç bir özəl zona yoxdur. Həlledici marşrutunu əlavə edin, sonra məsələnin ikinci yarısına baxın: müştəri həqiqətən hansı serveri seçir.
Mif: bir marşrut bütün xidməti əhatə edir
Bölünmüş tunel bağlantıdan keçən təyinatların siyahısıdır, xidmətin təsviri deyil. Tətbiq alt şəbəkəsi və həlledici ünvanı iki təyinatdır və profil birini digəri olmadan daşıya bilər. Bu baş verdikdə tətbiq ünvanla əlçatan olur, adı isə uğursuz olur; bu, marşrut boşluğundan çox DNS nasazlığı kimi görünür.
Həlledicinin ətrafındakı alt şəbəkə də avtomatik əhatə olunmur. Tək ünvana host marşrutu həmin həlledici üçün kifayətdir və qonşularını açmır. Host marşrutunun mənası budur: dizaynca dar və növbəti xidmət eyni alt şəbəkədə görünəndə unutmaq asandır.
Axtarışın işləməsi üçün üç şey doğru olmalıdır: müştəri həlledici ünvanını tuneldən keçirsin, şlüz həmin sorğunu qəbul edib yönəltsin və həlledici aldığı mənbəni qəbul etsin. Cavab da razılaşdırılmış yolla geri qayıtmalıdır. Bunlardan biri buraxılarsa simptom eyni olur, buna görə konfiqurasiyaya toxunmadan əvvəl ünvan cədvəlini yazmağa dəyər.
Profilin hansı ünvanları daşımalı olduğunu müəyyən edin
Təyinatları sıra ilə sadalayın: tətbiq şəbəkəsi, həlledici ünvanı və tunelin özünü sonlandıran ictimai son nöqtə. Üçüncüsü heç vaxt tunelin içinə marşrutlaşdırılmamalıdır, çünki xarici bağlantı tuneldən əvvəl mövcud olan yola ehtiyac duyur.
| 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 |
DNS üçün həm UDP, həm də TCP daxil edin, çünki tətbiqlərdən UDP ilə yanaşı TCP-ni də dəstəkləmək gözlənilir və bloklanmış TCP yolu təmiz deyil, yavaş və qismən nasazlıqlar yaradır. Özəl zona IPv6 ilə də xidmət edilirsə, ekvivalent host istisnası IPv6 ünvanı və prefiksi istifadə edir və ayrıca qeyddir.
Nəyisə əlavə etməzdən əvvəl profilin artıq nələri əhatə etdiyini qeyd edin. Təkrar marşrut zərərsizdir, lakin gözlənilməz mövcud marşrut profilə sizə veriləndən fərqli ünvan planı üçün dizayn edildiyini deyir.
Host marşrutunu bağlantı sahibi vasitəsilə əlavə edin
Yerli olaraq idarə olunan doğma Windows profilində marşrut maşının qlobal marşrut cədvəlinə deyil, bağlantıya aiddir. Əlavə etməni əvvəlcə önizləyin, sonra profilin istifadə etdiyi eyni əhatə ilə tətbiq edin.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Birinci əmr heç nə quraşdırmadan dəyişikliyi önizləyir, ikincisi isə profilin hazırda daşıdığı marşrutları sadalayır. Microsoft-un Add-VpnConnectionRoute üçün istinadı istifadəçi üzrə və bütün istifadəçilər üzrə əhatələri sənədləşdirir; bütün istifadəçilər profili öz əhatə parametrinə ehtiyac duyur və bütün istifadəçilər profilinə qarşı istifadəçi üzrə əmr uğursuz olur və ya yanlış yerə düşür.
Profil idarə olunursa və ya satıcı müştərisindən gəlirsə, dəyişiklik həmin sahibə aiddir. Bağlantı siyasətinin üstünə daimi sistem marşrutu yığmaq siyasət yenidən tətbiq olunana və marşrut yoxa çıxana qədər işləyir; bu isə adətən sınaq zamanı deyil, dəstək zəngi zamanı baş verir. Bu nasazlıq səssizdir: marşrut itir, ad həll olunmağı dayandırır və heç kim iki hadisəni bağlamır. Dəyişikliyi sahibin öz qeydinə yazın ki, növbəti yenidən tətbiq onu silsin deyil, daşısın.
Tətbiqdən sonra marşrutun qüvvəyə mindiyini güman etmək əvəzinə profili yenidən qoşun. Canlı bağlantıda marşrut dəyişiklikləri həmişə tutulmur və yenidən qoşulma istifadəçilərinizin həqiqətən yaşayacağı vəziyyəti də bərpa edir.
Müştərinin həqiqətən hansı həlledicini istifadə etdiyini yoxlayın
Marşrut həllediciyə ünvanlanmış paketləri idarə edir. Hansı adların ora göndəriləcəyinə qərar vermir və bu seçim ayrıca mexanizmdir. Windows-da qüvvədə olan ad sahəsi qaydaları domen üzrə həlledici seçə bilər, profilin DNS parametrləri isə susmaya görə dəyər verir. Bu iki qat heç bir xəta yaratmadan ziddiyyət təşkil edə bilər, buna görə birbaşa sorğu dəlilin yalnız yarısıdır.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Birinci əmr qüvvədə olan ad sahəsi siyasətini çap edir, ikincisi isə özəl həlledicidən birbaşa tətbiqin adını soruşur. Birbaşa cavab yolun və həlledicinin işlədiyini sübut edir; tətbiqin öz axtarışının o serveri seçdiyini sübut etmir. Onu eyni adın adi axtarışı ilə və tətbiqin aldığı cavabla müqayisə edin.
Keşləri və brauzer səviyyəsində təhlükəsiz DNS-i nəzərə alın; bu, istifadəçinin yazdığı adlar üçün sistem həlledicisini tamamilə yan keçə bilər. Axtarış şəkilçisi başqa bir yanıltıcı izdir: qısa adı tam kvalifikasiyalı ada genişləndirir və hansı serverin cavab verdiyi ilə heç bir əlaqəsi yoxdur.
Sonda yenidən qoşulun və adi axtarışı təkrarlayın, sonra adi gəzintinin hələ də təsdiqlənmiş siyasətinə əməl etdiyini təsdiqləyin. Özəl həlledicini ictimai biri ilə əvəz etmək ki, əlaqəsiz ad həll olunsun, düzəliş deyil və özəl sorğuları heç vaxt nəzərdə tutulmadığı yerə səssizcə köçürür.