SQL Server-ի անվանված օրինակը VPN-ով․ հայտնաբերում, ոչ թե 1433 պորտ

Մարդկանց մեծ մասը SQL Server-ի հոսթի անունը համարում է ամբողջական հասցե, իսկ VPN-ը՝ կա՛մ թույլատրված, կա՛մ ոչ։ Գործնականում անվանված օրինակը ստիպում է հաճախորդին DNS-ից հետո կատարել երկրորդ որոնում, և հենց այդ որոնումն է, որ թունելը ամենահաճախ կոտրում է։ Բացահայտ վերջնակետը շրջանցում է այն, դրա համար tcp:host,port-ը կարող է աշխատել, մինչ host\INSTANCE-ը ժամանակն սպառում է։ Տարբերությունը ծառայությունը գտնելու և այն օգտագործելու թույլտվություն ստանալու միջև է։

Առասպելը․ մեկ հոսթի անունը նշանակում է մեկ պորտ

Հոսթի անունը լուծվում է հասցեի, և այդտեղ ավարտվում է նրա աշխատանքը։ Անվանված օրինակը ավելացնում է օրինակի անուն, որը սերվերը պետք է թարգմանի TCP պորտի, և հաճախորդը չի կարող գուշակել այն։ 1433 պորտը լռելյայն օրինակի լռելյայնն է, ոչ թե մեքենայի յուրաքանչյուր օրինակի հատկությունը։ Երկուսը նույն բանը համարելը ստեղծում է դասական ախտանիշ․ ping-ը աշխատում է, DNS-ը աշխատում է, 1433-ի սկանավորումը ոչինչ չի ցույց տալիս, և եզրակացությունն այն է, որ ցանցը արգելափակում է SQL-ը։

Երկրորդ ենթադրությունը ձախողվում է նույն կերպ․ որ TCP 1433-ը բացելը բավարար է։ Եթե օրինակը լսում է այլ տեղ, բաց 1433-ը միայն ապացուցում է, որ այնտեղ այլ բան կա։ Պորտը պետք է համապատասխանի լսողին, և որ լսողը սերվերի կողմի կարգավորման մանրամասն է պետք է հարցնել, ոչ թե ենթադրել։

Ինչ է հաճախորդն իրականում անում անվանված օրինակի հետ

Հոսթը լուծելուց հետո հաճախորդը UDP 1434-ով հայտնաբերման հարցում է ուղարկում SQL Server Browser-ին և հարցնում, թե որ պորտն է օգտագործում անվանված օրինակը։ Բրաուզերի ծառայությունը պատասխանում է սերվերի սեփական ռեեստրից, և այնուհետև հաճախորդը TCP կապ է բացում այդ պորտին։ Երկու արձանագրություն և երկու պորտ ներգրավված են մինչև նույնիսկ մուտքի փորձը։

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

Այդ պատճառով միայն UDP-ի արգելափակումը ստեղծում է ժամանակի սպառում, որը նման է մեռած հոսթի։ Եթե բրաուզերի ծառայությունը կանգնեցված է կամ անջատված, հայտնաբերման հարցումը մնում է անպատասխան, թեև տվյալների բազայի շարժիչն աշխատում է և նրա TCP պորտը բաց է։ Եթե օրինակը կարգավորված է ստատիկ պորտով, հաճախորդը դեռ հարցնում է, եթե վերջնակետը ուղղակիորեն չի տրվել։ Այս ձախողումներից յուրաքանչյուրը հավելվածի սխալի հաղորդագրության մեջ նույնն է թվում, և դրանք տարբեր ուղղումներ են պահանջում։

Բրաուզերի ծառայությունը հայտնաբերման հարմարություն է, ոչ թե տվյալների բազան։ Այն կանգնեցնելը չի կանգնեցնում շարժիչը, և այն սկսելը չի բացում օրինակի TCP պորտը։

Ինչու բացահայտ վերջնակետն աշխատում է, երբ անունը չի աշխատում

Բացահայտ վերջնակետը հանում է որոնումը հաջորդականությունից․ հաճախորդը ուղղակիորեն միանում է ձեր նշած հասցեին և պորտին։ Սա նախ ախտորոշում է, ոչ թե ինքնաբերաբար մշտական լուծում, քանի որ պորտը կարող է փոխվել, եթե օրինակը հետագայում վերակարգավորվի դինամիկի։ Համեմատեք երկու ձևերը նույն հաճախորդով և նույն հաշվով՝ նախքան եզրակացություններ անելը։

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

Եթե բացահայտ ձևը հաջողվում է, իսկ անվանվածը՝ ոչ, բացը հայտնաբերման մեջ է, և դուք կարող եք ընտրել, թե ինչպես փակել այն․ թույլատրեք UDP 1434-ը թունելով, կամ խնդրեք ադմինիստրատորին ամրագրել ստատիկ պորտ և փաստաթղթավորել վերջնակետը։ Երկուսն էլ գիտակցված որոշումներ են՝ տարբեր սպասարկման ծախսերով։ Շարքի բոլոր պորտերը բացելը ոչ մեկն է դրանցից, և դա այն տարբերակն է, որ սովորաբար առաջարկվում է երկար օրվա վերջում։ Գրանցեք ընտրությունը այնտեղ, որտեղ ապրում են կապի տողերը։

Եթե ոչ մի ձև չի աշխատում, խնդիրը հայտնաբերումից վերև է։ Ստուգեք լսողը, երթուղին և մուտքի կանոնը այն պորտի համար, որն օրինակն իրականում օգտագործում է, նախքան բրաուզերի ծառայությանը մեղադրելը։

Հայտնաբերումից հետո․ նույնականացումը և ինքնությունը առանձին են

Մուտքի ձախողումը տարբեր իրադարձություն է, քան ժամանակի սպառումը, և VPN ինքնությունը թունելի շնորհիվ SQL մուտք չի դառնում։ Երբ հաճախորդը հասնում է ճիշտ պորտին, տվյալների բազայի շարժիչը կիրառում է իր սեփական նույնականացումը և թույլտվությունները։ Երկու փուլերը մեկ տոմսի մեջ խառնելը հենց այն ճանապարհն է, որով հայտնաբերման խնդիրը հանձնվում է սխալ թիմին։ Կարդացեք սխալի համարը նախքան որևէ բան փոխելը։

Պահեք փաստաթղթավորված հոսթի անունը, եթե դրայվերը վավերացնում է սերվերի վկայագիրը, քանի որ թվային հասցեով միանալը կարող է փոխել այդ ստուգումը՝ փոխարենը լուծելու սկզբնական խնդիրը։ Microsoft-ի վերջին դրայվերները լռելյայն գաղտնագրում են, ուստի անվան անհամապատասխանությունը հայտնվում է որպես վկայագրի սխալ հաջող TCP կապից հետո։ Սա առաջընթաց է, ոչ թե նոր ձախողում։

Առասպելը, որից պետք է հրաժարվել, այն է, որ SQL Server-ի հոսթի անունը ամբողջական հասցե է։ Դա հոսթ է գումարած՝ անվանված օրինակի համար, որոնում, որը թունելը կարող է չտանել։ Անվանեք պորտը, անվանեք հայտնաբերման ուղին, և հաջորդ ձախողումը կասի, թե որ շերտը ուղղել։