தனிப்பட்ட முனைப்புள்ளி, அதே சேவையகப் பெயர்: Azure SQL இணைப்பு சரங்கள்

Private Link ஒரு இணைப்பு எங்கு வந்து சேருகிறது என்பதை மாற்றுகிறது, இணைப்பு எப்படி அழைக்கப்படுகிறது என்பதை அல்ல. Azure SQL Database பொறுத்தவரை அந்த வேறுபாடே முழு வடிவமைப்பு: தர்க்கரீதியான சேவையகம் அதன் பெயரைத் தக்கவைத்துக்கொள்கிறது, தனிப்பட்ட முனைப்புள்ளி பெயர் தீர்க்கப்படும் வலைப்பிணைப்புப் பதிவை வழங்குகிறது. பெயரை IP முகவரியால் மாற்றுவதே TLS, சான்றுகள், கருவிகள் ஆகியவற்றை ஒரே நேரத்தில் உடைக்கும் ஒரே மாற்றம். இரு இணைப்பு சரங்கள் சமமாகத் தோன்றி முற்றிலும் வேறுபட்டு நடந்துகொள்ளலாம்.

orders-db.database.windows.net வைத்துக்கொண்டு வாடிக்கையாளருக்கு அதற்கான தனிப்பட்ட பதிலை வழங்குங்கள்.

பெயருக்கும் முகவரிக்கும் வெவ்வேறு பணிகள் உள்ளன

பெயர் SQL சேவையை அடையாளம் காட்டுகிறது, சான்றிதழும் உள்நுழைவும் அதையே எதிர்பார்க்கின்றன. தனிப்பட்ட முகவரி இணைக்கப்பட்ட மெய்நிகர் வலையமைப்புக்குள் வலைப்பிணைப்புப் பதிவை வழங்குகிறது. ஒன்றை மற்றொன்றுடன் குழப்புவது எதையோ அடைந்து எதற்கும் அங்கீகாரம் செய்யாத இணைப்பை உருவாக்குகிறது.

Azure SQL க்கான Microsoft வழிகாட்டுதல் வாடிக்கையாளர்களிடமிருந்து வழக்கமான சேவையகப் பெயரைக் கோருகிறது. நேரடி IP, அதேபோல் privatelink முன்னொட்டுடன் கூடிய பெயரும், பரிமாற்றம் செய்யக்கூடிய உள்நுழைவு இலக்கு அல்ல. IP யை ஏற்கும் கருவிகள் அதை ஏற்றுக்கொண்டு பின்னர் TLS இல் அல்லது அங்கீகாரத்தில் தோல்வியடையும், இது உண்மையான தவறை மறைக்கிறது. அந்தத் தோல்விகள் பிழையில் உள்ள புரவலன் பெயரைப் பார்க்கும் வரை சான்று சிக்கல்களாகப் படிக்கப்படுகின்றன.

தனிப்பட்ட மண்டலம் உண்மையில் மாற்றுவது என்ன

தனிப்பட்ட DNS மண்டலம் privatelink பெயர் வெளியில் சேவையகத்திற்கு ஒரு முகவரியைப் பதிவு செய்கிறது, மண்டலம் அதைப் பயன்படுத்த வேண்டிய மெய்நிகர் வலையமைப்புடன் இணைக்கப்பட்டுள்ளது. தீர்வு நகருகிறது; இணைப்பு சரம் நகருவதில்லை. கீழே உள்ள வடிவம் ஒரு எடுத்துக்காட்டு, பொது மண்டலத்தில் ஒட்ட வேண்டிய பதிவு அல்ல.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

அந்தப் பதிவையும் அதன் மண்டல இணைப்பையும் உரிமையாளர் மற்றும் மதிப்பாய்வு தேதியுடன் உள்கட்டமைப்பாகப் பராமரியுங்கள்.

ஒரே தோற்றமும் வெவ்வேறு பதில்களும் கொண்ட இரு மண்டலங்கள் சாதாரண இறுதி நிலை, மோதல் அல்ல. பொது வாடிக்கையாளர்கள் பொது பதிலைத் தக்கவைக்கின்றனர், தனிப்பட்ட வாடிக்கையாளர்கள் முனைப்புள்ளி முகவரியைப் பெறுகின்றனர். கவனிக்க வேண்டிய தோல்வி முறை தனிப்பட்ட பார்வையின் பகுதி பரவல், அங்கு ஒரு துணை வலையம் தனிப்பட்ட முறையில் தீர்க்கப்படுகிறது மற்றொன்று அமைதியாக இல்லை.

Azure வெளியே உள்ள வாடிக்கையாளர்களுக்கு அந்த மண்டலத்திற்கு ஒரு பாதை தேவை

