നിങ്ങളുടെ VPN ഗേറ്റ്‌വേയ്ക്ക് ഇപ്പോഴും അപ്‌ഡേറ്റുകൾ ഇൻസ്റ്റാൾ ചെയ്യാനുള്ള ഒരു വഴി വേണം

ടണൽ അതിന് പിന്നിലുള്ള എല്ലാവർക്കും പ്രവർത്തിക്കുന്നു, ഗേറ്റ്‌വേ അവരുടെ ട്രാഫിക് കൈമാറുന്നു, എന്നിട്ടും യന്ത്രത്തിന് തന്നെ ഒരു സുരക്ഷാ അപ്‌ഡേറ്റ് ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയുന്നില്ല. പ്രശ്നത്തിന്റെ സാധാരണ രൂപം ഇതാണ്: ഫോർവേഡിംഗ് അനുമതി ക്ലയന്റുകൾക്ക് നൽകി, ഗേറ്റ്‌വേയുടെ സ്വന്തം പുറത്തേക്കുള്ള കണക്ഷനുകൾ പദ്ധതിയിൽ ഒരിക്കലും ഉൾപ്പെടുത്തിയില്ല. പാക്കേജ് മാനേജർ സ്വന്തം സോക്കറ്റുകൾ തുറക്കുന്നു, ഗേറ്റ്‌വേയിൽ നിന്ന്, ഫയർവാൾ നയത്തിൽ നിങ്ങൾ എവിടെയും പേരിടാത്ത ഒരു റിപ്പോസിറ്ററിയിലേക്ക്.

ഗേറ്റ്‌വേ ലോക്ക് ചെയ്യുന്നത് ശരിയാണ്. പാച്ചുകൾ സ്വീകരിക്കുന്നത് നിർത്തുന്നത്ര കർശനമായി ലോക്ക് ചെയ്യുന്നത് മറ്റൊരു തീരുമാനമാണ്, സാധാരണയായി ആകസ്മികമായത്.

ലോക്കൽ ഔട്ട്പുട്ട് ക്ലയന്റ് ഫോർവേഡിംഗ് അല്ല

ഫോർവേഡിംഗ് നിയമങ്ങൾ മറ്റെവിടെ നിന്നോ വന്ന് ഗേറ്റ്‌വേയിലൂടെ പുറത്തുപോകുന്ന പാക്കറ്റുകൾക്ക് ബാധകമാണ്. ഗേറ്റ്‌വേയുടെ സ്വന്തം അപ്‌ഡേറ്റ് ട്രാഫിക് അവയുമായി ഒരിക്കലും ഒത്തുപോകുന്നില്ല; അത് ലോക്കലായി സൃഷ്ടിക്കപ്പെട്ട് ഔട്ട്പുട്ട് പാതയിലൂടെ പോകുന്നു. ഈ വ്യത്യാസമാണ് ക്ലയന്റ് ആക്സസ് തികച്ചും പ്രവർത്തിക്കുമ്പോൾ അസാധ്യമെന്ന് തോന്നുന്ന പരാജയം വിശദീകരിക്കുന്നത്.

ഇത് പരിശോധനകളെ അതിജീവിക്കുന്ന ഒരു നയ വിടവും വിശദീകരിക്കുന്നു, കാരണം ടണലിന് പിന്നിലെ ലാപ്‌ടോപ്പിൽ നിന്നുള്ള പെട്ടെന്നുള്ള പരിശോധന ഫോർവേഡിംഗ് ശൃംഖല പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നു, ഹോസ്റ്റിന്റെ സ്വന്തം കണക്ഷനുകളെ കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. ഗേറ്റ്‌വേയെ രണ്ട് വിഷയങ്ങളായി കാണുക: ഫോർവേഡിംഗ് ശൃംഖലയുള്ള റൂട്ടറും ഔട്ട്പുട്ട് ശൃംഖലയുള്ള ഹോസ്റ്റും. രണ്ടിനും ഒരു അഭിപ്രായം വേണം, സാധാരണയായി ഒന്ന് മാത്രമാണ് എഴുതപ്പെടുന്നത്.

പരാജയപ്പെട്ട ഘട്ടത്തിന് പേര് നൽകുക

