SharePoint bağlantıları yayımlanan URL'ler yüzünden VPN üzerinden kopuyor

VPN üzerinden bir SharePoint sayfası açılıyor ve ilk belge bağlantısı adres çubuğunda hiç olmayan bir adla başarısız oluyor. Bu boşluk tüm sorundur: sayfa bir URL'den geldi ve hizmet sonraki isteği başka bir URL'den biçimlendirdi. Yayımlanan URL sunucu tarafında bir karardır, bu yüzden onu istemcide düzeltmek yanlış uçtur. DNS veya yollara dokunmadan önce hizmetin hangi adı döndürdüğünü kontrol edin.

İlk sayfa ve sonraki istek farklı adlar kullanır

Sunucuya adresle ulaşan kullanıcı çalışan bir ana sayfa görür. O sayfadaki belge bağlantıları, hizmetin yayımladığını düşündüğü URL'den oluşturulur, tarayıcının yazdığından değil. Bunlar farklıysa, sonraki tıklama istemcinin hiç çözemediği bir ada gider.

Adresi bir kez girmek oluşturulan her bağlantıyı onarmaz ve adrese konan yer imi belge açılana kadar sorunu gizler.

Bu hatanın yalnızca tünel kullanıldıktan sonra ortaya çıkması nedeniyle VPN sorunu olarak yanlış okunması kolaydır. Aslında tünel işini yapar: isteği çalışan yolu veya eşleşen sertifikası olmayan bir ada taşır. İkisinden birini değiştirmeden önce iki soruyu ayırın. Biri paketin nereye gittiği, diğeri hizmetin hangi adı yayımlamayı seçtiğidir.

Dört kontrol, tek ad

Yayımlanan her ad dört bağımsız kontrolü geçmelidir. DNS onu gerçek istemci için çözmelidir, yönlendirme ve erişim ilkesi yolu izin vermelidir, TLS o adı doğrulamalıdır ve hizmet onu yayımlamak için yapılandırılmış olmalıdır.

Bir kontroldeki değişiklik diğerlerini yerine getirmez. Bir sertifika uyarısını kabul etmek ad çözümlemesinin onarımı değildir.

Aşağıdaki tablo kontrol listesinin sırasıdır. Başarısız olan ilk satırda durun, çünkü sonraki bir düzeltme önceki boşluğu telafi edemez.

Değiştirmeden önce yayımlama modelini okuyun

SharePoint Server dağıtımları farklıdır. Klasik web uygulamaları alternatif erişim eşlemeleri kullanabilir; burada iç URL sunucunun aldığı şeydir ve genel URL bağlantıları biçimlendirmek için kullandığı şeydir. Ana makine adlı site koleksiyonları farklı bir yaklaşım izler ve Microsoft'un rehberliğine göre AAM'i kullanamaz.

Microsoft'un planlama rehberi de AAM özelliklerini eski olarak işaretler ve yeni planlama için ana makine adlı site koleksiyonlarını önerir. Bu, dağıtım modelini sahibinin sorusu haline getirir, sizin yamadığınız bir varsayılan değil.

Bir eşleme değişikliği önermeden önce hangi modelin kullanıldığını belirleyin. Ana makine adlı bir dağıtıma AAM girdisi eklemek hiçbir şey yapmaz, klasik bir dağıtıma bir tane eklemek ise döndürülen her bağlantıyı birden değiştirir. İkisi de geniş etkili yapılandırma değişiklikleridir, bu yüzden aşamalı hazırlayın ve bir geri alma planı tutun. Bu, eski eşlemeleri modern bir ortama sokma önerisi değildir.

Başarısız işlemi izleyin, ana sayfayı değil

Başarısız isteğin gerçekte kullandığı hedefi, istemci uygulamasını, zamanı ve hatayı kaydedin. Bir tarayıcı ile bir masaüstü uygulaması aynı belgeye farklı proxy, VPN veya kimlik doğrulama yollarından gidebilir.

Tarayıcı başarılı olurken Office istemcisi başarısız olabilir ve bu fark, adı hangi bağlamın çözdüğüne dair bir ipucudur.

URL ve ağ aktarımı ikisi de çalışıyor ve hizmet işlemi hâlâ reddediyorsa, kalan sorun uygulama düzeyindedir. Belge izinleri ve ödeme durumu hizmetin sahibine aittir ve bir VPN yolu bağlantı sağlar, izin değil.

Aktarımı baştan sona kontrol edin

Denetimleri başarısız olan istemcide sırayla çalıştırın: yayımlanan adı çözün, sayfayı o adla isteyin, sonra belgenin URL'sini sayfanın kaynağından isteyin. Her adım bir kontrolü yalıtır.

Üç komut çözümlemeyi, TLS'i ve belge yolunu kapsar:

nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx

Çözümleme yalnızca tünel üzerinden başarısız oluyorsa, şüpheli split-DNS ilkesidir. TLS başarısız oluyorsa, uyarıyı tıklamak yerine sertifika adını yayımlanan adla karşılaştırın. İkisi de başarılı olur ve belge hâlâ açılmazsa, hata artık URL ile ilgili değildir.