VPN வாடிக்கையாளர் Azure இன் தீர்வியலுக்கு வெளியே அமர்ந்திருக்கிறார், எனவே தனிப்பட்ட மண்டலம் கலப்புப் பாதையிலிருந்து அணுகக்கூடியதாக இருக்க வேண்டும். Azure DNS அனுப்பி அல்லது Azure DNS Private Resolver அந்த வலையமைப்பின் வழியாக வரும் வினவல்களுக்குச் சேவை செய்ய முடியும். Microsoft இன் வழிகாட்டுதல், வாடிக்கையாளர்கள் நேரடியாக privatelink பெயரைக் கேட்கிறார்கள் என்று கருதுவதற்குப் பதிலாக தொடர்புடைய பொது சேவை மண்டலத்தை அந்த ஏற்பாட்டின் வழியாக அனுப்புவதாகும். தனிப்பட்ட பதிலைத் தீர்க்க முடியாத வாடிக்கையாளர்கள் புகார் இல்லாமல் பொது பதிலுக்குத் திரும்புகின்றனர்.

அனுப்பும் வரம்பை வேண்டுமென்றே வைத்திருங்கள், ஏனெனில் பயன்பாட்டில் உள்ள பொது மண்டலத்தை மாற்றுவது மாற்றீட்டில் இல்லாத பெயர்களை உடைக்கும்.

அடையாளத்தை நிலையாக வைத்திருக்கும் வரிசையில் வழங்குங்கள்

படிகளுக்கு தனித்தனி உரிமையாளர்கள் உள்ளனர்: முனைப்புள்ளியை உருவாக்கி அனுமதியுங்கள், VPN பாதையை வழங்குங்கள், தனிப்பட்ட DNS ஐ ஒருங்கிணைக்கவும், பின்னர் வாடிக்கையாளரை அதன் சாதாரண சேவையகப் பெயருடன் அமைக்கவும். பாதைக்கு முன் DNS செய்வது DNS தோல்விகளைப் போலத் தோன்றும் நேர வரம்புகளை உருவாக்குகிறது. வாடிக்கையாளரைக் கடைசியாகச் செய்வது ஒரு நேரத்தில் ஒரு மாறியை மட்டும் இயக்கத்தில் வைக்கிறது. ஒவ்வொரு படிக்கும் கவனிக்கக்கூடிய முடிவு உள்ளது, எனவே எதையும் ஊகித்துச் சோதிக்க வேண்டியதில்லை.

இணைக்கப்பட்ட VPN சின்னம் தானாகவே தனிப்பட்ட இலக்கைத் தேர்ந்தெடுக்காது.

தனிப்பட்ட முனைப்புள்ளி அணைக்காதது

தனிப்பட்ட முனைப்புள்ளியை உருவாக்குவது தர்க்கரீதியான சேவையகத்திற்கான பொது அணுகலைத் தானாக முடக்காது. அது தனி வரிசைப்படுத்தல் முடிவு, மேலும் நோக்கிய தனிப்பட்ட வாடிக்கையாளர்கள் செயல்படுவது உறுதிசெய்யப்பட்ட பிறகே அது வரும். மீட்புப் பாதையை வைத்திருங்கள், இன்னும் பொது நுழைவைப் பயன்படுத்தும் பயன்பாடுகளைக் கணக்கில் கொள்ளுங்கள். பொது அணுகலை முதலில் அணைப்பது என்பது இயங்கும் சேவை ஒழுங்கான தணிக்கைத் தடத்துடன் இடையூறாக மாறும் வழி.

சேவையகம் எந்த இணைப்புக் கொள்கையைப் பயன்படுத்துகிறது என்பதையும் சரிபார்க்கவும்.

Redirect ஆரம்ப நுழைவாயில் இணைப்புக்குப் பிறகு வாடிக்கையாளரை முனையத்தின் துறைமுகத்திற்கு அனுப்புகிறது, இது வாடிக்கையாளர் வலையமைப்பு எதை அனுமதிக்க வேண்டும் என்பதை மாற்றுகிறது. Proxy போக்குவரத்தை நுழைவாயிலில் வைத்திருக்கிறது. ஒரு துறைமுகத்தில் வெற்றிகரமான TCP கைகுலுக்கல் முழு உள்நுழைவு பணிப்பாய்வு அல்ல.

இது Azure SQL Database, SQL Managed Instance அல்ல, அதற்கு சொந்த இணைப்பு மாதிரி உள்ளது மற்றும் சமமான தனிப்பட்ட முனைப்புள்ளிக் கதை இல்லை. இரண்டு நிலைகளிலும் மூன்று விஷயங்களைத் தனித்தனியாக லேபிளிட்டு வைத்திருங்கள்: பெயர், வலைப்பிணைப்புப் பதிவு மற்றும் சான்று. இணைப்பு எங்கு பயணிக்கிறது என்பதை மாற்றுவது வாடிக்கையாளர் எந்தச் சேவையுடன் பேசுகிறார் என்று நினைப்பதை ஒருபோதும் மாற்றக்கூடாது.