വെബ്സൈറ്റുകൾ VPN വഴി ലോഡ് ചെയ്യുന്നു, പക്ഷേ apt ശേഖരണത്തിൽ എത്തുന്നില്ല

VPN കണക്റ്റ് ചെയ്യുന്നു, ആന്തരിക വിക്കി ബ്രൗസറിൽ ലോഡ് ചെയ്യുന്നു, apt update ഇപ്പോഴും എത്തിച്ചേരാൻ കഴിയാത്ത ഒരു കണ്ണാടിയിൽ തൂങ്ങിക്കിടക്കുന്നു. ആ ചിത്രത്തിൽ തുരങ്കത്തിൽ ഒന്നും പൊട്ടിയിട്ടില്ല. ബ്രൗസറും പാക്കേജ് മാനേജറും രണ്ട് വേറിട്ട പ്രോക്സി തീരുമാനങ്ങൾ എടുത്തു, അവയിൽ ഒന്ന് മാത്രമാണ് കോൺഫിഗർ ചെയ്തിരുന്നത്.

ഏത് തീരുമാനം പരാജയപ്പെട്ടു എന്നത് ആദ്യം ഉറപ്പാക്കാൻ യോഗ്യമായ ഒരേയൊരു കാര്യമാണ്.

ക്രമീകരണം തൊടുന്നതിന് മുൻപ് പിശക് വായിക്കുക

ഓരോ ഘട്ടവും വ്യത്യസ്ത സന്ദേശം അവശേഷിപ്പിക്കുന്നു. ഒരിക്കലും പരിഹരിക്കാത്ത പേര് DNS, ഒരിക്കലും പൂർത്തിയാകാത്ത കണക്ഷൻ റൂട്ടിംഗ് അല്ലെങ്കിൽ ഫയർവാൾ, തൽക്ഷണ 407 പ്രോക്സി പ്രാമാണീകരണം, സർട്ടിഫിക്കറ്റിനെക്കുറിച്ചുള്ള പരാതി TLS സ്ഥിരീകരണം, ഒപ്പിന്റെ മുന്നറിയിപ്പ് ശേഖരണ മെറ്റാഡാറ്റ. ഈ അഞ്ച് പരാജയങ്ങൾക്ക് അഞ്ച് വ്യത്യസ്ത തിരുത്തലുകൾ വേണം, DNS പ്രശ്നത്തിന് മുകളിൽ ഒട്ടിച്ച പ്രോക്സി വരി തൂങ്ങൽ മറ്റൊരിടത്തേക്ക് നീക്കുക മാത്രം ചെയ്യുന്നു.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ആ കൃത്യമായ വരിയും അത് പേരിടുന്ന ശേഖരണവും പകർത്തുക. „സമയം കഴിഞ്ഞു“ എന്ന മങ്ങിയ ഓർമ്മയാണ് പത്ത് മിനിറ്റ് നീളുന്ന രോഗനിർണയത്തെ ഒരു മുഴുവൻ ഉച്ചകഴിഞ്ഞാക്കി മാറ്റുന്നത്.

APT അതിന്റേതായ പ്രോക്സി ക്രമീകരണങ്ങൾ സൂക്ഷിക്കുന്നു

APT /etc/apt/apt.conf.d/, പ്രധാന apt.conf, APT_CONFIG പേരിടുന്ന ഏത് ഫയലും വായിക്കുന്നു. ഇത് ഡെസ്ക്ടോപ്പ് പ്രോക്സി പ്രൊഫൈലോ GNOME നെറ്റ്വർക്ക് ക്രമീകരണമോ ബ്രൗസർ എക്സ്റ്റൻഷനോ വായിക്കുന്നില്ല. എന്നാൽ ഗതാഗതം പ്രോക്സി പരിസ്ഥിതി ചരങ്ങളെ മാനിക്കുന്നു, അതിനാൽ നിങ്ങളുടെ ഷെല്ലിൽ പ്രവർത്തിക്കുന്ന export https_proxy=... മറ്റൊരു പരിസ്ഥിതിയിൽ പ്രവർത്തിക്കുന്ന ടൈമറിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

