Istanza denominata di SQL Server via VPN: la scoperta, non la porta 1433

La maggior parte delle persone tratta un nome host di SQL Server come un indirizzo completo e una VPN come qualcosa di consentito o meno. In pratica un'istanza denominata costringe il client a fare una seconda ricerca dopo il DNS, e quella ricerca è la parte che un tunnel rompe più spesso. Un endpoint esplicito la evita, per questo tcp:host,port può funzionare mentre host\INSTANCE va in timeout. La differenza è tra trovare il servizio e avere il permesso di usarlo.

Il mito: un nome host significa una porta

Il nome host si risolve in un indirizzo, e lì finisce il suo compito. Un'istanza denominata aggiunge un nome di istanza che il server deve tradurre in una porta TCP, e il client non può indovinarlo. La porta 1433 è il valore predefinito di un'istanza predefinita, non una proprietà di ogni istanza della macchina. Trattare le due cose come la stessa produce il sintomo classico: il ping funziona, il DNS funziona, la scansione della 1433 non mostra nulla, e la conclusione è che la rete blocca SQL.

Una seconda supposizione fallisce allo stesso modo: che aprire la TCP 1433 basti. Se l'istanza ascolta altrove, una 1433 aperta dimostra solo che lì c'è qualcos'altro. La porta deve corrispondere all'ascoltatore, e l'ascoltatore è un dettaglio di configurazione lato server questo va chiesto invece che supposto.

Che cosa fa realmente il client con un'istanza denominata

Dopo aver risolto l'host, il client invia una richiesta di scoperta a SQL Server Browser su UDP 1434 e chiede quale porta usi l'istanza denominata. Il servizio browser risponde dal registro del server stesso, poi il client apre una connessione TCP a quella porta. Due protocolli e due porte sono coinvolti prima ancora che si tenti un accesso.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Per questo un blocco solo UDP produce un timeout che sembra un host morto. Se il servizio browser è fermo o disabilitato, la richiesta di scoperta resta senza risposta anche se il motore del database è in esecuzione e la sua porta TCP è aperta. Se l'istanza è configurata con una porta statica, il client chiede comunque, a meno che gli sia stato dato l'endpoint direttamente. Ognuno di questi guasti appare identico nel messaggio di errore dell'applicazione, e richiedono correzioni diverse.

Il servizio browser è una comodità per la scoperta, non il database. Fermarlo non ferma il motore, e avviarlo non apre la porta TCP dell'istanza.

Perché l'endpoint esplicito funziona quando il nome no

Un endpoint esplicito toglie la ricerca dalla sequenza: il client si connette direttamente all'indirizzo e alla porta che hai indicato. È prima una diagnosi, non automaticamente una correzione permanente, perché la porta può cambiare se in seguito l'istanza viene riconfigurata su una dinamica. Confronta le due forme con lo stesso client e lo stesso account prima di trarre conclusioni.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Se la forma esplicita riesce e quella denominata fallisce, la scoperta è il vuoto, e puoi scegliere come chiuderlo: consentire UDP 1434 attraverso il tunnel, o chiedere all'amministratore di fissare una porta statica e documentare l'endpoint. Entrambe sono decisioni deliberate con costi di manutenzione diversi. Aprire ogni porta dell'intervallo non è nessuna delle due, ed è l'opzione che tende a essere proposta alla fine di una lunga giornata. Registra la scelta dove vivono le stringhe di connessione.

Se nessuna delle due forme funziona, il problema sta a monte della scoperta. Controlla l'ascoltatore, la rotta e la regola di accesso per la porta che l'istanza usa davvero prima di dare la colpa al servizio browser.

Dopo la scoperta: autenticazione e identità sono separate

Un errore di accesso è un evento diverso da un timeout, e l'identità VPN non diventa un accesso SQL per via del tunnel. Quando il client raggiunge la porta giusta, il motore del database applica la propria autenticazione e i propri permessi. Mescolare le due fasi in un solo ticket è il modo in cui un problema di scoperta viene assegnato al team sbagliato. Leggi il numero di errore prima di cambiare qualcosa.

Mantieni il nome host documentato se il driver convalida il certificato del server, perché connettersi tramite indirizzo numerico può cambiare quel controllo invece di risolvere il problema originale. I driver Microsoft recenti cifrano per impostazione predefinita, quindi una discrepanza di nome emerge come errore di certificato dopo una connessione TCP riuscita. È un progresso, non un nuovo guasto.

Il mito da abbandonare è che un nome host di SQL Server sia un indirizzo completo. È un host più, per un'istanza denominata, una ricerca che il tunnel potrebbe non trasportare. Nomina la porta, nomina il percorso di scoperta, e il prossimo guasto ti dirà quale livello correggere.