Always On VPN bir LAN erişimi değildir: kaynak denetim listesi

Always On bir bağlantı yaşam döngüsüdür: profil oturum açmada veya öncesinde bağlanır ve kullanıcı hiçbir şeye basmadan yeniden bağlanır. Bu, her özel hedefin, protokolün ve kullanıcının izinli olduğu anlamına gelmez. Asıl soru, dağıtılan profilin gerçekte hangi kaynakları sunduğudur ve bu yanıt Connected rozetine bakmayı değil, her kaynak için ayrı denetim yapmayı gerektirir.

Adım 1: Kaynağı test etmeden önce yazın

Her uygulama için gerçek ortamdan alınan kısa bir kayıt tutun: ad, hedef öneki, hizmet ve bağlantı noktası, tünel rolü, kimlik grubu ve çözümleyici yolu.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Kayıt dört ayrı soruyu zorunlu kılar. Yol, adresin nereye gittiğini belirler; DNS ilkesi, istemcinin adresi nasıl öğrendiğini belirler; trafik filtresi, o trafiğin bağlantıyı kullanıp kullanamayacağını belirler; hedefin güvenlik duvarı ve uygulama izinleri isteğin kabul edilip edilmeyeceğini belirler. Bu dördünün hiçbiri bağlı bir tünelden doğmaz.

Adım 2: Hangi tünelin taşıması gerektiğini belirleyin

Windows Always On VPN’de cihaz tüneli ve kullanıcı tüneli vardır ve bunlar ayrı sertifikalar ve kapsamlarla ayrı profiller olarak yapılandırılır. Cihaz tüneli genellikle yalnızca oturum açmadan önce gereken altyapıyı, örneğin yönetim ve etki alanı hizmetlerini taşır; çalışanların geniş uygulama erişimi kullanıcı tünelinindir.

Trafik filtreleri cihaz tünelinin bir özelliğidir, bu yüzden Microsoft örneği bunları yönetim trafiği için kullanır. Bu örneği genel bir kaynak profiline kopyalamak, bağlanan ama yanlış kümeyi taşıyan bir tünel verir. Etkin bağlantıyı Get-VpnConnection ile doğrulayın ve o bağlantının altında test edin.

Adım 3: Gerçek adres için yolu doğrulayın

Adı bir kez çözün, ardından yolu denetleyin: Find-NetRoute -RemoteIPAddress 10.20.5.10 seçilen arabirimi, sonraki atlamayı ve kaynak adresi bildirir. Arabirim fiziksel bağdaştırıcıysa önek tünelin yol kümesinde yoktur ya da istemci onu bölünmüş tünelle dışlamıştır. Yerel bir yol eklemek yerine profil tanımıyla karşılaştırın.

Yerel bir route add testi geçirebilir ve sonraki ilke yenilenmesinde kaybolabilir, bu yüzden değişiklik yönetilen profile aittir. Öneki hem kullanıcı hem cihaz profilinde denetleyin ve bölünmüş tünel ayarını kontrol edin: tam tünel her önek için yol gerektirmez, bölünmüş tünel taşıdığı her özel önek için bir tane gerektirir.

Adım 4: Özel ad çözümlemesini ayrı test edin

Özel adların kendi ilke yolu vardır. Profil NRPT kuralları ve DNS son eki arama listesi sağlayabilir; bunlar tünel ayakta olduğu sürece geçerlidir. İstemcinin gerçekte ne aldığını Get-DnsClientNrptPolicy ile okuyun, sonra aynı oturumda bir ad ve bir adres test edin. Adresler çalışırken adlar başarısız oluyorsa sorun çözümleyicidedir; ikisi de başarısızsa yoldadır.

Bir ad, tünelin yolları dışındaki bir adrese de çözülebilir ve bu başarı ile zaman aşımını karıştırır. Dönen adresi kaydınızdaki önekle karşılaştırın; farklıysa özel bölge genel veya alternatif bir adresle yanıt veriyordur ve eşleşen yol tasarlanan yol değildir.

Adım 5: Filtreleri, kimliği ve uygulamanın kendi kapısını denetleyin

Trafik filtreleri hangi protokollerin ve bağlantı noktalarının cihaz tünelini kullanabileceğini sınırlar ve dar bir küme yolun taşıyacağı bir kaynağı engelleyebilir. Profil bağlantıyı bir gruba atar, ancak kaynağın kendi yetkilendirmesi vardır: bağlanabilen bir kullanıcı dosya sunucusu tarafından otomatik olarak kabul edilmez.

Yönetilen profili sahibi üzerinden değiştirin, ister Intune, ister ProfileXML dağıtımı ya da bir operasyon betiği olsun, sonra normal yeniden bağlanmadan ve yeniden başlatmadan sonra yeniden test edin: olağan arıza eski bir yerel yol veya yalnızca bir kez uygulanmış profildir. Profil sürümünü test sonucunun yanında tutun.