കണക്ഷൻ നിരസിക്കപ്പെടുന്നത് സർട്ടിഫിക്കറ്റ് പ്രശ്നമല്ല: VPN റൺബുക്ക്

CRL വീണ്ടും സൃഷ്ടിച്ചതിന് തൊട്ടുപിന്നാലെ കണക്ഷൻ നിരസിക്കപ്പെട്ടു എന്ന് ക്ലയന്റ് പറയുന്നു, അതിനാൽ CRL കുറ്റക്കാരനായി തോന്നുന്നു. അല്ല. നിരസിക്കൽ ട്രാൻസ്പോർട്ട് ലെയറിന്റെ ഉത്തരമാണ്, സർട്ടിഫിക്കറ്റ് സാധുത പരിശോധന പിന്നീട്, ടണൽ ഹാൻഡ്ഷേക്കിനുള്ളിൽ നടക്കുന്നു. സമയക്രമം സന്ദർഭമാണ്, തെളിവല്ല.

രണ്ട് പരിശോധനകൾ കേസുകളെ ഒരു മിനിറ്റിൽ താഴെ വേർതിരിക്കുന്നു, അവയൊന്നും വിശ്വാസ ക്രമീകരണങ്ങളെ തൊടുന്നില്ല.

പിശക് ഉണ്ടാക്കിയ ലെയറിൽ തന്നെ അത് വായിക്കുക

connect-ൽ നിന്നുള്ള ECONNREFUSED എന്നാൽ ട്രാൻസ്പോർട്ട് ശ്രമം നിരസിക്കപ്പെട്ടു: എന്തോ reset ഉപയോഗിച്ച് ഉത്തരം നൽകി, അല്ലെങ്കിൽ സ്റ്റാക്ക് എത്താനാകാത്ത പോർട്ട് റിപ്പോർട്ട് ചെയ്തു. സർട്ടിഫിക്കറ്റ് പ്രശ്നത്തിന് ആ പിശക് ഉണ്ടാക്കാനാകില്ല, കാരണം ട്രാൻസ്പോർട്ട് കണക്ഷൻ ഇല്ലാതെ TLS ഹാൻഡ്ഷേക്ക് ഒരിക്കലും തുടങ്ങുന്നില്ല. നിരസിക്കൽ കണ്ടാൽ, ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്ന ഘട്ടത്തിൽ പോലും എത്തിയിട്ടില്ല. ആ ഒരു വസ്തുത റദ്ദാക്കലിനെ കാരണമായി ഒഴിവാക്കുന്നു.

വിപരീതവും ശരിയാണ്. റദ്ദാക്കിയ സർട്ടിഫിക്കറ്റ് പൂർത്തിയായ TCP കണക്ഷനും പരാജയപ്പെട്ട ഹാൻഡ്ഷേക്കും ഉണ്ടാക്കുന്നു, അത് സെർവറിൽ പരിശോധന പിശകായി രേഖപ്പെടുത്തുന്നു.

TCP നിരസിക്കൽ: ആരും കേൾക്കുന്നില്ല

TCP-ക്ക്, ഉദ്ദേശിച്ച ഇൻസ്റ്റൻസ് പ്രവർത്തിക്കുന്നുണ്ടോ, പ്രൊഫൈലിലെ വിലാസത്തിലും പോർട്ടിലും ബന്ധിപ്പിച്ചിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക. ss -lntp ശ്രോതാക്കളെ കാണിക്കുന്നു, അവയിലൊന്ന് ഇല്ലാതിരിക്കുന്നതാണ് സാധാരണ വിശദീകരണം. ഉപേക്ഷിക്കുന്നതിനുപകരം നിരസിക്കുന്ന ഫയർവാൾ ക്ലയന്റ് വശത്ത് അതേ സന്ദേശം ഉണ്ടാക്കുന്നു, അതിനാൽ രണ്ടും പരിശോധിക്കുന്നു.

വിലാസ കുടുംബവും പരിശോധിക്കുക. 127.0.0.1 അല്ലെങ്കിൽ IPv6-ൽ മാത്രം ബന്ധിപ്പിച്ച സേവനം മറ്റൊന്നിലേക്ക് റിസോൾവ് ചെയ്യുന്ന ക്ലയന്റിനെ നിരസിക്കും.

പിന്നീട് ഊഹിക്കുന്നതിനുപകരം സേവന ലോഗ് വായിക്കുക. CA പരിപാലനത്തിന് ശേഷമുള്ള പുനരാരംഭം വായിക്കാനാകാത്തതോ കാണാത്തതോ ആയ ഫയലിൽ പരാജയപ്പെടാം, കേൾക്കുന്ന അവസ്ഥയിൽ എത്താതിരിക്കാം, ലോഗ് ഫയലിന്റെ പേര് പറയുന്നു. അത് സ്റ്റാർട്ടപ്പ് പരാജയമാണ്, നിരസിച്ച സർട്ടിഫിക്കറ്റിൽ നിന്ന് വ്യത്യസ്തമായ ബഗ്.

