SharePoint linkləri dərc edilmiş URL-lər üzündən VPN üzərindən açılmır

VPN üzərindən SharePoint səhifəsi açılır və ilk sənəd linki ünvan çubuğunda heç vaxt olmayan adla uğursuz olur. Bu boşluq bütün problemdir: səhifə bir URL-dən gəldi, xidmət isə növbəti sorğunu başqa bir URL-dən formatladı. Dərc edilmiş URL server tərəfində verilən qərardır, ona görə də onu müştəridə düzəltmək yanlış tərəfdir. DNS-ə və ya marşrutlara toxunmadan əvvəl xidmətin hansı adı qaytardığını yoxlayın.

İlk səhifə və növbəti sorğu fərqli adlardan istifadə edir

Serverə ünvanla çatan istifadəçi işlək əsas səhifə görür. Həmin səhifədəki sənəd linkləri xidmətin dərc etdiyini düşündüyü URL-dən yaradılır, brauzerin yazdığından deyil. Bunlar fərqlənirsə, növbəti klik müştərinin heç vaxt həll etmədiyi ada gedir.

Ünvanı bir dəfə daxil etmək hər yaradılmış linki bərpa etmir və ünvana qoyulan əlfəcin sənəd açılana qədər problemi gizlədir.

Bu nasazlığı VPN problemi kimi səhv oxumaq asandır, çünki o, yalnız tunel istifadəyə verildikdən sonra görünür. Əslində tunel öz işini görür: sorğunu işlək marşrutu və ya uyğun sertifikatı olmayan ada daşıyır. Hər ikisini dəyişməzdən əvvəl iki sualı ayırın. Biri paketin hara getdiyi, digəri xidmətin hansı adı dərc etməyi seçdiyidir.

Dörd nəzarət, bir ad

Hər dərc edilmiş ad dörd müstəqil nəzarətdən keçməlidir. DNS onu faktiki müştəri üçün həll etməli, marşrutlaşdırma və giriş siyasəti yola icazə verməli, TLS həmin ad üçün doğrulamalı və xidmət onu dərc etmək üçün konfiqurasiya olunmalıdır.

Bir nəzarətdə dəyişiklik digərlərini yerinə yetirmir. Sertifikat xəbərdarlığını qəbul etmək ad həllinin bərpası deyil.

Aşağıdakı cədvəl yoxlama siyahısının sırasıdır. Uğursuz olan ilk sətirdə dayanın, çünki sonrakı düzəliş əvvəlki boşluğu kompensasiya edə bilməz.

Dəyişməzdən əvvəl dərc modelini oxuyun

SharePoint Server quraşdırmaları fərqlənir. Klassik veb tətbiqləri alternativ giriş xəritələri istifadə edə bilər; burada daxili URL serverin qəbul etdiyi, ictimai URL isə linkləri formatlamaq üçün istifadə etdiyi ünvandır. Host adlı sayt kolleksiyaları başqa yanaşma tutur və Microsoft-un təlimatına görə AAM istifadə edə bilməz.

Microsoft-un planlama təlimatı həmçinin AAM funksiyalarını köhnəlmiş kimi qeyd edir və yeni planlama üçün host adlı sayt kolleksiyalarını tövsiyə edir. Bu, quraşdırma modelini onun sahibinin sualına çevirir, sizin yamaq vura biləcəyiniz standart deyil.

Xəritə dəyişikliyi təklif etməzdən əvvəl hansı modelin istifadədə olduğunu müəyyən edin. Host adlı quraşdırmaya AAM qeydi əlavə etmək heç nə etmir, klassik quraşdırmaya bir qeyd əlavə etmək isə bütün qaytarılan linkləri birdən dəyişir. Hər ikisi geniş təsir dairəsi olan konfiqurasiya dəyişiklikləridir, ona görə də onları mərhələli hazırlayın və geri qaytarma planını saxlayın. Bu, köhnə xəritələri müasir mühitə gətirmək tövsiyəsi deyil.

Uğursuz əməliyyatı izləyin, əsas səhifəni deyil

Uğursuz sorğunun faktiki istifadə etdiyi təyinatı, müştəri tətbiqini, vaxtı və xətanı qeyd edin. Brauzer və masaüstü tətbiq eyni sənədə fərqli proxy, VPN və ya autentifikasiya yolları ilə gedə bilər.

Brauzer uğur qazana bilər, Office müştərisi isə uğursuz ola bilər və bu fərq adı hansı kontekstin həll etdiyinə dair ipucudur.

URL və şəbəkə ötürməsi işləyirsə, xidmət isə əməliyyatı yenə rədd edirsə, qalan problem tətbiq səviyyəsindədir. Sənəd icazələri və check-out vəziyyəti xidmət sahibinə aiddir, VPN marşrutu isə icazə deyil, bağlantı təmin edir.

Ötürməni başdan sona yoxlayın

Yoxlamaları uğursuz olan müştəridə sıra ilə aparın: dərc edilmiş adı həll edin, səhifəni həmin adla sorğulayın, sonra səhifə mənbəyindən sənədin URL-ini sorğulayın. Hər addım bir nəzarəti təcrid edir.

Üç əmr həlli, TLS-i və sənəd yolunu əhatə edir:

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

Həll yalnız tuneldən keçəndə uğursuz olursa, şübhəli split-DNS siyasətidir. TLS uğursuz olursa, sertifikat adını dərc edilmiş adla müqayisə edin, keçməyə çalışmayın. Hər ikisi uğurlu olub sənəd yenə uğursuz olursa, xəta artıq URL ilə bağlı deyil.