VPN ഗേറ്റ്വേ അപ്ഡേറ്റ് പരാജയപ്പെടുന്നു: പുറത്തേക്കുള്ള വഴി തുറക്കുന്നതിന് മുൻപ് ഘട്ടം വായിക്കുക
പരാജയപ്പെട്ട അപ്ഡേറ്റ് കാണാതായ പോർട്ടിനെയല്ല, ഒരു ഘട്ടത്തെയാണ് പേരിടുന്നത്. സന്ദേശം അതിന്റെ ഉടമയുമായി ചേർക്കുക, പ്രോക്സി വഴി വായിക്കുക, എന്നിട്ട് പരിപാലന നയം ബോധപൂർവം തീരുമാനിക്കുക.
സുരക്ഷാ അപ്ഡേറ്റുകൾ ഇൻസ്റ്റാൾ ചെയ്യാൻ വിസമ്മതിക്കുന്നത് മറ്റൊരാളുടെ പ്രശ്നമാകാൻ ഒരു മോശം ആഴ്ച മാത്രം അകലെയാണ്, കൂടാതെ ക്ലയന്റുകളെ അനുവദിക്കുന്ന ഗേറ്റ്വേയാണ് ആ ശീലം വളർത്താൻ ഏറ്റവും എളുപ്പമുള്ള സ്ഥലം. സാധാരണ കാരണം കാണാതായ വഴിയല്ല, കാണാതായ തീരുമാനമാണ്: ക്ലയന്റ് ഫോർവേഡിംഗ് ബോധപൂർവം ഇടുങ്ങിയതാകുമ്പോൾ ഹോസ്റ്റ് തന്നെ ഒരു ശേഖരത്തിൽ എത്തേണ്ടത് എങ്ങനെയെന്ന് ആരും പറഞ്ഞില്ല. ആ തീരുമാനം വ്യക്തമായി എടുക്കണം, അത് ഒരു ഉച്ചയ്ക്ക് പുറത്തേക്കുള്ള നയം ഓഫ് ചെയ്യുന്നതിനേക്കാൾ ഇടുങ്ങിയതായിരിക്കണം.
നാല് ഘട്ടങ്ങൾ, നാല് വ്യത്യസ്ത ഉടമകൾ
അപ്ഡേറ്റ് പരാജയം ഒരു പേരിട്ട ഘട്ടമാണ്, സന്ദേശം അത് പറഞ്ഞാലും ഇല്ലെങ്കിലും, ഓരോ ഘട്ടവും വ്യത്യസ്ത ഉടമയുടേതാണ്. പരിഹരിക്കാനാകാത്ത പേര് റിസോൾവറിന്റെ ചോദ്യമാണ്. സമയം കഴിയുന്ന കണക്ഷൻ ഗതാഗതം, പ്രോക്സി അല്ലെങ്കിൽ ദൂരെയുള്ള അറ്റം എന്നിവയുടെ ചോദ്യമാണ്. TLS ഐഡന്റിറ്റി പിശക് വിശ്വാസത്തിന്റെ ചോദ്യമാണ്, കൂടാതെ നിരസിച്ച ശേഖര മെറ്റാഡാറ്റ ഒപ്പിന്റെ ചോദ്യമാണ്. നാല് ഘട്ടങ്ങൾ, നാല് ഉടമകൾ, പോർട്ട് നിയമം എപ്പോഴും അവയിലൊന്നിന് മാത്രമേ ഉത്തരം നൽകൂ.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
പിംഗും പേര് പരിഹാരവും ആളുകൾ ആദ്യം ആശ്രയിക്കുന്ന രണ്ട് പരിശോധനകളാണ്, രണ്ടും ആരും ചോദിക്കാത്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. എക്കോ പ്രതികരണം ശേഖര കണക്ഷനിൽ നിന്ന് വ്യത്യസ്ത പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു, വിജയകരമായ തിരയൽ ഡൗൺലോഡ് പരിശോധിക്കാതെ പേര് പരിഹാരത്തിൽ നിൽക്കുന്നു. രണ്ടും യഥാർത്ഥ ഇടപാട് പരാജയപ്പെടുമ്പോൾ കടക്കാം, രണ്ടും വഴിയുമായി ബന്ധമില്ലാത്ത കാരണങ്ങളാൽ പരാജയപ്പെടാം.
മാനേജർ യഥാർത്ഥത്തിൽ സ്വീകരിക്കുന്ന വഴി വായിക്കുക
കോൺഫിഗർ ചെയ്ത സ്രോതസ്സ് URIകളും പ്രോക്സിയുടെ യഥാർത്ഥ ക്രമീകരണവും പരിശോധിക്കുക, അവയിലൊന്ന് അനുമാനിക്കുന്നതിന് പകരം. സാധാരണ HTTPയ്ക്കായി എഴുതിയ നിയമം ശേഖരം HTTPS സംസാരിക്കുമ്പോൾ അറ്റകുറ്റപ്പണിയല്ല, പ്രോക്സി നിർബന്ധമാക്കുന്ന സ്ഥാപനം വഴി ഇതിനകം തിരഞ്ഞെടുത്തു. പാക്കേജ് മാനേജർമാർ പരിസ്ഥിതി ചരങ്ങളും സ്വന്തം കോൺഫിഗറേഷനും മാനിക്കുന്നു, ഹോസ്റ്റ്-നിർദ്ദിഷ്ട ക്രമീകരണങ്ങൾ ആഗോള ക്രമീകരണത്തെ മറികടക്കാം. ഇന്ററാക്ടീവ് ബ്രൗസർ ചെയ്യുന്നത് മാനേജർ ചെയ്യേണ്ടതാണ് എന്നില്ല.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxy
APT ഗതാഗത രേഖകൾ ഏത് ക്രമീകരണം ഏത് URI സ്കീമിന് ബാധകമാണെന്നും ഹോസ്റ്റ്-നിർദ്ദിഷ്ട തിരഞ്ഞെടുപ്പുകൾ എങ്ങനെ എഴുതുന്നുവെന്നും വിവരിക്കുന്നു. കമാൻഡുകളുടെ ഔട്ട്പുട്ട് ടിക്കറ്റിനൊപ്പം സൂക്ഷിക്കുക, കാരണം ഇത് പ്രോക്സി പ്രശ്നത്തെ കാണാതായ വഴിയിൽ നിന്ന് എത്രയും പിംഗ് ഫലങ്ങളെക്കാൾ വേഗത്തിൽ വേർതിരിക്കുന്നു. മാനേജർ ശ്രമിക്കുന്ന കൃത്യമായ ലക്ഷ്യം, പോർട്ട്, പ്രോട്ടോക്കോൾ എന്നിവ എഴുതുക, ഫയർവാൾ മാറ്റം മാസങ്ങൾക്കുള്ളിൽ പഴയതാകുന്ന ഊഹിച്ച കണ്ണാടി വിലാസത്തെക്കാൾ ആ രേഖയെ ആശ്രയിക്കട്ടെ.
പരിപാലന നയം തിരഞ്ഞെടുക്കുക, ഒഴിവാക്കലല്ല
മൂന്ന് നയങ്ങൾ സമർത്ഥിക്കാവുന്നതാണ്: തുരങ്കത്തിലൂടെ പരിപാലനം, കൈകാര്യം ചെയ്യുന്ന അപ്ഡേറ്റ് പ്രോക്സിയിലൂടെ പരിപാലനം, അല്ലെങ്കിൽ ഇടുങ്ങിയ അധികാരമുള്ള നേരിട്ടുള്ള വഴിയിലൂടെ പരിപാലനം. ഓരോന്നും അതിന് യോജിക്കുന്ന റിസോൾവർ ക്രമീകരണം സൂചിപ്പിക്കുന്നു. സമർത്ഥിക്കാനാകാത്തത് തുരങ്കം വീഴുമ്പോഴെല്ലാം നിശബ്ദമായി പരിധിയില്ലാത്ത പകരം വഴിയായി മാറുന്ന ഒഴിവാക്കലാണ്.
തിരഞ്ഞെടുത്ത നയം ഒരു ഉടമയോടൊപ്പം എഴുതുക, കാരണം അടുത്ത ഓപ്പറേറ്റർ നിയമം കണ്ടെത്തും, അതിന് പിന്നിലെ ന്യായീകരണമല്ല. അനുമതി നിലവിലുള്ള ഫയർവാളിലൂടെയും നെറ്റ്വർക്ക് ഉടമയിലൂടെയും പ്രയോഗിക്കുക, നിയമങ്ങൾ ഒഴിവാക്കിയോ ഒരു ഹോസ്റ്റിനായി രണ്ടാമത്തെ നയ മാനേജർ ചേർത്തോ അല്ല. യഥാർത്ഥ സ്രോതസ്സ് ഉപയോഗിക്കുന്ന വിലാസ കുടുംബങ്ങളും സേവന അന്ത്യബിന്ദുക്കളും ഉൾക്കൊള്ളുക, ശേഖരം സ്ഥലം മാറുമ്പോൾ പട്ടിക പുനഃപരിശോധിക്കുക.
വിശ്വാസം ദുർബലമാക്കാതെ പരിശോധിക്കുക
വിജയകരമായ ഗതാഗതം പരിശോധന അയച്ചുവിടാനുള്ള അനുമതിയല്ല: ആർക്കൈവ് പ്രാമാണീകരണവും TLS സെർവർ ഐഡന്റിറ്റിയും രണ്ട് വ്യത്യസ്ത പരിശോധനകളാണ്, അവയിലേതെങ്കിലും ഓഫ് ചെയ്യുന്നത് പിശക് മായ്ക്കുമ്പോൾ ഹോസ്റ്റ് എന്ത് സ്വീകരിക്കുമെന്ന് മാറ്റുന്നു. തടയുന്ന പ്രോക്സി നെറ്റ്വർക്ക് ഉടമയുടെ വിശ്വാസ തീരുമാനമാണ്, പരിശോധന പ്രാദേശികമായി ഓഫ് ചെയ്യാനുള്ള കാരണമല്ല, ശേഖരത്തിന്റെ ക്രെഡൻഷ്യലുകൾ പങ്കിട്ട ഡയഗ്നോസ്റ്റിക്സിൽ ഉണ്ടാകരുത്, കാരണം വിശദമായ ലോഗ് അവ ചോർത്താൻ ഏറ്റവും എളുപ്പമുള്ള സ്ഥലമാണ്.
മാറ്റം നിയന്ത്രിത മെറ്റാഡാറ്റ വീണ്ടെടുക്കലും തുടർന്ന് ഒരു അംഗീകൃത പാക്കേജ് ഇടപാടും ഉപയോഗിച്ച് സ്വീകരിക്കുക, എന്നിട്ട് തുരങ്കം വീഴുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്ന് പരീക്ഷിക്കുക. തടസ്സ സമയത്ത് നിശബ്ദമായി വിശാലമാകുന്ന പരിപാലന വഴി അടഞ്ഞ് പരാജയപ്പെടുന്ന വഴിയെക്കാൾ മോശമാണ്, ഫലം പേരിട്ട ഉടമയും പരിമിത വ്യാപ്തിയും ഉള്ള അപ്ഡേറ്റ് വഴിയായിരിക്കണം.