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

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

பிழையை உருவாக்கிய அடுக்கிலேயே படியுங்கள்

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

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

TCP மறுப்பு: யாரும் கேட்கவில்லை

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

முகவரி குடும்பத்தையும் சரிபார்க்கவும். 127.0.0.1 அல்லது IPv6-க்கு மட்டும் பிணைக்கப்பட்ட சேவை மற்றொன்றுக்குத் தீர்க்கப்படும் வாடிக்கையாளரை நிராகரிக்கும்.

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

UDP-க்கு மறுக்க கைக்குலுக்கல் இல்லை

UDP மீது OpenVPN TCP பொருளில் இணைப்பை நிறுவுவதில்லை, எனவே connect நேரத்தில் நிராகரிக்க எதுவும் இல்லை. Linux-இல், UDP சாக்கெட் காட்டும் பிழை முந்தைய தரவுக்கிராமத்தால் உருவாக்கப்பட்ட ICMP port-unreachable-இலிருந்து வரலாம். udp(7) கையேட்டுப் பக்கம் அந்த ஒத்திசைவற்ற நடத்தையை விவரிக்கிறது.

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

CRL உண்மையில் எங்கே சரிபார்க்கப்படுகிறது

CRL, TLS கைக்குலுக்கலின் போது, எதிர்ப் பக்கம் தன் சான்றிதழை வழங்கிய பிறகு, சேவையக உள்ளமைவு அனுமதித்தால் மட்டுமே கேட்கப்படுகிறது. OpenVPN-இன் crl-verify விருப்பம் கோப்பைச் சுட்டுகிறது, தோல்வி சேவையகப் பதிவில் சான்றிதழைப் பெயரிடும் சரிபார்ப்புப் பிழையாகத் தோன்றுகிறது.

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

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

அடுத்த முறைக்கான சிறு கையேடு

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

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

தொடர்புடைய கட்டுரைகள்