Pautan SharePoint terputus melalui VPN kerana URL yang diterbitkan

Halaman SharePoint dibuka melalui VPN, dan pautan dokumen pertama gagal dengan nama yang tidak pernah ada dalam bar alamat. Jurang itu ialah keseluruhan masalah: halaman datang dari satu URL, dan perkhidmatan memformat permintaan seterusnya dari URL lain. URL yang diterbitkan ialah keputusan di sebelah pelayan, jadi membetulkannya pada klien ialah hujung yang salah. Semak nama yang dipulangkan perkhidmatan sebelum menyentuh DNS atau laluan.

Halaman pertama dan permintaan seterusnya menggunakan nama berbeza

Pengguna yang sampai ke pelayan melalui alamat melihat halaman utama yang berfungsi. Pautan dokumen pada halaman itu dijana daripada URL yang perkhidmatan percaya sedang diterbitkannya, bukan daripada apa yang ditaip pelayar. Jika kedua-duanya berbeza, klik seterusnya pergi ke nama yang tidak pernah diselesaikan oleh klien.

Memasukkan alamat sekali tidak membaiki setiap pautan yang dijana, dan penanda buku ke alamat menyembunyikan masalah sehingga dokumen dibuka.

Kegagalan ini mudah disalahtafsir sebagai masalah VPN kerana ia hanya muncul selepas terowong digunakan. Pada hakikatnya terowong menjalankan tugasnya: ia membawa permintaan ke nama yang tiada laluan berfungsi atau tiada sijil yang sepadan. Pisahkan kedua-dua soalan sebelum menukar mana-mana satu. Satu ialah ke mana paket pergi, satu lagi ialah nama yang dipilih perkhidmatan untuk diterbitkan.

Empat kawalan, satu nama

Setiap nama yang diterbitkan mesti melalui empat kawalan bebas. DNS mesti menyelesaikannya untuk klien sebenar, penghalaan dan dasar akses mesti membenarkan laluan, TLS mesti mengesahkan nama itu, dan perkhidmatan mesti dikonfigurasikan untuk menerbitkannya.

Perubahan pada satu kawalan tidak melaksanakan yang lain. Menerima amaran sijil bukan pembaikan penyelesaian nama.

Jadual di bawah ialah susunan senarai semak. Berhenti pada baris pertama yang gagal, kerana pembaikan kemudian tidak boleh mengimbangi jurang terdahulu.

Baca model penerbitan sebelum mengubahnya

Pemasangan SharePoint Server berbeza-beza. Aplikasi web klasik boleh menggunakan pemetaan akses alternatif, di mana URL dalaman ialah apa yang diterima pelayan dan URL awam ialah apa yang digunakan untuk memformat pautan. Koleksi laman bernama hos mengikut pendekatan berbeza dan, menurut panduan Microsoft, tidak boleh menggunakan AAM.

Panduan perancangan Microsoft juga menandakan ciri AAM sebagai lapuk dan mengesyorkan koleksi laman bernama hos untuk perancangan baharu. Itu menjadikan model pemasangan sebagai persoalan kepada pemiliknya, bukan lalai yang anda tampal.

Tetapkan model mana yang digunakan sebelum mencadangkan perubahan pemetaan. Menambah entri AAM pada pemasangan bernama hos tidak melakukan apa-apa, dan menambah satu pada pemasangan klasik mengubah setiap pautan yang dipulangkan sekali gus. Kedua-duanya perubahan konfigurasi dengan kesan luas, jadi sediakan secara berperingkat dan kekalkan pelan pengunduran. Ini bukan cadangan untuk membawa pemetaan lama ke persekitaran moden.

Ikuti operasi yang gagal, bukan halaman utama

Rekod destinasi yang sebenarnya digunakan oleh permintaan yang gagal, aplikasi klien, masa dan ralat. Pelayar dan aplikasi desktop boleh mengambil laluan proksi, VPN atau pengesahan yang berbeza ke dokumen yang sama.

Pelayar mungkin berjaya manakala klien Office gagal, dan perbezaan itu ialah petunjuk tentang konteks mana yang menyelesaikan nama.

Jika URL dan penyerahan rangkaian kedua-duanya berfungsi dan perkhidmatan masih menolak operasi, masalah yang tinggal berada pada peringkat aplikasi. Kebenaran dokumen dan status pembayaran milik pemilik perkhidmatan, dan laluan VPN menyediakan sambungan, bukan kebenaran.

Semak penyerahan dari hujung ke hujung

Jalankan semakan mengikut urutan pada klien yang gagal: selesaikan nama yang diterbitkan, minta halaman dengan nama itu, kemudian minta URL dokumen dari sumber halaman. Setiap langkah mengasingkan satu kawalan.

Tiga arahan merangkumi penyelesaian, TLS dan laluan dokumen:

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

Jika penyelesaian gagal hanya melalui terowong, dasar split-DNS ialah suspek. Jika TLS gagal, bandingkan nama sijil dengan nama yang diterbitkan dan bukan klik melaluinya. Jika kedua-duanya berjaya dan dokumen masih gagal, ralat itu bukan lagi tentang URL.