Nimetty SQL Server -instanssi VPN:n yli: löytäminen, ei portti 1433

Useimmat pitävät SQL Serverin isäntänimeä täydellisenä osoitteena ja VPN:ää joko sallittuna tai ei. Käytännössä nimetty instanssi saa asiakkaan tekemään DNS:n jälkeen toisen haun, ja juuri tuo haku on osa, jonka tunneli useimmin rikkoo. Selkeä päätepiste ohittaa sen, minkä vuoksi tcp:host,port voi toimia, kun taas host\INSTANCE vanhenee. Ero on palvelun löytämisen ja sen käyttöön saadun luvan välillä.

Myytti: yksi isäntänimi tarkoittaa yhtä porttia

Isäntänimi ratkeaa osoitteeksi, ja siihen sen työ päättyy. Nimetty instanssi lisää instanssin nimen, joka palvelimen on käännettävä TCP-portiksi, eikä asiakas voi arvata sitä. Portti 1433 on oletusinstanssin oletus, ei jokaisen koneen instanssin ominaisuus. Jos molempia pidetään samana asiana, syntyy klassinen oire: ping toimii, DNS toimii, portin 1433 skannaus ei näytä mitään, ja johtopäätös on, että verkko estää SQL:n.

Toinen oletus epäonnistuu samalla tavalla: että TCP 1433:n avaaminen riittää. Jos instanssi kuuntelee muualla, avoin 1433 todistaa vain, että siellä on jotain muuta. Portin on vastattava kuuntelijaa, ja että kuuntelija on palvelinpuolen kokoonpanotieto, sitä pitäisi kysyä eikä olettaa.

Mitä asiakas todella tekee nimetyn instanssin kanssa

Ratkaistuaan isännän asiakas lähettää löytämispyynnön SQL Server Browserille UDP 1434:n kautta ja kysyy, mitä porttia nimetty instanssi käyttää. Selainpalvelu vastaa palvelimen omasta rekisteristä, ja sitten asiakas avaa TCP-yhteyden siihen porttiin. Kaksi protokollaa ja kaksi porttia ovat mukana ennen kuin kirjautumista edes yritetään.

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

Siksi pelkkä UDP:n estäminen tuottaa aikakatkaisun, joka näyttää kuolleelta isännältä. Jos selainpalvelu on pysäytetty tai poistettu käytöstä, löytämispyyntö jää vastaamatta, vaikka tietokantamoottori on käynnissä ja sen TCP-portti on auki. Jos instanssi on määritetty staattiselle portille, asiakas kysyy silti, ellei sille annettu päätepistettä suoraan. Jokainen näistä vioista näyttää sovelluksen virheilmoituksessa samalta, ja ne vaativat erilaisia korjauksia.

Selainpalvelu on löytämisen mukavuus, ei tietokanta. Sen pysäyttäminen ei pysäytä moottoria, eikä sen käynnistäminen avaa instanssin TCP-porttia.

Miksi selkeä päätepiste toimii, kun nimi ei toimi

Selkeä päätepiste poistaa haun järjestyksestä: asiakas yhdistää suoraan ilmoittamaasi osoitteeseen ja porttiin. Se on ensin diagnostiikkaa, ei automaattisesti pysyvä korjaus, koska portti voi muuttua, jos instanssi myöhemmin määritetään uudelleen dynaamiseksi. Vertaa kahta muotoa samalla asiakkaalla ja samalla tilillä ennen johtopäätöksiä.

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

Jos selkeä muoto onnistuu ja nimetty muoto epäonnistuu, löytäminen on aukko, ja voit valita, miten suljet sen: salli UDP 1434 tunnelin läpi tai pyydä ylläpitäjää kiinnittämään staattinen portti ja dokumentoimaan päätepiste. Molemmat ovat tietoisia päätöksiä, joilla on erilaiset ylläpitokustannukset. Alueen jokaisen portin avaaminen ei ole kumpikaan niistä, ja se on vaihtoehto, jota yleensä ehdotetaan pitkän päivän lopussa. Kirjaa valinta sinne, missä yhteysmerkkijonot elävät.

Jos kumpikaan muoto ei toimi, ongelma on löytämisen yläpuolella. Tarkista kuuntelija, reitti ja käyttösääntö sille portille, jota instanssi todella käyttää, ennen kuin syytät selainpalvelua.

Löytämisen jälkeen: todennus ja identiteetti ovat erillisiä

Kirjautumisen epäonnistuminen on eri tapahtuma kuin aikakatkaisu, eikä VPN-identiteetistä tule SQL-kirjautumista tunnelin ansiosta. Kun asiakas saavuttaa oikean portin, tietokantamoottori soveltaa omaa todennustaan ja käyttöoikeuksiaan. Kahden vaiheen sekoittaminen yhteen tikettiin on tapa, jolla löytämisongelma päätyy väärälle tiimille. Lue virhenumero ennen kuin muutat mitään.

Säilytä dokumentoitu isäntänimi, jos ajuri validoi palvelimen varmenteen, koska numeerisella osoitteella yhdistäminen voi muuttaa tuota tarkistusta sen sijaan, että se ratkaisisi alkuperäisen ongelman. Uudemmat Microsoftin ajurit salaavat oletuksena, joten nimen poikkeama näkyy varmennevirheenä onnistuneen TCP-yhteyden jälkeen. Se on edistystä, ei uusi vika.

Myytti, josta on luovuttava, on se, että SQL Serverin isäntänimi on täydellinen osoite. Se on isäntä plus, nimetyn instanssin kohdalla, haku, jota tunneli ei välttämättä kanna. Nimeä portti, nimeä löytämispolku, ja seuraava vika kertoo, mikä kerros on korjattava.