SQL Server-en instantzia izendatua VPN bidez: aurkikuntza, ez 1433 ataka

Jende gehienak SQL Server-en ostalari-izena helbide oso gisa tratatzen du, eta VPN-a baietsita edo ez dagoen zerbait gisa. Praktikan, instantzia izendatuak bezeroari DNSaren ondoren bigarren bilaketa bat egitera behartzen dio, eta bilaketa hori da tunelek maizenik hausten duen zatia. Muturreko puntu esplizitu batek saihesten du, horregatik tcp:host,port funtziona dezake host\INSTANCE iraungitzen den bitartean. Ezberdintasuna zerbitzua aurkitzearen eta erabiltzeko baimena izatearen artean dago.

Mitoa: ostalari-izen batek ataka bat esan nahi du

Ostalari-izena helbide batean ebazten da, eta han amaitzen da bere lana. Instantzia izendatuak zerbitzariak TCP ataka bihurtu behar duen instantzia-izen bat gehitzen dio, eta bezeroak ezin du asmatu. 1433 ataka lehenetsitako instantzia baten lehenespena da, ez makinako instantzia bakoitzaren propietatea. Biak gauza bera balira bezala tratatzeak sintoma klasikoa sortzen du: ping-ek funtzionatzen du, DNSak funtzionatzen du, 1433ren eskaneatzeak ez du ezer erakusten, eta ondorioa da sareak SQL blokeatzen duela.

Bigarren hipotesi batek modu berean huts egiten du: TCP 1433 irekitzea nahikoa dela. Instantzia beste leku batean entzuten badago, 1433 ireki batek soilik frogatzen du beste zerbait dagoela han. Atakak entzulearekin bat etorri behar du, eta entzulea zerbitzariaren aldeko konfigurazio xehetasuna dela, hori galdetu behar da, ez asmatu.

Zer egiten duen bezeroak instantzia izendatu batekin benetan

Ostalaria ebatzita, bezeroak aurkikuntza-eskaera bat bidaltzen dio SQL Server Browserri UDP 1434 bidez eta galdetzen du zein ataka erabiltzen duen instantzia izendatuak. Nabigatzailearen zerbitzuak zerbitzariaren erregistrotik erantzuten du, eta gero bezeroak TCP konexio bat irekitzen du ataka horretara. Bi protokolo eta bi ataka parte hartzen dute saioa hasteko saiakerarik egin aurretik.

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

Horregatik UDP soilik blokeatzeak ostalari hil baten itxura duen denbora-muga sortzen du. Nabigatzailearen zerbitzua geldituta edo desgaituta badago, aurkikuntza-eskaera erantzunik gabe geratzen da datu-basearen motorra martxan egon eta haren TCP ataka irekita egon arren. Instantzia ataka estatiko batekin konfiguratuta badago, bezeroak oraindik galdetzen du, muturreko puntua zuzenean eman ez bazaio. Hutsegite horietako bakoitzak berdin dirudi aplikazioaren errore-mezuan, eta konponketa desberdinak behar dituzte.

Nabigatzailearen zerbitzua aurkikuntzarako erraztasuna da, ez datu-basea. Hura gelditzeak ez du motorra gelditzen, eta hura abiarazteak ez du instantziaren TCP ataka irekitzen.

Zergatik funtzionatzen duen muturreko puntu esplizituak izenak funtzionatzen ez duenean

Muturreko puntu esplizitu batek bilaketa kentzen du segidatik: bezeroak zuk izendatutako helbide eta atakara zuzenean konektatzen da. Hori lehenik diagnostikoa da, ez automatikoki irtenbide iraunkorra, ataka aldatu baitaiteke instantzia geroago dinamiko batera birkonfiguratuz gero. Alderatu bi formak bezero berarekin eta kontu berarekin ondorioak atera aurretik.

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

Forma esplizituak arrakasta badu eta forma izendatuak huts egiten badu, aurkikuntza da hutsunea, eta nola itxi aukeratu dezakezu: baimendu UDP 1434 tuneletik, edo eskatu administratzaileari ataka estatiko bat finkatzeko eta muturreko puntua dokumentatzeko. Biak erabaki deliberatuak dira, mantentze-kostu desberdinekin. Barrutiko ataka guztiak irekitzea ez da horietako bat ere, eta egun luze baten amaieran proposatu ohi den aukera da. Idatzi aukera konexio-kateak bizi diren tokian.

Bi formek funtzionatzen ez badute, arazoa aurkikuntzaren goialdean dago. Egiaztatu entzulea, ibilbidea eta instantziak benetan erabiltzen duen atakaren sarbide-araua nabigatzailearen zerbitzuari errua bota aurretik.

Aurkikuntzaren ondoren: autentifikazioa eta identitatea bereiziak dira

Saioa hasteko hutsegitea denbora-muga batetik desberdina den gertaera da, eta VPN identitatea ez da SQL saio-hasiera bihurtzen tuneleko presentziagatik. Bezeroa ataka zuzena iritsitakoan, datu-basearen motorrak bere autentifikazioa eta baimenak aplikatzen ditu. Bi fase txartel bakarrean nahastea da aurkikuntza-arazo bat talde oker bati esleitzeko modua. Irakurri errore-zenbakia ezer aldatu aurretik.

Mantendu dokumentatutako ostalari-izena gidatzaileak zerbitzariaren ziurtagiria baliozkotzen badu, helbide numerikoaren bidez konektatzeak egiaztapen hori alda baitezake jatorrizko arazoa konpondu ordez. Microsoft-en azken gidatzaileek lehenespenez zifratzen dute, beraz izen-desadostasuna ziurtagiri-errore gisa agertzen da TCP konexio arrakastatsu baten ondoren. Hori aurrerapena da, ez hutsegite berria.

Aldendu beharreko mitoa da SQL Server-en ostalari-izena helbide osoa dela. Ostalari bat da, eta instantzia izendatu batentzat, tunelek eraman lezakeen edo ez duen bilaketa bat gehitzen da. Izenda ezazu ataka, izenda ezazu aurkikuntza-bidea, eta hurrengo hutsegiteak esango dizu zein geruza konpondu.