VPN வழியாக SQL Server பெயரிடப்பட்ட நிகழ்வு: போர்ட் 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 ஹோஸ்ட் பெயர் ஒரு முழுமையான முகவரி என்பது. அது ஒரு ஹோஸ்ட், பெயரிடப்பட்ட நிகழ்வுக்கு சுரங்கப்பாதை சுமக்காத ஒரு தேடலும் சேர்கிறது. போர்ட்டைப் பெயரிடுங்கள், கண்டறிதல் பாதையைப் பெயரிடுங்கள், அடுத்த தோல்வி எந்த அடுக்கைச் சரிசெய்ய வேண்டும் என்பதைச் சொல்லும்.