Postfix, VPN, smarthost: ക്യൂ ഒരു ഫയർവാൾ അല്ല

VPN ഉയരുന്നതുവരെ മെയിൽ ക്യൂവിൽ നിർത്തുന്നത് ഷെഡ്യൂളിംഗ് പ്രശ്നമാണ്, സാധാരണ പരിഹാരം Postfix നിർത്തി, main.cf മാറ്റി, വീണ്ടും ആരംഭിക്കുകയാണ്. അത് പ്രവർത്തിക്കുന്നു, അത് തെറ്റായ രൂപമാണ്, കാരണം അത് രണ്ട് ആവശ്യങ്ങൾ കലർത്തുന്നു: ഡെലിവറി എപ്പോൾ ശ്രമിക്കണം, ഏത് നെറ്റ്വർക്ക് വഴിക്ക് അത് കൊണ്ടുപോകാം. രണ്ടാമത്തേത് ഫയർവാളിന്റെ തീരുമാനമാണ്, ഒരു Postfix നിർദ്ദേശത്തിനും അത് എടുക്കാനാവില്ല. രണ്ടും വേർതിരിച്ചാൽ, ഓരോന്നിനും ചെറുതും പരിശോധിക്കാവുന്നതുമായ ഉത്തരമുണ്ട്.

റിലേയുടെ ലക്ഷ്യം സ്ഥിരമായി നിർത്തുക, നെറ്റ്വർക്ക് അതിർത്തിയിൽ നേരിട്ടുള്ള ഡെലിവറി തടയുക, കാത്തിരിപ്പ് ക്യൂവിന് വിടുക.

ആളുകൾ ഒന്നായി ചേർക്കുന്ന രണ്ട് ആവശ്യങ്ങൾ

റിലേ Postfix-നോട് മെയിൽ എവിടെ ഏൽപ്പിക്കണം എന്ന് പറയുന്നു; relayhost = [smtp.corp.example]:587 ഹോസ്റ്റും പോർട്ടും പേരിടുന്നു, ബ്രാക്കറ്റുകൾ ആ അടുത്ത ഹോപ്പിന് MX അധിഷ്ഠിത തിരഞ്ഞെടുപ്പ് അടിച്ചമർത്തുന്നു. പാത കേർണലിനോട് പാക്കറ്റുകൾക്ക് എവിടെ പോകാമെന്ന് പറയുന്നു. പാത നിയന്ത്രണമില്ലാത്ത ശരിയായ relayhost പോലും റൂട്ടിംഗ് പട്ടിക അനുവദിക്കുമ്പോൾ Postfix നേരിട്ട് ഇന്റർനെറ്റിൽ എത്താൻ അനുവദിക്കുന്നു, തെറ്റായ relayhost-നൊപ്പം ശരിയായ ഫയർവാൾ മെയിൽ തെറ്റായ സ്ഥലത്ത് അയയ്ക്കുന്നു. ഒന്നും മറ്റൊന്നിനെ അർത്ഥമാക്കുന്നില്ല.

ട്രാൻസ്പോർട്ട് മാപ്പുകൾ, അയച്ചയാൾക്കനുസരിച്ചുള്ള മാറ്റങ്ങൾ, ഫോൾബാക്ക് റിലേകൾ എന്നിവയ്ക്ക് ഓരോന്നിനും അതേ വായന അർഹതയുണ്ട്. സ്ഥിരമായ relayhost കോൺഫിഗർ ചെയ്ത എല്ലാ ഡെലിവറി പാതയും അത് ഉപയോഗിക്കുന്നു എന്നതിന് തെളിവല്ല, റിലേ ഒഴിവാക്കുന്ന ഫോൾബാക്ക് പാത മികച്ച വേഷത്തിലുള്ള അതേ പരാജയമാണ്.

defer_transports യഥാർത്ഥത്തിൽ ചെയ്യുന്നത്

defer_transports പേരിട്ട ട്രാൻസ്പോർട്ടുകൾക്കുള്ള സന്ദേശങ്ങൾ പിടിച്ചുവയ്ക്കുന്നു, അതിനാൽ ക്യൂ ഓട്ടം അവയെ സ്പർശിക്കുന്നതുവരെ ഡെലിവറി ശ്രമമുണ്ടാകില്ല. ഇത് ഷെഡ്യൂളിംഗ് നിയന്ത്രണമാണ്, ക്യൂ ഫ്ലഷ് അതിനെ മറികടക്കുന്നു; അത് രൂപകൽപ്പനയാണ്, വീഴ്ചയല്ല. master.cf-ലെ യഥാർത്ഥ ട്രാൻസ്പോർട്ട് നാമങ്ങൾ ഉപയോഗിക്കുക, കാരണം ഇഷ്ടാനുസൃത ട്രാൻസ്പോർട്ടോ വേറെ പേരുള്ള റിലേ ട്രാൻസ്പോർട്ടോ അതിന്റെ പ്രോഗ്രാം SMTP-യും സംസാരിക്കുന്നു എന്നത് മാത്രം കൊണ്ട് ഉൾപ്പെടുത്തപ്പെടുന്നില്ല. സാധാരണ വീണ്ടും ശ്രമം മറ്റൊരു സംവിധാനമാണ്: fail-closed പാതയിൽ ഡെലിവറി ശ്രമങ്ങൾ വെറുതെ പരാജയപ്പെട്ട് ക്യൂവിൽ തുടരുന്നു, കാലതാമസ നിർദ്ദേശം ഒന്നും ഇടപെടുന്നില്ല.