UDP-ക്ക് നിരസിക്കാൻ ഹാൻഡ്ഷേക്ക് ഇല്ല

UDP-യിൽ OpenVPN TCP അർത്ഥത്തിൽ കണക്ഷൻ സ്ഥാപിക്കുന്നില്ല, അതിനാൽ connect സമയത്ത് നിരസിക്കാൻ ഒന്നുമില്ല. Linux-ൽ, UDP സോക്കറ്റ് കാണിക്കുന്ന പിശക് മുൻപത്തെ ഡാറ്റാഗ്രാം സൃഷ്ടിച്ച ICMP port-unreachable-ൽ നിന്ന് വരാം. udp(7) മാനേജ് പേജ് ആ അസമകാലിക സ്വഭാവം വിവരിക്കുന്നു.

അതിനാൽ UDP ക്ലയന്റ് സെർവർ പ്രോസസ്സ് പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും പ്രതീക്ഷിച്ച വിലാസത്തിൽ ബന്ധിപ്പിച്ചിട്ടില്ലെങ്കിൽ നിരസിക്കൽ അച്ചടിക്കാം.

CRL യഥാർത്ഥത്തിൽ എവിടെ പരിശോധിക്കുന്നു

TLS ഹാൻഡ്ഷേക്കിനിടയിൽ, എതിർകക്ഷി തന്റെ സർട്ടിഫിക്കറ്റ് അവതരിപ്പിച്ചതിനുശേഷം, സെർവർ കോൺഫിഗറേഷൻ അനുവദിച്ചാൽ മാത്രമേ CRL പരിശോധിക്കുന്നുള്ളൂ. OpenVPN-ന്റെ crl-verify ഓപ്ഷൻ ഫയലിലേക്ക് ചൂണ്ടുന്നു, പരാജയം സെർവർ ലോഗിൽ സർട്ടിഫിക്കറ്റിന്റെ പേര് പറയുന്ന പരിശോധന പിശകായി പ്രത്യക്ഷപ്പെടുന്നു.

അതിനാൽ റദ്ദാക്കിയ ക്ലയന്റ് ട്രാൻസ്പോർട്ട് ലെയറിൽ ബന്ധിക്കുന്നു, പിന്നീട് പ്രാമാണീകരണത്തിൽ പരാജയപ്പെടുന്നു. അതേ സെർവർ, അതേ പോർട്ട്, തീർത്തും വ്യത്യസ്ത സന്ദേശം.

ആ ഘട്ടത്തിൽ എത്തുമ്പോൾ CRL-ന്റെ ഇഷ്യൂവറും സാധുത തീയതികളും പരിശോധിക്കുക. തെറ്റായ CA ഒപ്പിട്ട CRL, അല്ലെങ്കിൽ ക്ലയന്റ് ബന്ധിക്കുന്നതിന് മുൻപ് കാലഹരണപ്പെട്ട CRL, ക്ലയന്റിന്റെ സ്വന്തം സർട്ടിഫിക്കറ്റുമായി യാതൊരു ബന്ധവുമില്ലാത്ത പരിശോധന പിശകുകൾ ഉണ്ടാക്കുന്നു.

അടുത്ത തവണയ്ക്കുള്ള ചെറിയ റൺബുക്ക്

ആദ്യം ട്രാൻസ്പോർട്ട് ഉറപ്പാക്കുക: ശ്രോതാവ് ഉണ്ട്, ശരിയായ വിലാസ കുടുംബം, ഫയർവാൾ നിരസിക്കുന്നില്ല. പിന്നീട് സ്റ്റാർട്ടപ്പ് ലോഗ് വായിച്ച് സേവനം കേൾക്കുന്ന അവസ്ഥയിൽ എത്തിയെന്ന് ഉറപ്പാക്കുക. അതിനുശേഷം മാത്രം പരിശോധന സന്ദേശങ്ങൾക്കായി ഹാൻഡ്ഷേക്ക് പിശകുകൾ നോക്കുക. ഈ ക്രമം സ്ഥിരമായി നിലനിർത്തുക, കാരണം ഓരോ ഘട്ടവും ഒരു മുഴുവൻ കാരണ വിഭാഗത്തെ ഒഴിവാക്കുന്നു.

ട്രാൻസ്പോർട്ട്, റിസോൾവ് ചെയ്ത ലക്ഷ്യം, പോർട്ട്, പിശകിന്റെ കൃത്യമായ പാഠം എന്നിവ എഴുതിവയ്ക്കുക. ക്ലയന്റ് പുനഃസ്ഥാപിക്കുന്നത് ആ തെളിവ് നശിപ്പിക്കുന്നു, സാധാരണയായി ഒന്നും മാറ്റുന്നുമില്ല.