IIS Manager jarak jauh: periksa dulu alamat WMSVC sendiri
WMSVC mendengarkan pada pengikatan HTTPS-nya sendiri, bukan pada situs Anda. Bandingkan titik akhir itu, pembatasan IP-nya, dan sertifikatnya sebelum menyalahkan rute VPN.
Situs Anda menjawab pada 443 melalui terowongan, dan IIS Manager tetap tidak dapat terhubung ke server. Kombinasi hasil itu bukan kontradiksi, karena situs web dan titik akhir administrasi jarak jauh adalah dua pendengar dengan dua konfigurasi dan dua set aturan akses. Yang satu milik Web Management Service, WMSVC, dan memiliki alamat, port, sertifikat, serta pembatasan IPv4 sendiri. Periksa titik akhir itu sebelum Anda menyentuh satu rute pun.
Dua pendengar, dua masalah berbeda
Permintaan ke situs mencapai pengikatan HTTP.sys untuk situs itu, yang ditentukan per situs dan per protokol dalam konfigurasi applicationHost. Permintaan dari IIS Manager mencapai WMSVC, yang secara default menjawab HTTPS pada TCP 8172 dan dikonfigurasi di tingkat server. Tidak ada hal dalam pengikatan situs yang mengubah tempat WMSVC mendengarkan, dan tidak ada hal dalam WMSVC yang mengubah alamat mana yang dijawab situs. Keduanya berbagi satu mesin dan satu penyimpanan sertifikat, dan di situlah kesamaannya berakhir.
Jadi Test-NetConnection yang berhasil terhadap port 443 memberi tahu Anda bahwa pendengar situs dapat dijangkau, dan sama sekali tidak memberi tahu apa pun tentang administrasi.
Temukan alamat yang sebenarnya diikat oleh WMSVC
Tanyakan kepada server apa yang sedang didengarkannya, bukan apa yang dikonfigurasi bertahun-tahun lalu. Get-NetTCPConnection -LocalPort 8172 -State Listen mencetak alamat lokal, dan nilai 0.0.0.0 atau :: berarti semua alamat, sedangkan alamat tertentu berarti hanya alamat itu. Jika alamat server pernah diubah, pendengar yang masih terpatok pada alamat lama adalah persis kegagalan yang ditangkap pemeriksaan ini.
Nilai yang dikonfigurasi berada di halaman Management Service pada IIS Manager di node server, dan di baliknya di administration.config di dalam direktori konfigurasi inetsrv. Bandingkan keduanya: apa yang dikatakan berkas, dan ke alamat apa soket sebenarnya terikat.
Lalu jalankan Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed dari klien VPN yang terdampak dan baca alamat yang diresolusikan serta alamat sumber yang dipilih. Jawaban DNS yang berbeda di VPN cukup umum sehingga layak disingkirkan lebih awal. Simpan nama host dan port yang persis itu di tiket, karena perbandingan nanti dengan nama lain tidak membuktikan apa pun tentang perubahan yang Anda buat.
Baca alamat sumber yang dilihat server
Pembatasan IPv4 WMSVC dievaluasi terhadap alamat yang tiba di server, yang tidak selalu merupakan alamat yang diyakini laptop Anda. Jika kumpulan VPN diterjemahkan di suatu titik di sepanjang jalur, server melihat alamat hasil terjemahan dan daftar izin yang dibangun dari alamat dalam klien akan menolaknya. Penolakan itu tampak seperti kegagalan koneksi dari sisi klien, itulah sebabnya sering salah didiagnosis sebagai masalah perutean.
Gunakan keluaran terperinci dari uji TCP, ditambah tabel koneksi server sendiri, untuk melihat alamat sumber mana yang benar-benar tiba sebelum Anda mengubah daftar pembatasan.
Ubah pengikatan sebagai perubahan layanan
WMSVC harus dihentikan sebelum konfigurasinya diedit, jadi rencanakan sebagai perubahan dengan jalur manajemen lain yang tersedia, seperti akses konsol atau sesi jarak jauh yang tidak bergantung pada IIS Manager. Hentikan layanan, terapkan perubahan alamat, port, atau sertifikat, lalu mulai lagi dan pastikan pendengar berpindah. Siapa pun yang memakai administrasi IIS jarak jauh kehilangan sesinya selama jendela itu. Beri tahu administrator lain sebelum jendela dibuka; menemukannya di tengah perubahan adalah cara dua orang berakhir mengedit pendengar yang sama.
Memilih semua alamat adalah opsi yang sah, tetapi perlakukan itu sebagai keputusan akses, bukan jalan pintas. Memperluas pendengar sementara daftar pembatasan tetap terbuka adalah cara titik akhir manajemen berakhir terekspos di jaringan yang tidak diniatkan siapa pun. Jika server punya beberapa NIC, batasi pendengar ke antarmuka manajemen, biarkan jalur data, dan pastikan situs tetap menjawab pada alamatnya sendiri.
Sertifikat yang disajikan WMSVC dipilih terpisah dari sertifikat situs. Jika Anda mengubah alamat, pastikan sertifikat masih cocok dengan nama host yang dipakai klien, atau koneksi akan gagal nanti pada langkah TLS dengan keluhan yang tidak ada hubungannya dengan perutean.
Pisahkan keterjangkauan dari kepercayaan dan izin
Setelah TCP berhasil, kegagalan yang tersisa berurutan: kepercayaan TLS untuk sertifikat manajemen, lalu autentikasi Windows, lalu izin IIS Manager yang diberikan ke akun itu. Masing-masing menghasilkan kesalahan berbeda, dan tidak satu pun diperbaiki oleh rute atau aturan firewall. Baca teks kesalahan secara harfiah alih-alih memulai ulang layanan lagi.
Kerjakan empat pemeriksaan dalam urutan itu, titik akhir, pendengar, alamat sumber, kepercayaan, dan Anda biasanya akan menemukan pengikatan usang sebelum menemukan masalah jaringan.