IIS Manager remoto: controlla prima l'indirizzo di WMSVC

Il tuo sito risponde sulla 443 attraverso il tunnel, e IIS Manager continua a non connettersi al server. Questa coppia di risultati non è una contraddizione, perché il sito web e l'endpoint di amministrazione remota sono due listener con due configurazioni e due insiemi di regole di accesso. Quello di gestione appartiene al Web Management Service, WMSVC, e ha un proprio indirizzo, porta, certificato e restrizioni IPv4. Controlla quell'endpoint prima di toccare anche una sola rotta.

Due listener, due problemi diversi

Una richiesta al sito raggiunge l'associazione HTTP.sys di quel sito, definita per sito e per protocollo nella configurazione applicationHost. Una richiesta da IIS Manager raggiunge WMSVC, che per impostazione predefinita risponde in HTTPS sulla TCP 8172 ed è configurato a livello di server. Nulla nell'associazione del sito cambia dove ascolta WMSVC, e nulla in WMSVC cambia su quale indirizzo risponde il sito. Condividono una macchina e un archivio certificati, ed è lì che finisce la somiglianza.

Quindi un Test-NetConnection riuscito sulla porta 443 ti dice che il listener del sito è raggiungibile, e nulla sull'amministrazione.

Trova l'indirizzo a cui WMSVC è realmente associato

Chiedi al server su cosa sta ascoltando, non su cosa era configurato anni fa. Get-NetTCPConnection -LocalPort 8172 -State Listen stampa l'indirizzo locale, e un valore 0.0.0.0 o :: significa tutti gli indirizzi, mentre un indirizzo specifico significa solo quello. Se l'indirizzamento di un server è cambiato, un listener ancora fissato a un indirizzo dismesso è esattamente il guasto che questo controllo intercetta.

Il valore configurato si trova nella pagina Management Service di IIS Manager sul nodo server, e dietro di essa in administration.config nella directory di configurazione inetsrv. Confronta i due: ciò che dice il file e ciò a cui il socket è realmente associato.

Poi esegui Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed dal client VPN interessato e leggi l'indirizzo risolto e l'indirizzo sorgente selezionato. Una risposta DNS diversa sulla VPN è abbastanza comune da valere la pena di escluderla subito. Conserva quel nome host e quella porta esatti nel ticket, perché un confronto successivo con un nome diverso non dimostra nulla sulla modifica fatta.

Leggi l'indirizzo sorgente che vede il server

Le restrizioni IPv4 di WMSVC vengono valutate rispetto all'indirizzo che arriva al server, che non è sempre quello che il tuo portatile crede di avere. Se il pool VPN viene tradotto da qualche parte lungo il percorso, il server vede l'indirizzo tradotto e una lista di autorizzazione costruita sull'indirizzo interno del client lo rifiuterà. Quel rifiuto sembra un errore di connessione dal lato client, ed è per questo che viene spesso diagnosticato male come problema di routing.

Usa l'output dettagliato del test TCP, insieme alla tabella delle connessioni del server, per vedere quale indirizzo sorgente è realmente arrivato prima di modificare la lista delle restrizioni.

Cambia l'associazione come modifica di servizio

WMSVC deve essere arrestato prima di modificare la sua configurazione, quindi pianificalo come un intervento con un'altra via di gestione disponibile, come l'accesso alla console o una sessione remota che non dipende da IIS Manager. Arresta il servizio, applica la modifica di indirizzo, porta o certificato, poi riavvialo e verifica che il listener si sia spostato. Chiunque altro usi l'amministrazione remota di IIS perde la sessione in quella finestra. Avvisa gli altri amministratori prima che la finestra si apra; scoprirlo a metà modifica è come due persone finiscono per modificare lo stesso listener.

Scegliere tutti gli indirizzi è un'opzione legittima, ma trattala come una decisione di accesso e non come una scorciatoia. Allargare il listener mentre la lista delle restrizioni resta aperta è come un endpoint di gestione finisce esposto su una rete che nessuno intendeva. Se il server ha più NIC, limita il listener all'interfaccia di gestione, lascia in pace il percorso dati e verifica che il sito risponda ancora sul proprio indirizzo.

Il certificato presentato da WMSVC viene scelto separatamente dai certificati del sito. Se cambi l'indirizzo, verifica che il certificato corrisponda ancora al nome host usato dai client, altrimenti la connessione fallirà più avanti allo step TLS con una lamentela che non ha nulla a che vedere con il routing.

Separa la raggiungibilità dalla fiducia e dai permessi

Una volta che la TCP funziona, i guasti rimanenti sono in ordine: fiducia TLS per il certificato di gestione, poi autenticazione Windows, poi i permessi di IIS Manager concessi a quell'account. Ognuno produce un errore diverso, e nessuno di essi si risolve con una rotta o una regola del firewall. Leggi il testo dell'errore alla lettera invece di riavviare di nuovo il servizio.

Esegui i quattro controlli in quell'ordine, endpoint, listener, indirizzo sorgente, fiducia, e di solito troverai l'associazione obsoleta prima di trovare un problema di rete.