VPN കണക്റ്റ് ചെയ്യുമ്പോൾ മെയിൽ സമർപ്പണം പരാജയപ്പെടുന്നു: ഘട്ടം കണ്ടെത്തുക

രാവിലെ മുഴുവൻ പ്രവർത്തിച്ചിരുന്ന മെയിൽ, ടണൽ മുകളിലേക്ക് വരുന്ന നിമിഷം നിലയ്ക്കുന്നു, ഒപ്പം ആദ്യത്തെ പ്രേരണ പാസ്വേഡ് വീണ്ടും ടൈപ്പ് ചെയ്യുകയാണ്. ആ പ്രേരണ കൂടുതൽ പ്രയോജനകരമായ ചോദ്യം ഒഴിവാക്കുന്നു: ക്ലയന്റ് സർവറിൽ എത്തിയിരുന്നോ, ക്രെഡൻഷ്യലുകൾ നൽകാൻ മതിയായ ദൂരം പോയിരുന്നോ? ടൈംഔട്ട്, സർട്ടിഫിക്കറ്റ് പിശക്, നിരസിക്കൽ പ്രതികരണം എന്നിവ മൂന്ന് വ്യത്യസ്ത പരാജയങ്ങളാണ്, മൂന്നാമത്തേത് മാത്രമാണ് അക്കൗണ്ടുമായി ബന്ധപ്പെട്ടത്. ഘട്ടങ്ങൾ ക്രമത്തിൽ പരിശോധിക്കുക, അപ്പോൾ VPN കുറ്റപ്പെടുത്തേണ്ട സംശയാസ്പദനല്ല, പരീക്ഷിക്കാവുന്ന ചരമായി മാറുന്നു.

ഘട്ടം 1: ക്രെഡൻഷ്യലുകൾ തൊടുന്നതിന് മുൻപ് പരാജയം വർഗ്ഗീകരിക്കുക

ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ സൃഷ്ടിച്ച പിശക് വായിക്കുക, തുടർന്ന് അതിനെ മൂന്ന് കൊട്ടകളിൽ ഒന്നിൽ ഇടുക. ടൈംഔട്ട് അല്ലെങ്കിൽ കണക്ഷൻ റീസെറ്റ് എന്നാൽ TCP പാത പരാജയപ്പെട്ടു; TLS അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് പിശക് എന്നാൽ പാത പ്രവർത്തിച്ചു, ഹാൻഡ്ഷേക്ക് പ്രവർത്തിച്ചില്ല; കോഡുള്ള SMTP പ്രതികരണം എന്നാൽ മെയിൽ സർവർ മറുപടി നൽകി തീരുമാനമെടുത്തു. ഓരോ കൊട്ടയും വ്യത്യസ്ത ഉത്തരവാദിയെ ചൂണ്ടുന്നു.

കൊട്ടകൾ വേർതിരിക്കുന്നത് മൂല്യമുള്ളതാണ്, കാരണം പരിഹാരങ്ങൾ പരസ്പരവിരുദ്ധമാണ്. സർവർ അയച്ചയാളെ നിരസിക്കുമ്പോൾ ടൈംഔട്ട് നീട്ടുന്നത് ഉപകരിക്കില്ല, പാത തടയപ്പെട്ടിരിക്കുമ്പോൾ പാസ്വേഡ് മാറ്റുന്നത് ഒന്നും ചെയ്യില്ല. മറുപടി കോഡാണ് പട്ടികയിലെ ഏറ്റവും വിലപ്പെട്ട തെളിവ്, കാരണം മുഴുവൻ ഗതാഗത ശൃംഖലയും പ്രവർത്തിച്ചുവെന്നും പ്രശ്നം നയത്തിലോ ഐഡന്റിറ്റിയിലോ ആണെന്നും അത് തെളിയിക്കുന്നു. വീണ്ടും ശ്രമിക്കുന്നതിന് മുൻപ് കൃത്യമായ പാഠം സൂക്ഷിക്കുക, ഏതെങ്കിലും വിപുലീകൃത സ്റ്റാറ്റസ് കോഡ് ഉൾപ്പെടെ.

VPN-ന് പുറത്ത് പരാജയം പുനരുൽപ്പാദിപ്പിക്കാൻ കഴിയില്ലെങ്കിൽ ഇവിടെ നിർത്തുക. ഒരു യന്ത്രത്തിലെ ഒരു ആപ്ലിക്കേഷനിൽ കാണുന്ന പ്രശ്നം ഇപ്പോഴും നെറ്റ്വർക്ക് പ്രശ്നമല്ല.