അപ്‌ഡേറ്റ് പിശകുകൾ വ്യത്യസ്ത അതിരുകൾക്ക് പേര് നൽകുന്നു, ഏതാണ് പരാജയപ്പെട്ടതെന്ന് വായിക്കുന്നതിന് മുമ്പ് പോർട്ട് നിയമത്തിലേക്ക് ചാടുന്നത് ഒരു ഉച്ചയ്ക്ക് ശേഷം നഷ്ടപ്പെടുത്തുന്നു. പരിഹരിക്കാനാകാത്ത റിപ്പോസിറ്ററി പേര് resolver ചോദ്യമാണ്, ഗതാഗത ചോദ്യമല്ല.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

വിജയകരമായ തിരയലിന് ശേഷമുള്ള സമയപരിധി ചോദ്യത്തെ ഗതാഗതത്തിലേക്ക് മാറ്റുന്നു: പാക്കേജ് മാനേജർ യഥാർത്ഥത്തിൽ ഏത് വിലാസം, ഏത് പോർട്ട്, ഏത് കോൺഫിഗർ ചെയ്ത പ്രോക്സി പരീക്ഷിച്ചു. TLS സ്ഥിരീകരണ പരാജയം മൂന്നാമത്തേത്, തികച്ചും വ്യത്യസ്തമായ ഒരു കാര്യമാണ്, കണക്ഷൻ ചർച്ചയ്ക്ക് മതിയായ നിലയിൽ പ്രവർത്തിച്ചു എന്നാണ് അർത്ഥം. ആർക്കൈവ് പ്രാമാണീകരണത്തെക്കുറിച്ചുള്ള പരാതി നാലാം ഘട്ടമാണ്, അത് എത്തിച്ചേരാനുള്ള കഴിവിനെക്കാളുപരി ഒപ്പിട്ട മെറ്റാഡാറ്റയെക്കുറിച്ചാണ്. നാല് ഘട്ടങ്ങൾ, നാല് വ്യത്യസ്ത അറ്റകുറ്റപ്പണികൾ, ping എപ്പോഴും ഒരു പാക്കേജ് മാനേജറും ഉപയോഗിക്കാത്ത ഒരു പ്രോട്ടോക്കോൾ മാത്രം വിവരിക്കുന്നു.

നിയമം ചേർക്കുന്നതിന് മുമ്പ് ഉറവിട പട്ടിക വായിക്കുക

ഓർമ്മയിലുള്ള ഉറവിടങ്ങൾക്ക് പകരം യഥാർത്ഥ ഉറവിട URIകളും ഫലപ്രദമായ പ്രോക്സി കോൺഫിഗറേഷനും പട്ടികപ്പെടുത്തുക. സാധാരണ HTTPക്കായി എഴുതിയ നിയമം ഉറവിടം HTTPS ആകുമ്പോൾ നിഷ്പ്രയോജനമാണ്, ഷെല്ലിന് അറിയാവുന്ന പ്രോക്സി ബൂട്ട് സമയത്ത് മറ്റൊരു പരിതസ്ഥിതിയോടെ ആരംഭിക്കുന്ന സേവനത്തിന് അദൃശ്യമായിരിക്കാം.

APTൽ HTTP ഗതാഗത രേഖ പരിസ്ഥിതി, APT-നിർദ്ദിഷ്ട പ്രോക്സി ക്രമീകരണങ്ങൾ ഉൾക്കൊള്ളുന്നു, ഓരോ ഹോസ്റ്റിനുമുള്ള തിരഞ്ഞെടുപ്പുകൾ ഉൾപ്പെടെ, അതിന്റെ HTTPS ഗതാഗതത്തിന് സ്വന്തം സ്ഥിരീകരണ ക്രമീകരണങ്ങളുണ്ട്. ബ്രൗസർ എടുക്കുന്ന പാതയും പാക്കേജ് മാനേജർ എടുക്കുന്ന പാതയും വെവ്വേറെ പാതകളാണ്, ഒരേ യന്ത്രത്തിൽ പോലും.

ഉറവിടങ്ങൾ ഏത് വിലാസ കുടുംബങ്ങളിലേക്ക് പരിഹരിക്കപ്പെടുന്നു എന്ന് ശ്രദ്ധിക്കുക. IPv4 മാത്രം അനുവദിക്കുന്ന നിയമം, ഉറവിടങ്ങൾ AAAA റെക്കോർഡ് ഇഷ്ടപ്പെടുന്ന ഹോസ്റ്റിൽ പരാജയപ്പെട്ടുകൊണ്ടിരിക്കും, പിശക് ഇടയ്ക്കിടെ കാണുന്നതുപോലെ തോന്നുന്നു, കാരണം ഏത് ഉത്തരം ആദ്യം എത്തുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