സ്ഥിരമായ പരാജയങ്ങൾ മര്യാദയോടെ കാത്തിരിക്കുന്നില്ല. മോശം സ്വീകർത്താവോ നിരസിച്ച ക്രെഡൻഷ്യലോ ടണൽ പ്രത്യക്ഷപ്പെടുന്നതുവരെ ഇരിക്കുന്നതിനുപകരം തിരികെ പോകുന്നു അല്ലെങ്കിൽ കടുത്ത പിശകായി കുടുങ്ങുന്നു, അതിനാൽ കാലതാമസമുള്ള മെയിൽ നിറഞ്ഞ ക്യൂ സ്വയമേവ സുരക്ഷിത ക്യൂ അല്ല.

നെറ്റ്വർക്ക് പാളിയിൽ പാത നിർബന്ധമാക്കുക

നിയന്ത്രണം പ്രാദേശിക ഔട്ട്പുട്ട് അതിർത്തിയിലോ ഒറ്റപ്പെട്ട നെറ്റ്വർക്ക് നാമസ്ഥലത്തിനുള്ളിലോ ആണ്. റിലേയുടെ യഥാർത്ഥ വിലാസങ്ങൾ, ട്രാൻസ്പോർട്ട്, പോർട്ട് എന്നിവ ഉൾക്കൊള്ളണം, പ്രവർത്തനക്ഷമമാണെങ്കിൽ IPv6-ഉം, കാരണം TCP 25 തടയുന്ന നിയമം 587 അല്ലെങ്കിൽ 465-ലെ റിലേയ്ക്ക് ഒന്നും ചെയ്യുന്നില്ല. ലൂപ്പ്ബാക്കും പ്രാദേശിക സമർപ്പണ പാതകളും വേർതിരിച്ച് നിർത്തുക, ക്യൂ തന്നെ പ്രവർത്തിക്കാൻ. ടണൽ പാത മാഞ്ഞുപോകുമ്പോഴോ മറ്റൊരു ഇന്റർഫേസ് പേരിൽ വീണ്ടും പ്രത്യക്ഷപ്പെടുമ്പോഴോ നയം അടച്ച് നിൽക്കണം.

ഇന്റർഫേസ് ഉയർന്നു എന്ന സംഭവം അതിലൂടെ റിലേ എത്തിച്ചേരാമെന്ന് തെളിയിക്കുന്നില്ല. അതുകൊണ്ടാണ് ലിങ്ക് പരിശോധിച്ച് ശേഷം ഫ്ലഷ് ചെയ്യുന്ന ഹുക്ക് ഒരു സൗകര്യമല്ലാതെ ഉറപ്പല്ലാത്തത്: പരിശോധനയ്ക്കും ഡെലിവറി ശ്രമത്തിനും ഇടയിൽ ലിങ്ക് മാറാം.

ഒരു ഹാനികരമല്ലാത്ത സന്ദേശം കൊണ്ട് തെളിയിക്കുക

VPN താഴെയായിരിക്കെ ഒരു ഹാനികരമല്ലാത്ത സന്ദേശം അയയ്ക്കുക, തുടർന്ന് കാലതാമസ കാരണത്തിനും ക്യൂ ID-യ്ക്കുമായി postqueue -p പരിശോധിക്കുക. ഉദ്ദേശിച്ച പാത പുനഃസ്ഥാപിച്ച് നിയന്ത്രിത ക്യൂ ഓട്ടം അഭ്യർത്ഥിക്കുക, സന്ദേശം മറ്റെവിടെയോ അല്ലാതെ റിലേ വഴി പുറപ്പെടുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക. തുടർന്ന് പറക്കുന്നതിനിടയിൽ പാത വീണ്ടും മുറിക്കുക, സന്ദേശം ക്യൂവിലേക്ക് തിരികെ വരുന്നുവെന്ന് ഉറപ്പാക്കുക. തടസ്സം എത്ര കാലം നീണ്ടുനിൽക്കാമെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് maximal_queue_lifetime പരിശോധിക്കുക, കാരണം പൂജ്യം മൂല്യം അർത്ഥമാക്കുന്നത് ഒരു ശ്രമമാണ്, പരിധിയില്ലാത്ത സംരക്ഷണമല്ല.

ക്യൂവിന്റെ പ്രായവും ഡിസ്ക് ഉപയോഗവും നിരീക്ഷിക്കുക. VPN-നായി കാത്തിരിക്കുന്ന നയം, വെള്ളിയാഴ്ച മുതൽ ക്യൂ വളരുന്നത് ആരും ശ്രദ്ധിക്കുന്നില്ലെങ്കിൽ മെയിൽ തടസ്സമായി മാറുന്നു.

റിലേ, ട്രാൻസ്പോർട്ട്, ഫയർവാൾ നിയമം, ആയുസ്സ് എന്നിവ ഒരുമിച്ച് രേഖപ്പെടുത്തുക. ആ നാലും ക്രമീകരണം വിവരിക്കുന്നു; അവയിലേതെങ്കിലും ഒറ്റയ്ക്ക് ഊഹം മാത്രം വിവരിക്കുന്നു.