ഘട്ടം 2: എൻഡ്പോയിന്റും TLS മോഡും സ്ഥിരീകരിക്കുക

സന്ദേശ സമർപ്പണം ഒരു പ്രത്യേക സേവനമാണ്, സർവർ-ടു-സർവർ റിലേയുമായി ഒരുപോലെയല്ല. സമർപ്പണത്തിനായി ദാതാവിന്റെ ഡോക്യുമെന്റേഷനിൽ നിന്ന് ഹോസ്റ്റ്നെയിം, പോർട്ട്, TLS മോഡ് എന്നിവ സ്ഥിരീകരിക്കുക, കാരണം മറ്റൊരു മെയിൽ ക്രമീകരണത്തിൽ നിന്ന് കടമെടുത്ത പരിചിതമായ പോർട്ട് തെളിവല്ല. പോർട്ട് 587 സാധാരണ ടെക്സ്റ്റ് അഭിവാദനവും തുടർന്ന് STARTTLS-ഉം പ്രതീക്ഷിക്കുന്നു, അതേസമയം പോർട്ട് 465 ആദ്യ ബൈറ്റിൽ നിന്ന് തന്നെ TLS പ്രതീക്ഷിക്കുന്നു.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

രണ്ടിൽ തെറ്റായ പരിശോധന പ്രവർത്തിപ്പിക്കുന്നത് ക്ലയന്റ് മറ്റൊരു മോഡിനായി ക്രമീകരിച്ചിരിക്കുമ്പോൾ വരുത്തുന്ന കൃത്യമായ തെറ്റാണ്. ഇംപ്ലിസിറ്റ്-TLS പരിശോധന 587-ൽ കുടുങ്ങുകയാണെങ്കിൽ, അല്ലെങ്കിൽ STARTTLS പരിശോധന 465-ൽ പരാജയപ്പെടുകയാണെങ്കിൽ, പോർട്ടും മോഡും പൊരുത്തപ്പെടുന്നില്ല. സർട്ടിഫിക്കറ്റ് പരിശോധന നിർത്തലാക്കുന്നതിന് പകരം ക്ലയന്റിൽ മോഡ് ശരിയാക്കുക, കാരണം അത് ക്രമീകരണ പിശകിനെ പരിശോധിക്കാത്ത കണക്ഷനാക്കി മാറ്റുന്നു. ഈ വിഭജനം സ്റ്റാൻഡേർഡാക്കാൻ മതിയാകും വിധം പഴക്കമുള്ളതാണ്: പോർട്ട് 465-ലെ ഇംപ്ലിസിറ്റ് TLS RFC 8314-ൽ വിവരിച്ച ക്രമീകരണമാണ്.

ഇവിടെ സർട്ടിഫിക്കറ്റ് പിശക് തടസ്സമല്ല, വിവരമാണ്. സർവർ അവതരിപ്പിച്ച ഐഡന്റിറ്റിയും ക്ലയന്റ് പ്രതീക്ഷിച്ച ഐഡന്റിറ്റിയും അത് പേരിടുന്നു, രണ്ടും കണക്ഷൻ ദുർബലമാക്കാതെ ശരിയാക്കാം.

ഘട്ടം 3: അക്കൗണ്ട് മാറ്റാതെ പാതകൾ താരതമ്യം ചെയ്യുക

എൻഡ്പോയിന്റ്, അക്കൗണ്ട്, ക്ലയന്റ് ക്രമീകരണങ്ങൾ സ്ഥിരമായി നിർത്തി പാത മാത്രം മാറ്റുക. ഒരിക്കൽ ടണൽ താഴെയും ഒരിക്കൽ മുകളിലും ആയിരിക്കുമ്പോൾ അയയ്ക്കുക, സർവർ കാണുന്ന പാതയും ഉറവിട വിലാസവും രേഖപ്പെടുത്തുക. പരാജയം പാതയെ പിന്തുടരുന്നെങ്കിൽ നിങ്ങൾ അതിനെ വേർതിരിച്ചു; യന്ത്രത്തെ പിന്തുടരുന്നെങ്കിൽ ഇല്ല.

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

