VPN ഇല്ലാതെ മെയിൽ സെർവറിൽ എത്തുന്നു: നിയമം എവിടെ നടപ്പാക്കണം

മെയിൽ തുടർച്ചയായി ചോദിക്കുന്നു, VPN ഓഫ് ആണ്, എന്നിട്ടും അക്കൗണ്ട് സിങ്ക് ചെയ്യുന്നു. ആപ്പ് തനിക്ക് കോൺഫിഗർ ചെയ്തത് ചെയ്യുന്നു; സാധാരണ മെയിൽ പ്രൊഫൈലിൽ സെർവർ ടണലിലൂടെ മാത്രമേ ലഭ്യമാകൂ എന്ന് എവിടെയും പറയുന്നില്ല. അത് രണ്ട് വ്യത്യസ്ത ആവശ്യകതകൾ ബാക്കിയാക്കുന്നു, അവ കൂട്ടിക്കുഴയ്ക്കാൻ എളുപ്പമാണ്: സേവനം നേരിട്ടുള്ള ക്ലയന്റുകളെ നിരസിക്കണം, അല്ലെങ്കിൽ Mac ഒട്ടും ശ്രമിക്കരുത്.

ഉൽപ്പന്നം തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് ആവശ്യകത തിരഞ്ഞെടുക്കുക. സെർവർ നിയമവും ക്ലയന്റ് നിയമവും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരാജയപ്പെടുന്നു, വ്യത്യസ്ത തെളിവുകൾ നൽകുന്നു, വ്യത്യസ്ത ഉടമകൾക്കുള്ളതാണ്. രണ്ടും പ്രയോഗിക്കുന്നത് രണ്ട് പ്രസ്താവനകളും ശരിയാകുമ്പോൾ സാധുവാണ്, പക്ഷേ ഒന്ന് മറ്റൊന്നിന്റെ പകരമല്ല. രണ്ട് ആവശ്യകതകളും ന്യായമാണ്; അവ ഒരേ നിയന്ത്രണമല്ലെന്ന് മാത്രം.

ലക്ഷണം Mac പോലെ തോന്നുന്നു, പക്ഷേ ചോർച്ച സെർവർ ആകാം

മെയിൽ ടണലിന് പുറത്ത് സിങ്ക് ചെയ്യുമ്പോൾ, സെർവർ എന്ത് സ്വീകരിക്കുന്നു എന്നതിൽ നിന്ന് തുടങ്ങുക. മെയിൽ ലിസണർ ഇന്റർനെറ്റിൽ നിന്നുള്ള നേരിട്ടുള്ള കണക്ഷനോട് പ്രതികരിക്കുന്നുവെങ്കിൽ, ക്ലയന്റ് ഭാഗത്തെ ഒരു സൗകര്യ ക്രമീകരണവും ആ വസ്തുത മാറ്റുന്നില്ല. Mac ഇപ്പോഴും തുറന്നിരിക്കുന്ന ഒരു സേവനത്തോട് സാധാരണമായി പെരുമാറുന്നു.

സേവനം ഏത് ഉറവിട വിലാസം കാണുന്നുവെന്ന് മെയിൽ അഡ്മിനിസ്ട്രേറ്ററിനോട് ചോദിക്കുക. VPN ഗേറ്റ്വേ, റിവേഴ്സ് പ്രോക്സി അല്ലെങ്കിൽ ലോഡ് ബാലൻസർ ക്ലയന്റ് വിലാസം പരിവർത്തനം ചെയ്യാം, അതിനാൽ VPN കോൺഫിഗറേഷനിലെ വിലാസ പൂൾ മെയിൽ പ്രോസസ്സിലേക്ക് എത്തുന്നതുമായി പൊരുത്തപ്പെട്ടെന്ന് വരില്ല. തെറ്റായ ഉറവിടത്തിനെതിരെ എഴുതിയ നിയമം എല്ലാവരെയും തടയുന്നു അല്ലെങ്കിൽ ആരെയും തടയുന്നില്ല.

ആ ഉത്തരം സേവനത്തിന് VPN ക്ലയന്റുകളെ ഒട്ടും വേർതിരിച്ചറിയാനാകുമോ എന്നും പറയുന്നു. ഓരോ ക്ലയന്റും ഒരേ പ്രോക്സി വിലാസത്തിലൂടെ വന്നാൽ, ഉറവിടാധിഷ്ഠിത പ്രവേശനത്തിന് അവരെ വേർതിരിക്കാനാകില്ല, ആവശ്യകത പ്രാമാണീകരണത്തിലേക്കോ ക്ലയന്റ് ഭാഗത്തേക്കോ മാറ്റണം.

സെർവറിലെ പ്രവേശനം: ആപ്പിനെയല്ല, ഉറവിടത്തെ നിരസിക്കുക