പരാജയപ്പെടുന്ന പ്രക്രിയ യഥാർത്ഥത്തിൽ എന്ത് കാണുന്നു എന്ന് ഡംപ് ചെയ്യുക: apt-config dump | grep -i proxy.

പരാജയപ്പെടുന്ന പ്രവർത്തനം പ്രവർത്തിക്കുന്ന ഉപയോക്താവായി ഇത് പ്രവർത്തിപ്പിക്കുക. root മറ്റൊരു ഫയൽ കൂട്ടം വായിക്കുകയാണെങ്കിൽ, അല്ലെങ്കിൽ systemd ടൈമർ മറ്റൊരു പരിസ്ഥിതിയോടെ ആരംഭിക്കുകയാണെങ്കിൽ, ഡംപ് വ്യത്യാസപ്പെടും, ആ വ്യത്യാസമാണ് നിങ്ങളുടെ ഉത്തരം. പരസ്പരവിരുദ്ധമായ രണ്ട് പ്രോക്സി മൂല്യങ്ങൾ ഒരു കാണാത്ത മൂല്യത്തെക്കാൾ മോശമാണ്, കാരണം ഗതാഗതം കണ്ടെത്തുന്ന ഏറ്റവും നിർദ്ദിഷ്ട പൊരുത്തം പിന്തുടരുന്നു.

കോൺഫിഗറേഷന്റെ ഉടമ പ്രതീക്ഷിക്കുന്നിടത്ത് പ്രോക്സി ക്രമീകരിക്കുക

അഡ്മിൻ അനുവദിച്ച വ്യക്തമായ പ്രോക്സിക്ക് പുതിയ ഫയലിലെ ഒരു ചെറിയ ശകലം മതി:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

മൂന്നാമത്തെ വരി മിക്ക ഉദാഹരണങ്ങളും ഒഴിവാക്കുന്ന ഭാഗമാണ്. ഓരോ ഹോസ്റ്റിനുമുള്ള താക്കോൽ സാധാരണ മൂല്യത്തെ അതിലംഘിക്കുന്നു, അതിനാൽ തുരങ്കത്തിലൂടെ എത്താവുന്ന ആന്തരിക കണ്ണാടിക്ക് പ്രോക്സി ഒഴിവാക്കാം, ബാക്കിയെല്ലാം ഇപ്പോഴും അതിലൂടെ കടന്നുപോകുന്നു. DIRECT അതിനുള്ള രേഖപ്പെടുത്തിയ മൂല്യമാണ്, കാലി സ്ട്രിംഗ് അല്ല.

ശകലം പുതിയ ക്രമനമ്പറുള്ള ഫയലായി ചേർക്കുക, ഉദാഹരണത്തിന് /etc/apt/apt.conf.d/95proxy. വിതരണ ഫയൽ മേലെഴുതുന്നത് എന്നാൽ അടുത്ത പാക്കേജ് അപ്ഡേറ്റ് നിങ്ങളുടെ മാറ്റം നിശ്ശബ്ദമായി തിരികെ മാറ്റും.

ക്രെഡൻഷ്യലുകൾ URI ന് പുറത്ത് തുടരുന്നു

APT ഗതാഗത റെഫറൻസ് പ്രാമാണീകരണത്തിനായി apt_auth.conf ലേക്ക് ചൂണ്ടുന്നു, ഉപയോക്തൃനാമവും പാസ്വേഡും അവിടെയാണ് ചേരേണ്ടത്. അവ പ്രോക്സി URI യിൽ ഉൾച്ചേർക്കുന്നത് പ്രക്രിയ പട്ടികകളിലേക്കും ഷെൽ ചരിത്രത്തിലേക്കും ടിക്കറ്റിൽ ഒട്ടിച്ച ഓരോ കോൺഫിഗറേഷൻ ഡംപ്പിലേക്കും അവയെ കൊണ്ടുപോകുന്നു. പ്രാമാണീകരണ ഫയലിന് കർശനമായ അനുമതികൾ വേണം, കാരണം അത് ക്രെഡൻഷ്യലുകളുടെ സംഭരണിയാണ്.

