Azure P2S VPN தனிப்பட்ட முனைப்புள்ளியின் பெயரைத் தீர்க்க முடியவில்லை

நீங்கள் point-to-site சுரங்கப்பாதையை இணைத்து, தனிப்பட்ட முகவரிக்கு ping செய்து, பயன்பாட்டைத் திறக்கும்போது அதற்குப் பதிலாக 403 அல்லது சான்றிதழ் பிழை வருகிறது. இரண்டு அறிகுறிகளும் DNS ஐச் சுட்டுகின்றன, ஆனால் அவை வெவ்வேறு குறைபாடுகள்: ஒன்று வாடிக்கையாளர் பொது முகவரியைத் தீர்த்தார் என்பது, மற்றொன்று தனிப்பட்ட முகவரியைத் தீர்த்துவிட்டு சான்றிதழ் மூடாத பெயரை வழங்கியது என்பது. கீழே உள்ள சரிபார்ப்புகளை வரிசையாகச் செய்து முதல் தோல்வியில் நிறுத்துங்கள், ஏனெனில் hosts பதிவு அல்லது தேக்ககத்தில் உள்ள பதில் ஒவ்வொரு பிந்தைய சரிபார்ப்பையும் தவறான காரணத்திற்காக வெற்றிபெறச் செய்யும். இந்த வரிசையை என் VPN சுயவிவரங்களுக்கு அருகிலுள்ள உரைக் கோப்பில் வைத்திருக்கிறேன், ஏனெனில் சரிசெய்தல் சுரங்கப்பாதையில் எதையும் மாற்றாது, வாடிக்கையாளர் அறிந்தவற்றில் எல்லாவற்றையும் மாற்றும்.

வாடிக்கையாளர் உண்மையில் பெறும் முகவரியில் தொடங்குங்கள்

பயன்பாட்டை நம்புவதற்குப் பதிலாக தீர்வியை நேரடியாகக் கேளுங்கள். Windows இல், nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net வாடிக்கையாளர் எந்தப் பார்வையைப் பெற்றார் என்பதைக் காட்டுகிறது. பொது பதில் என்பது கீழே எதுவும் முனைப்புள்ளியை அடையாது; முனைப்புள்ளியின் தனிப்பட்ட முகவரி என்பது DNS முடிந்தது, அடுத்த சரிபார்ப்பு இணைப்பே.

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

சுரங்கப்பாதைக்கு முன் மண்டலம், அதன் இணைப்பு மற்றும் பதிவைச் சரிபார்க்கவும்

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

மண்டலப் பெயர்கள் சேவைகளுக்குரியவை, பொதுவாகத் தனிப்பட்ட இணைப்புகளுக்கு அல்ல. App Service வழக்கமாக privatelink.azurewebsites.net பயன்படுத்துகிறது, சேமிப்பகத்திற்கும் SQL க்கும் அவற்றின் சொந்தப் பெயர்வெளிகள் உள்ளன, மற்றொரு சேவையின் மண்டலத்தைக் கடனாகப் பெறுவது இருக்கும் ஆனால் பயனுள்ள எதற்கும் பதிலளிக்காத மண்டலத்தை உருவாக்கும்.

வாடிக்கையாளர் உண்மையில் அடையக்கூடிய தீர்வியைக் கொடுங்கள்

168.63.129.16 Azure மெய்நிகர் இயந்திரங்களிலிருந்து பதிலளிக்கிறது, point-to-site சுரங்கப்பாதையின் மறுபக்கத்தில் உள்ள மடிக்கணினிக்கு DNS சேவையகம் அல்ல. வாடிக்கையாளருக்கு சுரங்கப்பாதை வழியாக அணுகக்கூடிய தீர்வி தேவை: Azure DNS Private Resolver இன் உள்வரும் முனைப்புள்ளி, மெய்நிகர் வலையமைப்பிற்குள் உள்ள அனுப்பி, அல்லது VPN வாடிக்கையாளர் சுயவிவரத்தில் எடுத்துச் செல்லப்படும் DNS சேவையகப் பதிவுகள், அதனால் வாடிக்கையாளர் மெய்நிகர் வலையமைப்பை நேரடியாகக் கேட்பார்.

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

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

சான்றிதழ் வழங்கப்பட்ட பெயரைப் பயன்படுத்துங்கள்

முகவரி சரியானதும் இரண்டாவது குறைபாடு வெளிப்படுகிறது. சேமிப்பகமும் App Service உம் privatelink மாற்றுப்பெயரை வெளியிடுகின்றன, அந்த மாற்றுப்பெயர் சான்றிதழில் உள்ள பெயராக இருக்க வேண்டியதில்லை. privatelink.blob.core.windows.net க்கு அனுப்பப்பட்ட AzCopy பதிவேற்றம் சரிபார்ப்பில் தோல்வியடைந்தது; அதே பதிவேற்றம் <account>.blob.core.windows.net/<container> க்கு தனிப்பட்ட முகவரிக்குத் தீர்க்கப்பட்டு கடந்தது, எனவே எந்த முரண்பாடும் இல்லாமல் தனிப்பட்ட பாதையில் தங்கியது.

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

ஒவ்வொரு அடுக்கையும் தனிமைப்படுத்தும் நான்கு படி வரிசை

1. VPN வாடிக்கையாளரிடம் point-to-site குளத்திலிருந்து முகவரி மற்றும் முனைப்புள்ளியின் தனிப்பட்ட முகவரிக்கான பாதை உள்ளதை உறுதிசெய்யுங்கள்.
2. பயன்பாடு பயன்படுத்தும் சரியான பெயரைத் தீர்த்து, பதிலை முனைப்புள்ளியின் முகவரியுடன் ஒப்பிடுங்கள்.
3. சேவைத் துறையில் முனைப்புள்ளிக்கு TCP இணைப்பைத் திறந்து, பின்னர் அந்த இணைப்பில் வழங்கப்படும் சான்றிதழ் பெயரைப் படியுங்கள்.
4. இப்போதுதான் அங்கீகாரத்தைச் சோதியுங்கள், ஏனெனில் வேலை செய்யும் பாதையும் செல்லுபடியாகும் சான்றிதழும் இன்னும் வளத்திற்கான அணுகலைத் தரவில்லை.

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

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

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

hosts பதிவு எங்கே இடம்பெற வேண்டும்

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

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

குறுகிய பெயர்களுக்குத் தேடல் பின்னொட்டு தேவை, முழுத் தகுதிபெற்ற பெயர்களுக்குத் தேவையில்லை, எனவே முதலில் முழுத் தகுதிபெற்ற பெயரைச் சோதித்து, பின்னர் பணிப்பாய்வுக்கு வாடிக்கையாளர் சுயவிவரம் வழியாகத் தள்ளப்படும் பின்னொட்டு தேவையா என முடிவு செய்யுங்கள். Microsoft தனது தனிப்பட்ட முனைப்புள்ளி DNS வழிகாட்டுதலில் ஒவ்வொரு சேவைக்கும் மண்டலப் பெயர்களையும் பதிவு வடிவங்களையும் ஆவணப்படுத்துகிறது; மற்றொரு சேவையிலிருந்து மண்டலத்தை நகலெடுப்பதற்குப் பதிலாக உங்கள் சேவையின் பதிவைப் படியுங்கள்.