ഹോസ്റ്റ് അല്ലെങ്കിൽ നെറ്റ്വർക്ക് ഫയർവാൾ പ്രാമാണീകരണവും TLS-ഉം മാറ്റാതെ മെയിൽ ലിസണറെ അംഗീകൃത ഉറവിട ശ്രേണികളിൽ പരിമിതപ്പെടുത്താം. ദൂര വിലാസങ്ങൾ, സബ്നെറ്റുകൾ അല്ലെങ്കിൽ ശ്രേണികൾ യോജിക്കുന്ന നിയമ വ്യവസ്ഥ സാധാരണ നിർമ്മാണ ഘടകമാണ്; കൃത്യമായ വാക്യഘടന സെർവറിന്റെ ഫയർവാൾ ഉൽപ്പന്നത്തിന്റേതാണ്, മെയിൽ ആപ്പിന്റേതല്ല.

ആവശ്യകത «സേവനം നേരിട്ടുള്ള ക്ലയന്റുകൾക്ക് സേവനം നൽകരുത്» എന്നാകുമ്പോൾ ഇതാണ് ഏറ്റവും ശക്തമായ അതിർത്തി. ഉപയോക്താവ് മറ്റൊരു മെയിൽ ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്താലും ഇത് നിലനിൽക്കുന്നു, കാരണം നിരസിക്കൽ പ്രാമാണീകരണത്തിന് മുൻപ് സംഭവിക്കുന്നു. സ്വന്തം VPN നയം അവഗണിക്കുന്ന Mac-നെയും ഇത് അതിജീവിക്കുന്നു.

അതിന്റെ പരിധിയും അത്രതന്നെ പ്രധാനമാണ്. നിരസിച്ച കണക്ഷൻ സേവനം സെഷൻ നിരസിച്ചു എന്ന് തെളിയിക്കുന്നു; Mac ഒരു ശ്രമവും നടത്തിയില്ലെന്ന് തെളിയിക്കുന്നില്ല. DNS റെസല്യൂഷൻ, മുൻ ലോഡ് ബാലൻസറിലേക്കുള്ള TCP SYN, പരാജയത്തിന് ശേഷമുള്ള വീണ്ടും ശ്രമം — എല്ലാം സെർവർ നിയമത്തിൽ എത്തുന്നതിന് മുൻപ് സംഭവിക്കാം. ആവശ്യകത പ്രവേശനത്തെക്കുറിച്ചല്ല, ശ്രമങ്ങളുടെ വെളിപ്പെടുത്തലിനെക്കുറിച്ചാണെങ്കിൽ, സെർവർ പ്രവേശനം നിയന്ത്രണത്തിന്റെ പകുതി മാത്രമാണ്.

ക്ലയന്റിൽ നടപ്പാക്കൽ: ടണൽ മാത്രമല്ല, ശ്രമം തടയുക

ക്ലയന്റ് ഭാഗത്തെ നിയമം ട്രാഫിക് നിരോധിക്കണം, മെയിൽ തുറക്കുമ്പോൾ ടണൽ ആരംഭിക്കുക മാത്രം ചെയ്യരുത്. മെയിൽ ഡൊമെയ്നിനുള്ള ആക്ടിവേഷൻ ട്രിഗർ ശരിയായ നിമിഷത്തിൽ VPN ഉയർത്താം, പക്ഷേ ടണൽ ഓഫ് ആയിരിക്കുമ്പോഴോ അത് പരാജയപ്പെട്ടതിന് ശേഷമോ എന്ത് സംഭവിക്കുന്നു എന്ന് അത് നിർവചിക്കുന്നില്ല.

എൻഡ്പോയിന്റ് ഉൽപ്പന്നത്തിന്റെ പിന്തുണയുള്ള ബ്ലോക്കിംഗ് നയം ഉപയോഗിക്കുക, അതിന്റെ പരിധി ബോധപൂർവം നിശ്ചയിക്കുക. ആപ്പ് തലത്തിലെ നിയമം ആ മെയിൽ ആപ്പിലെ എല്ലാ അക്കൗണ്ടുകളെയും ഉൾക്കൊള്ളുന്നു, വ്യക്തിഗത അക്കൗണ്ടുകൾ ഉൾപ്പെടെ. ലക്ഷ്യ തലത്തിലെ നിയമം ജോലി അക്കൗണ്ടിന്റെ IMAP, അയയ്ക്കൽ, പ്രാമാണീകരണ എൻഡ്പോയിന്റുകൾ പേരെടുത്ത് പറയണം, ആ വിലാസങ്ങൾ മാറുമ്പോഴും പ്രവർത്തിക്കണം.

രണ്ട് വിലാസ കുടുംബങ്ങളെയും നിലവിലുള്ള സെഷനുകളെയും ഉൾക്കൊള്ളുക. പുതിയ IPv4 കണക്ഷനുകൾ തടയുകയും IPv6 അല്ലെങ്കിൽ സ്ഥാപിത സോക്കറ്റ് തൊടാതെ വിടുകയും ചെയ്യുന്ന നയം ക്രമരഹിതമായി തോന്നുന്ന ഇടവിട്ടുള്ള സിങ്കുകൾ സൃഷ്ടിക്കുന്നു. നെറ്റ്വർക്ക് മാറ്റങ്ങളും സ്ലീപ്പ് ചക്രങ്ങളും അതേ പരീക്ഷയുടെ ഭാഗമാണ്.