സ്കീമും പരിശോധിക്കുക. HTTPS ശേഖരണത്തിൽ ഇപ്പോഴും HTTP പ്രോക്സി വഴി എത്താം; ഗതാഗതം കണ്ണാടിയുടെ URI സ്കീമിൽ നിന്ന് വേറിട്ട തിരഞ്ഞെടുപ്പാണ്.

ഗ്രാഫിക്കൽ സോഫ്റ്റ്വെയർ കേന്ദ്രം വേറിട്ട മുൻഭാഗമാണ്. അത് PackageKit അല്ലെങ്കിൽ snap ബാക്ക്എൻഡ് ഉപയോഗിക്കുന്നുവെങ്കിൽ, APT ശകലം അതിന് ഒന്നും മാറ്റുന്നില്ല, അതിനാൽ പരാജയപ്പെട്ട അഭ്യർത്ഥന ഏത് പ്രക്രിയയാണ് ചെയ്തതെന്ന് ഉറപ്പാക്കുക.

പാത ഉറപ്പാക്കുക, പുറത്തുകടക്കൽ കോഡ് മാത്രമല്ല

ശകലം സ്ഥാനത്തിരിക്കുമ്പോൾ പച്ച ഫലം വിശ്വസിക്കുന്നതിന് പകരം അഭ്യർത്ഥന നിരീക്ഷിക്കുക. apt-get -o Debug::Acquire::http=true update കണക്ഷൻ ശ്രമം, തിരഞ്ഞെടുത്ത പ്രോക്സി, പ്രതികരണ കോഡ് എന്നിവ അച്ചടിക്കുന്നു, ഇത് തെറ്റായ പ്രോക്സിയെ നിങ്ങളെ നിരസിച്ച പ്രോക്സിയിൽ നിന്ന് വേർതിരിക്കുന്നു.

തുടർന്ന് പ്രവർത്തിക്കാൻ പാടില്ലാത്ത സാഹചര്യം പരീക്ഷിക്കുക. VPN വിച്ഛേദിച്ച് ആന്തരിക കണ്ണാടി മറുപടി നൽകുന്നത് നിർത്തുന്നുവെന്ന് ഉറപ്പാക്കുക; അത് ഇപ്പോഴും ഡൗൺലോഡ് ചെയ്യുന്നുവെങ്കിൽ, എന്തോ തുരങ്കത്തിന് ചുറ്റും റൂട്ട് ചെയ്യുന്നു അല്ലെങ്കിൽ പഴയ കാഷെ നിങ്ങൾക്ക് സേവനം നൽകുന്നു. അനുവദനീയമായ പാത ഇപ്പോഴും TLS സ്ഥിരീകരിക്കുന്നുവെന്നും ഇപ്പോഴും ശേഖരണ ഒപ്പുകൾ പരിശോധിക്കുന്നുവെന്നും ഉറപ്പാക്കുക, കാരണം ട്രാഫിക് പരിശോധിക്കുന്ന പ്രോക്സി അവയിലൊന്നും അപ്രാപ്തമാക്കാനുള്ള കാരണമല്ല. പ്രാമാണീകരിക്കാത്ത ക്ലയന്റിന് നിശ്ശബ്ദ സമയപരിധിക്ക് പകരം വ്യക്തമായ നിരസിക്കൽ ലഭിക്കുന്നുവെന്നും ഉറപ്പാക്കുക.

പ്രവർത്തിക്കുന്ന ശകലവും പരാജയപ്പെട്ട ഔട്ട്പുട്ടും മാറ്റ രേഖയിൽ ഒരുമിച്ച് സൂക്ഷിക്കുക. അതേ തൂങ്ങൽ നേരിടുന്ന അടുത്ത വ്യക്തി രണ്ട് വരികളുടെ വ്യത്യാസം ഏത് വിശദീകരണത്തെക്കാളും വേഗം തിരിച്ചറിയും.