ഒരു അറ്റകുറ്റപ്പണി പാത തിരഞ്ഞെടുത്ത് അതിൽ ഉറച്ചുനിൽക്കുക

മൂന്ന് പ്രതിരോധിക്കാവുന്ന ഓപ്ഷനുകളുണ്ട്: അറ്റകുറ്റപ്പണി ട്രാഫിക് ടണലിലൂടെ, മാനേജുചെയ്ത അപ്‌ഡേറ്റ് പ്രോക്സിയിലൂടെ, അല്ലെങ്കിൽ ഇടുങ്ങിയ നേരിട്ടുള്ള ഒഴിവാക്കലിലൂടെ. ഒന്ന് ബോധപൂർവം തിരഞ്ഞെടുത്ത് resolver അതിനോട് യോജിക്കാൻ ഇടയാക്കുക, കാരണം പേരുകൾ ഒരു ദിശയിലേക്ക് പരിഹരിക്കപ്പെടുകയും കണക്ഷനുകൾ മറ്റൊരു ദിശയിലേക്ക് പോകുകയും ചെയ്യുന്ന വിഭജനം ആർക്കും വിശദീകരിക്കാനാകാത്ത പരാജയങ്ങൾ സൃഷ്ടിക്കുന്നു.

നിങ്ങൾ എന്ത് തിരഞ്ഞെടുത്താലും, അത് പരിധിയില്ലാത്ത ബദൽ പാതയാകരുത്. ടണൽ താഴെയായിരിക്കുമ്പോൾ നേരിട്ടുള്ള പുറത്തേക്കുള്ള ട്രാഫിക് നിരോധിച്ചിട്ടുണ്ടെങ്കിൽ, നിശ്ശബ്ദമായി എല്ലാം അനുവദിക്കുന്ന അറ്റകുറ്റപ്പണി ഒഴിവാക്കൽ പരിഹാരത്തിന്റെ വേഷത്തിലുള്ള നയമാറ്റമാണ്. ടണലിന്റെ സ്വന്തം അന്തിമബിന്ദുവും bootstrap ആവശ്യകതകളും റിപ്പോസിറ്ററി ആക്സസിൽ നിന്ന് വേറിട്ട വിഭാഗത്തിൽ സൂക്ഷിക്കുക, കാരണം അവ വ്യത്യസ്ത ലക്ഷ്യസ്ഥാനങ്ങളിലേക്ക് ചൂണ്ടുന്നു, വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു, അതിനാൽ ഒരു ഒഴിവാക്കൽ മറ്റൊന്നിനെ മൂടാൻ കഴിയില്ല.

പരിശോധനകൾ ദുർബലമാക്കാതെ സ്ഥിരീകരിക്കുക

നയം ഇതിനകം ഉള്ള ഫയർവാളിലൂടെത്തന്നെ പരിധി പ്രയോഗിക്കുക, ഒരു ഗൈഡ് അത് ഉപയോഗിച്ചതിനാൽ രണ്ടാമതൊരു മാനേജർ ചേർക്കുന്നതിന് പകരം. തുടർന്ന് പരിപാലിക്കുന്ന നയത്തിന് കീഴിൽ മെറ്റാഡാറ്റ റിഫ്രെഷും ഒരു യഥാർത്ഥ പാക്കേജ് ഇടപാടും പ്രവർത്തിപ്പിച്ച്, പുറത്തുകടക്കൽ നില മാത്രമല്ല ഔട്ട്പുട്ടും വായിക്കുക.

വിജയകരമായ ഗതാഗതം സ്ഥിരീകരണം അയച്ചുകൊടുക്കാനുള്ള അനുമതിയല്ല. ആർക്കൈവ് പ്രാമാണീകരണവും TLS സെർവറിന്റെ അനന്യതയും വേറിട്ട ഉറപ്പുകളാണ്, പിശക് ശാന്തമാക്കാൻ അവയിലൊന്ന് പ്രവർത്തനരഹിതമാക്കുന്നത് നിങ്ങൾ എന്തിൽ വിശ്വസിക്കുന്നു എന്നതിനെ മാറ്റുന്നു, നിങ്ങൾക്ക് എത്താൻ കഴിയുന്നതിനെയല്ല.

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