Tautan SharePoint rusak melalui VPN karena URL yang diterbitkan

Halaman SharePoint terbuka melalui VPN, dan tautan dokumen pertama gagal dengan nama yang tidak pernah ada di bilah alamat. Celah itu adalah seluruh masalahnya: halaman datang dari satu URL, dan layanan memformat permintaan berikutnya dari URL lain. URL yang diterbitkan adalah keputusan di sisi server, jadi memperbaikinya di klien adalah ujung yang salah. Periksa nama mana yang dikembalikan layanan sebelum menyentuh DNS atau rute.

Halaman pertama dan permintaan berikutnya memakai nama yang berbeda

Pengguna yang mencapai server melalui alamat melihat halaman beranda yang berfungsi. Tautan dokumen di halaman itu dihasilkan dari URL yang diyakini layanan sedang diterbitkannya, bukan dari apa yang diketik peramban. Jika keduanya berbeda, klik berikutnya menuju nama yang belum pernah diresolusi klien.

Memasukkan alamat sekali tidak memperbaiki setiap tautan yang dihasilkan, dan markah ke alamat menyembunyikan masalah sampai dokumen dibuka.

Kegagalan ini mudah dibaca keliru sebagai masalah VPN karena baru muncul setelah terowongan dipakai. Kenyataannya terowongan menjalankan tugasnya: ia membawa permintaan ke nama yang tidak memiliki jalur yang berfungsi atau sertifikat yang cocok. Pisahkan kedua pertanyaan sebelum mengubah salah satunya. Yang satu adalah ke mana paket pergi, yang lain adalah nama mana yang dipilih layanan untuk diterbitkan.

Empat kendali, satu nama

Setiap nama yang diterbitkan harus melewati empat kendali independen. DNS harus meresolusinya untuk klien yang sebenarnya, perutean dan kebijakan akses harus mengizinkan jalurnya, TLS harus memvalidasi nama itu, dan layanan harus dikonfigurasi untuk menerbitkannya.

Perubahan pada satu kendali tidak menjalankan yang lain. Menerima peringatan sertifikat bukan perbaikan resolusi nama.

Tabel di bawah adalah urutan daftar periksa. Berhenti pada baris pertama yang gagal, karena perbaikan kemudian tidak dapat menutupi celah sebelumnya.

Baca model penerbitan sebelum mengubahnya

Penerapan SharePoint Server berbeda-beda. Aplikasi web klasik dapat memakai pemetaan akses alternatif, di mana URL internal adalah yang diterima server dan URL publik adalah yang dipakai untuk memformat tautan. Koleksi situs bernama host mengikuti pendekatan berbeda dan, menurut panduan Microsoft, tidak dapat memakai AAM.

Panduan perencanaan Microsoft juga menandai fitur AAM sebagai usang dan merekomendasikan koleksi situs bernama host untuk perencanaan baru. Itu menjadikan model penerapan sebagai pertanyaan bagi pemiliknya, bukan nilai bawaan yang Anda tambal.

Tetapkan model mana yang dipakai sebelum mengusulkan perubahan pemetaan. Menambahkan entri AAM ke penerapan bernama host tidak melakukan apa pun, dan menambahkan satu ke penerapan klasik mengubah setiap tautan yang dikembalikan sekaligus. Keduanya perubahan konfigurasi dengan dampak luas, jadi siapkan secara bertahap dan pertahankan rencana pengembalian. Ini bukan rekomendasi untuk memasukkan pemetaan lama ke lingkungan modern.

Ikuti operasi yang gagal, bukan halaman beranda

Catat tujuan yang sebenarnya dipakai permintaan yang gagal, aplikasi klien, waktu, dan galat. Peramban dan aplikasi desktop dapat menempuh jalur proxy, VPN, atau autentikasi yang berbeda ke dokumen yang sama.

Peramban dapat berhasil sementara klien Office gagal, dan perbedaan itu adalah petunjuk tentang konteks mana yang meresolusi nama.

Jika URL dan penyerahan jaringan keduanya berfungsi dan layanan masih menolak operasi, masalah yang tersisa ada di tingkat aplikasi. Izin dokumen dan status pembayaran milik pemilik layanan, dan rute VPN menyediakan konektivitas, bukan izin.

Periksa penyerahan dari ujung ke ujung

Jalankan pemeriksaan berurutan pada klien yang gagal: resolusikan nama yang diterbitkan, minta halaman dengan nama itu, lalu minta URL dokumen dari sumber halaman. Setiap langkah mengisolasi satu kendali.

Tiga perintah mencakup resolusi, TLS, dan jalur 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 resolusi gagal hanya melalui terowongan, kebijakan split-DNS adalah tersangkanya. Jika TLS gagal, bandingkan nama sertifikat dengan nama yang diterbitkan alih-alih mengklik lewat. Jika keduanya berhasil dan dokumen masih gagal, galat bukan lagi tentang URL.