IIS Manager jauh: semak alamat WMSVC sendiri dahulu

Tapak anda menjawab pada 443 melalui terowong, dan IIS Manager masih tidak dapat menyambung ke pelayan. Pasangan keputusan ini bukan percanggahan, kerana tapak web dan titik akhir pentadbiran jauh ialah dua pendengar dengan dua konfigurasi dan dua set peraturan akses. Yang pentadbiran milik Web Management Service, WMSVC, dan mempunyai alamat, port, sijil serta sekatan IPv4 sendiri. Semak titik akhir itu sebelum anda menyentuh satu laluan pun.

Dua pendengar, dua masalah berbeza

Permintaan ke tapak sampai ke pengikatan HTTP.sys tapak itu, yang ditakrifkan mengikut tapak dan protokol dalam konfigurasi applicationHost. Permintaan daripada IIS Manager sampai ke WMSVC, yang secara lalai menjawab HTTPS pada TCP 8172 dan dikonfigurasikan pada peringkat pelayan. Tiada apa dalam pengikatan tapak mengubah tempat WMSVC mendengar, dan tiada apa dalam WMSVC mengubah alamat yang dijawab oleh tapak. Kedua-duanya berkongsi satu mesin dan satu stor sijil, dan di situlah persamaan berakhir.

Jadi Test-NetConnection yang berjaya terhadap port 443 memberitahu anda pendengar tapak boleh dicapai, dan tidak memberitahu apa-apa tentang pentadbiran.

Cari alamat yang sebenarnya diikat oleh WMSVC

Tanya pelayan apa yang sedang didengarnya, bukan apa yang dikonfigurasikan bertahun-tahun lalu. Get-NetTCPConnection -LocalPort 8172 -State Listen mencetak alamat tempatan, dan nilai 0.0.0.0 atau :: bermaksud semua alamat, manakala alamat tertentu bermaksud hanya alamat itu. Jika pelayan pernah menukar pengealamatan, pendengar yang masih terpaku pada alamat lama ialah tepat kegagalan yang ditangkap oleh semakan ini.

Nilai yang dikonfigurasikan terletak pada halaman Management Service IIS Manager pada nod pelayan, dan di belakangnya dalam administration.config di direktori konfigurasi inetsrv. Bandingkan keduanya: apa yang dikatakan fail, dan apa yang sebenarnya diikat oleh soket.

Kemudian jalankan Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed dari klien VPN yang terjejas dan baca alamat yang diselesaikan serta alamat sumber yang dipilih. Jawapan DNS yang berbeza pada VPN cukup biasa untuk disingkirkan lebih awal. Simpan nama hos dan port yang tepat itu dalam tiket, kerana perbandingan kemudian dengan nama lain tidak membuktikan apa-apa tentang perubahan yang anda buat.

Baca alamat sumber yang dilihat oleh pelayan

Sekatan IPv4 WMSVC dinilai terhadap alamat yang tiba di pelayan, yang bukan selalu alamat yang dianggap ada oleh komputer riba anda. Jika kolam VPN diterjemahkan di suatu tempat di sepanjang laluan, pelayan melihat alamat terjemahan dan senarai benarkan yang dibina daripada alamat dalaman klien akan menolaknya. Penolakan itu kelihatan seperti kegagalan sambungan dari sisi klien, sebab itulah ia sering salah didiagnosis sebagai masalah penghalaan.

Gunakan output terperinci ujian TCP, bersama jadual sambungan pelayan sendiri, untuk melihat alamat sumber mana yang benar-benar tiba sebelum anda mengedit senarai sekatan.

Tukar pengikatan sebagai perubahan perkhidmatan

WMSVC mesti dihentikan sebelum konfigurasinya diedit, jadi rancangkannya sebagai perubahan dengan laluan pentadbiran lain tersedia, seperti akses konsol atau sesi jauh yang tidak bergantung pada IIS Manager. Hentikan perkhidmatan, gunakan perubahan alamat, port atau sijil, kemudian mulakannya dan sahkan pendengar telah berpindah. Sesiapa sahaja yang menggunakan pentadbiran IIS jauh kehilangan sesinya dalam tempoh itu. Beritahu pentadbir lain sebelum tetingkap dibuka; menemukannya di tengah-tengah perubahan ialah cara dua orang akhirnya mengedit pendengar yang sama.

Memilih semua alamat ialah pilihan yang sah, tetapi anggapnya sebagai keputusan akses, bukan jalan pintas. Meluaskan pendengar sementara senarai sekatan kekal terbuka ialah cara titik akhir pentadbiran terdedah pada rangkaian yang tidak dimaksudkan oleh sesiapa. Jika pelayan mempunyai beberapa NIC, hadkan pendengar kepada antara muka pentadbiran, biarkan laluan data, dan sahkan tapak masih menjawab pada alamatnya sendiri.

Sijil yang dibentangkan oleh WMSVC dipilih secara berasingan daripada sijil tapak. Jika anda menukar alamat, sahkan sijil masih sepadan dengan nama hos yang digunakan oleh klien, jika tidak sambungan akan gagal kemudian pada langkah TLS dengan aduan yang tiada kaitan dengan penghalaan.

Pisahkan kebolehcapaian daripada kepercayaan dan kebenaran

Setelah TCP berjaya, kegagalan yang tinggal adalah mengikut urutan: kepercayaan TLS untuk sijil pentadbiran, kemudian pengesahan Windows, kemudian kebenaran IIS Manager yang diberikan kepada akaun itu. Setiap satu menghasilkan ralat berbeza, dan tiada satu pun diperbaiki oleh laluan atau peraturan tembok api. Baca teks ralat secara literal daripada memulakan semula perkhidmatan itu lagi.

Lakukan empat semakan dalam urutan itu, titik akhir, pendengar, alamat sumber, kepercayaan, dan anda biasanya akan menemui pengikatan lama sebelum menemui masalah rangkaian.