ആപ്പ്, ലക്ഷ്യ തലത്തിലെ നിയമങ്ങൾക്ക് വ്യത്യസ്ത സ്വാധീന പരിധിയുണ്ട്

ആപ്പ് തലത്തിലെ തടയൽ മനസ്സിലാക്കാൻ ലളിതമാണ്: ടണൽ ഇല്ലാതെ മെയിലിൽ നിന്ന് ഒരു ട്രാഫിക്കും പുറത്തുപോകുന്നില്ല. അത് പരുക്കനുമാണ്, കാരണം അതേ ആപ്പിൽ നയവുമായി യാതൊരു ബന്ധവുമില്ലാത്ത വ്യക്തിഗത അക്കൗണ്ട് ഉണ്ടാകാം. ഉപയോക്താക്കൾ അത് ആദ്യം ശ്രദ്ധിക്കുകയും തകർന്ന മെയിൽ ആപ്പ് എന്ന് റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്യുന്നു.

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

ആവശ്യകതയുടെ വാക്കുകൾക്കനുസരിച്ച് തിരഞ്ഞെടുക്കുക. «ഈ ജോലി അക്കൗണ്ട് നേരിട്ട് കണക്ട് ചെയ്യരുത്» ലക്ഷ്യ പരിധിയെ സൂചിപ്പിക്കുന്നു. «ഈ Mac VPN-ന് പുറത്ത് മെയിൽ പ്രവർത്തിപ്പിക്കരുത്» വിശാലമായ ആപ്പ് നിയമത്തെ ന്യായീകരിക്കുന്നു, ഉടമ വ്യക്തിഗത അക്കൗണ്ടിലെ പാർശ്വഫലം സ്വീകരിക്കുന്നെങ്കിൽ.

നിരസിക്കലും അഭാവവും വെവ്വേറെ പരീക്ഷിക്കുക

സമർപ്പിത പരീക്ഷണ അക്കൗണ്ടിനൊപ്പം VPN വഴി കണക്ട് ചെയ്ത് സാധാരണ പ്രവർത്തനം സ്ഥിരീകരിക്കുക. തുടർന്ന് ഡിസ്കണക്ട് ചെയ്ത് രണ്ടുതവണ പരീക്ഷിക്കുക: ഒരിക്കൽ സെർവർ ലോഗിൻ നിരസിക്കുന്നുണ്ടോ എന്ന് കാണാൻ, മറ്റൊരിക്കൽ Mac ഒട്ടും കണക്ഷൻ ശ്രമിക്കുന്നുണ്ടോ എന്ന് കാണാൻ. ഇവ വ്യത്യസ്ത നിരീക്ഷണങ്ങളാണ്, അവ വ്യത്യസ്ത ലോഗുകളിൽ പെടുന്നു.

ഡിസ്കണക്ട് ആയിരിക്കുമ്പോൾ SYN അല്ലെങ്കിൽ DNS ചോദ്യത്തിനുള്ള ക്ലയന്റ് ഭാഗത്തെ തെളിവുകളും, നിരസിച്ച അല്ലെങ്കിൽ സ്വീകരിച്ച സെഷനുള്ള സെർവർ ലോഗും നിരീക്ഷിക്കുക. സെർവർ നിരസിക്കുന്നുവെങ്കിലും ക്ലയന്റ് ഇപ്പോഴും ശ്രമിക്കുന്നുവെങ്കിൽ, സെർവർ നിയമം പ്രവർത്തിക്കുന്നു, ക്ലയന്റ് നിയമം ഇല്ല. ക്ലയന്റ് ഒരു ശ്രമവും നടത്തുന്നില്ലെങ്കിലും സെർവർ ഇപ്പോഴും മറ്റ് ക്ലയന്റുകളെ സ്വീകരിക്കുന്നുവെങ്കിൽ, അതിർത്തി നിങ്ങൾ ഇട്ട അതേ സ്ഥലത്താണ്.

നടപ്പാക്കലിന്റെ ഉടമ, സെർവർ യഥാർത്ഥത്തിൽ കാണുന്ന ഉറവിട വിലാസം, ഉപയോഗിച്ച പരീക്ഷണ അക്കൗണ്ട് എന്നിവ രേഖപ്പെടുത്തുക. അടുത്ത നെറ്റ്വർക്ക് അല്ലെങ്കിൽ പ്രോക്സി മാറ്റം ആ ഉറവിടത്തെ നീക്കാം, നിരീക്ഷിച്ച മൂല്യം പേരെടുത്ത് പറയുന്ന കുറിപ്പ് മറ്റൊരു ഊഹക്കച്ചവടത്തേക്കാൾ വേഗത്തിൽ പരിശോധിക്കപ്പെടുന്നു.