SSTP முதலில் சேவையகத்தையும் பின்னர் பயனரையும் அங்கீகரிக்கிறது
SSTP முதலில் சேவையகச் சான்றிதழைச் சரிபார்த்து, பயனரைப் பின்னர் PPP வழியாக அங்கீகரிக்கிறது. இரண்டு நிலைகளையும் ஒரே நேரத்தில் தொடுவதற்குப் பதிலாக பிழையைச் சரியான நிலையுடன் பொருத்துங்கள்.
SSTP வாடிக்கையாளர் TLS-ஐ முடித்துவிட்டு ஒரு வினாடி கழித்து பயனரை நிராகரிக்கலாம். இந்த வரிசை பிழை அல்ல, இது நெறிமுறை அடுக்கு: முதலில் இயக்கப் பாதுகாப்பு, பின்னர் பயனர் அங்கீகாரம். இரு நிலைகளும் வெவ்வேறு செய்திகளுடன் தோல்வியடைவதால், அவற்றுக்கு வெவ்வேறு திருத்தங்களும் தேவை. எந்த நிலை பிழையை உருவாக்கியது என்று படிப்பதே கண்டறிதலின் பெரும் பகுதி.
நம்பகமான சான்றிதழ் இறுதிப் புள்ளியை நிரூபிக்கிறது; கணக்கு பற்றி எதுவும் கூறுவதில்லை.
TLS கைச்செறுகை எதை நிறுவுகிறது
வாடிக்கையாளர் சேவையகம் வழங்கும் சான்றிதழை தனது நம்பிக்கைக் கிடங்கு, கோரப்பட்ட புரவலன் பெயர், செல்லுபடி சாளரம் மற்றும் தளம் பயன்படுத்தும் கூடுதல் கொள்கை ஆகியவற்றுக்கு எதிராகச் சரிபார்க்கிறது. இது நோக்கமிடப்பட்ட இறுதிப் புள்ளிக்கான இணைப்பைப் பாதுகாக்கிறது. ஆனால் ஒரு குறிப்பிட்ட கணக்கு இயக்கப்பட்டுள்ளது, காலாவதியாகவில்லை அல்லது தொலை அணுகலுக்கு அனுமதிக்கப்பட்டுள்ளது என்பதை நிரூபிக்கவில்லை. அவை பின்னர் மற்றொரு கூறு கேட்கும் தனித்தனி கேள்விகள்.
எனவே உள்நுழைவு கேட்பிற்குச் செல்ல சான்றிதழ் சரிபார்ப்புகளை நீக்குவது தவறான திருத்தம். சரிபார்க்க முடியாத இணைப்பில் உள்நுழைவு கேட்பு கிடைக்கும். சான்றிதழ் பிழை புரவலன் பெயர், கடிகாரம், சங்கிலி அல்லது நம்பிக்கை உள்ளமைவுக்கு உரியது.
SSTP மற்றும் PPP மேலே எதைச் சேர்க்கின்றன
SSTP HTTPS மீது இயங்கி உள்ளே PPP-ஐச் சுமக்கிறது, இணைப்பைச் சுற்றி அதன் சொந்த கட்டுப்பாட்டுப் பரிமாற்றத்துடன். பின்னர் PPP அதன் இணைப்பு மற்றும் அங்கீகார நிலைகளை இயக்குகிறது, அங்கீகார முறை சேவையகக் கொள்கை மற்றும் வாடிக்கையாளர் திறனைப் பொறுத்தது. PAP, CHAP, MS-CHAPv2 மற்றும் EAP அனைத்தும் மிக வெவ்வேறு பண்புகளைக் கொண்ட PPP அங்கீகார விருப்பங்கள். VPN-இன் பயனர் சரிபார்ப்பு அந்த PPP நிலையே, அதன் கீழுள்ள TLS அடுக்கு அல்ல.
எனவே பயனர் நிராகரிப்பு என்பது சான்றுகள், கணக்குக் கட்டுப்பாடு அல்லது முறைப் பொருந்தாமை என்று பொருள்படலாம்.
சேவையகப் பக்கக் காரணம் சுயவிவரத்தில் உள்ள ஒவ்வொரு ரகசியத்தையும் மீட்டமைப்பதை விட மிகவும் பயனுள்ளது. கணக்கு முடக்கப்பட்ட நிகழ்வும் முறைப் பேச்சுவார்த்தைத் தோல்வியும் வாடிக்கையாளரிடம் ஒரே மாதிரி தெரிகின்றன, சேவையகத்தில் அவற்றுக்கு பொதுவான எதுவும் இல்லை.
பிழையை நிலையுடன் பொருத்துங்கள்
இணைப்பு TLS-ஐ அடைகிறதா, பின்னர் SSTP HTTP பரிமாற்றம், பின்னர் PPP நிலை என்பதைச் சரிபார்க்கவும். மீண்டும் முயற்சிகளுக்கு இடையே பதிவுகளின் நேரமுத்திரைகளைச் சீரமைத்து வைத்திருங்கள், இதனால் முந்தைய தோல்வி பிந்தைய வெற்றியுடன் குழப்பப்படாது. ஒரு சாளரத்தில் இரண்டு முயற்சிகளைப் பதிவு செய்யும் வாடிக்கையாளர் இல்லையெனில் தான் அடைந்த கடைசி நிலையில் தோல்வியடைந்ததாகத் தோன்றும். கடைசி வரியை அல்ல, முதல் தொடர்புடைய பிழையைப் படியுங்கள்.
அதே சீரமைப்பு சேவையகப் பக்கத்திலும் முக்கியம், அங்கு அங்கீகாரப் பதிவும் இயக்கப் பதிவும் பெரும்பாலும் வெவ்வேறு கடிகாரங்களைக் கொண்ட தனித் தனி கோப்புகள். இரண்டு நிமிட வித்தியாசம் தெளிவான காரணத்தைச் சாத்தியமற்றதாகத் தோற்றுவிக்கப் போதும்.
உள்நுழைவுக்குப் பிறகும் அனுமதி தனித்தனியே உள்ளது
வெற்றிகரமான உள்நுழைவு ஒவ்வொரு தனிப்பட்ட வளத்தையும் வழங்காது. வழித்தடங்கள் எதை அடைய முடியும் என்பதைத் தீர்மானிக்கின்றன, DNS எது தீர்க்கப்படுகிறது என்பதைத் தீர்மானிக்கிறது, ஒவ்வொரு சேவையும் இன்னும் அதன் சொந்த அனுமதிகளைப் பயன்படுத்துகிறது. இணைக்கப்பட்டதாகக் காட்டப்படும் அமர்வு சுரங்கத்தைப் பற்றிய அறிக்கை, கோப்புப் பகிர்வைப் பற்றியது அல்ல. பயனர் இணைக்க முடிந்தும் ஒரு புரவலனை அடைய முடியாவிட்டால், சுரங்க நிலை ஏற்கனவே முடிந்துவிட்டது.
இது கைச்செறுகை காட்டிய அதே அடுக்கமைப்பு, ஒரு நிலை மேலே.
கணக்கு மீட்பை இயக்குபவர் ஆதரிக்கும் செயல்முறைக்குள் வைத்திருங்கள், வெளிப்படையான பயனர் மறுப்புக்குப் பதிலாக இயக்க அமைப்புகளை மாற்றுவதற்குப் பதிலாக. முடக்கப்பட்ட கணக்கைச் சரிசெய்ய இயக்கத்தை மாற்றுவது, கணக்கு தொடர்பில்லாத காரணத்தால் மீண்டும் இயக்கப்பட்டபோது வேலை செய்வதாகத் தோன்றும் வகையான திருத்தம்.