പൂർണ്ണ ടണൽ ദാതാവ് കാണുന്ന ഉറവിട വിലാസം മാറ്റുന്നു, ചില ദാതാക്കൾ അപരിചിതമായ ഉറവിടത്തോട് അപരിചിതമായ പാസ്വേഡിനേക്കാൾ കർശനമായി പെരുമാറുന്നു. അത് അവരുടെ ഭാഗത്തുള്ള നയ തീരുമാനമാണ്, അത് ഗ്രേലിസ്റ്റോ നിരക്ക് പരിധിയോ ബ്ലോക്കോ ആകാം. ഒരു ദാതാവിൽ നിന്ന് എല്ലാവർക്കും സാമാന്യവൽക്കരിക്കരുത്, കൂടാതെ കാണാത്ത NAT നിയമം ഓരോ പരാജയവും വിശദീകരിക്കുന്നു എന്ന് കരുതരുത്. curl രേഖ ഏത് ഘട്ടം പരാജയപ്പെട്ടുവെന്ന് കാണിക്കുന്നു, ആപ്ലിക്കേഷന്റെ സ്വന്തം ലോഗ് കാണിക്കാത്തപ്പോഴും.

ടണൽ ഇന്റർനെറ്റ് ട്രാഫിക് വഹിക്കേണ്ടതാണെങ്കിൽ, അതിന്റെ റൂട്ടിംഗും എഗ്രസ് നയവും ഈ ലക്ഷ്യസ്ഥാനം അനുവദിക്കണം. സ്വകാര്യ റൂട്ടുകൾ മാത്രം വഹിക്കുന്ന ടണൽ മെയിൽ കണക്ഷനെ പ്രാദേശിക പാതയിൽ വിടുന്നു, അത് വേറെ താരതമ്യമാണ്.

ഘട്ടം 4: ഒരു നിരുപദ്രവകരമായ സന്ദേശം അയച്ച് പ്രതികരണം രേഖപ്പെടുത്തുക

പരാജയപ്പെട്ട ഘട്ടം ശരിയാക്കുക, തുടർന്ന് വെബ്മെയിൽ പേജിന് പകരം അതേ ആപ്ലിക്കേഷനിലൂടെ ഒരു നിരുപദ്രവകരമായ സന്ദേശം സമർപ്പിക്കുക. നിങ്ങൾ പരീക്ഷിക്കുന്നത് ആപ്ലിക്കേഷന്റെ സ്വന്തം അയയ്ക്കൽ പാതയാണ്, അതിന്റെ സംഭരിച്ച ക്രമീകരണങ്ങളും TLS മോഡും ഉൾപ്പെടെ. വെബ്മെയിൽ സെഷൻ അതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

പ്രതികരണം, പോർട്ട്, TLS മോഡ്, നിങ്ങൾ ഉപയോഗിച്ച പാത എന്നിവ രേഖപ്പെടുത്തുക, അടുത്ത വ്യക്തിക്ക് ഫലം പുനരുൽപ്പാദിപ്പിക്കാൻ കഴിയുന്നതിന്. പ്രവർത്തിക്കുന്ന ബ്രൗസറും പച്ച VPN ഐക്കണും മറ്റ് കാര്യങ്ങളെക്കുറിച്ചുള്ള നിരീക്ഷണങ്ങളാണ്. സന്ദേശം എത്തിയാൽ, ബാക്കിയുള്ള ജോലി ആ ക്രമീകരണം ഈ അക്കൗണ്ടിലൂടെ അയയ്ക്കുന്ന ഓരോ യന്ത്രത്തിനും സ്ഥിരസ്ഥിതിയാക്കുകയാണ്.

പരാജയപ്പെട്ട ഘട്ടം, ക്ലയന്റ് ഉപയോഗിക്കുന്ന പോർട്ടും TLS മോഡും, സന്ദേശം പോയ പാത, സർവർ തിരികെ നൽകിയ പ്രതികരണം എന്നിവ പേരിടാൻ കഴിയുമ്പോൾ ചെക്ക്ലിസ്റ്റ് പൂർണ്ണമാകുന്നു. ആ നാല് വസ്തുതകൾ അവ്യക്തമായ ഔട്ട്ബോക്സ് പ്രശ്നത്തെ ആർക്കെങ്കിലും അവലോകനം ചെയ്യാവുന്ന മാറ്റമാക്കി മാറ്റുന്നു.