HTTP പ്രോക്സി ശൃംഖലയിലെ DNS പരാജയങ്ങൾ: ഏത് ഹോപ്പാണ് പേര് പരിഹരിക്കുന്നത്?
ശൃംഖലയായ ഫോർവേഡ് പ്രോക്സി പരിശോധിക്കുമ്പോൾ പ്രാദേശിക പ്രോക്സിയിലേക്കുള്ള എത്തിച്ചേരൽ, പാരന്റ് പരിഹരിക്കൽ, വെബ്സൈറ്റ് പരിഹരിക്കൽ എന്നിവ വേർതിരിക്കുക.
client → local forward proxy → HTTP parent → websiteഎല്ലാ DNS-ഉം “പ്രോക്സിയുടേതാണ്” എന്ന് പറയുന്നതിനുപകരം പരാജയപ്പെടുന്ന പേരിൽ നിന്ന് തുടങ്ങുക:
| ആവശ്യമായ പേര് | അതിൽ എത്തേണ്ട ഹോപ്പ് |
|---|---|
| പ്രാദേശിക പ്രോക്സി എൻഡ്പോയിന്റ് | ക്ലയന്റ് |
| HTTP പാരന്റ് എൻഡ്പോയിന്റ് | പ്രാദേശിക ഫോർവേഡ് പ്രോക്സി |
| വെബ്സൈറ്റ് എൻഡ്പോയിന്റ് | അന്തിമ കണക്ഷൻ തുറക്കുമ്പോൾ പാരന്റ് |
എൻഡ്പോയിന്റുകൾ ഹോസ്റ്റ്നെയിമുകളാകുമ്പോൾ ഈ ഹോപ്പുകൾക്ക് വ്യത്യസ്ത റിസോൾവറുകൾ ഉപയോഗിക്കാം. HTTPS-ന്, ഫോർവേഡ് പ്രോക്സിക്ക് CONNECT-ന്റെ ലക്ഷ്യ ഹോസ്റ്റും പോർട്ടും പാരന്റിന് നൽകാം; പാരന്റാണ് അന്തിമ കണക്ഷൻ ഉണ്ടാക്കുന്നത്. യഥാർത്ഥ ക്ലയന്റ് ആദ്യം വെബ്സൈറ്റ് പരിഹരിക്കേണ്ടതില്ല. സാധാരണ HTTP കൈമാറ്റവും ലക്ഷ്യവിവരം മുന്നോട്ട് കൊണ്ടുപോകുന്നു.
ഓരോ പേരും കൃത്യം ഒരു യന്ത്രം മാത്രം ചോദിക്കും എന്ന വാഗ്ദാനമല്ല ഇത്. ACL വിലയിരുത്തൽ, കാഷിംഗ്, നയം, നടപ്പാക്കൽ വിശദാംശങ്ങൾ എന്നിവ അധിക തിരച്ചിലുകൾക്ക് കാരണമാകാം.
പാരന്റ് ലഭ്യമല്ലാത്തപ്പോൾ ഫാൾബാക്ക് നയം പരിശോധിക്കുക. നേരിട്ടുള്ള ആക്സസ് അനുവദിച്ചിട്ടുണ്ടെങ്കിൽ, പ്രാദേശിക പ്രോക്സി സ്വന്തം റിസോൾവർ, സ്രോതസ്സ് വിലാസ തീരുമാനങ്ങളോടെ വെബ്സൈറ്റിനഭിമുഖമായ ഹോപ്പാകാം. പാരന്റ് കോൺഫിഗർ ചെയ്യുന്നത് മാത്രം ഓരോ അഭ്യർത്ഥനയും അത് ഉപയോഗിച്ചു എന്ന് തെളിയിക്കുന്നില്ല.
പരാജയത്തിൽ, hosts ഫയൽ തിരുത്തുന്നതിന് മുമ്പ് പേരും അത് പരിഹരിക്കാൻ ശ്രമിക്കുന്ന പ്രോസസ്സും തിരിച്ചറിയുക. ക്ലയന്റ് ഭാഗത്തെ തിരുത്തൽ തുടർന്നുള്ള എല്ലാ തീരുമാനങ്ങളും ശരിയാക്കാനാവില്ല. അന്തിമ പൊതു സ്രോതസ്സ് വെബ്സൈറ്റ് കണക്ഷൻ തുറക്കുന്ന ഹോപ്പിന്റേതാണ്; ആ സ്രോതസ്സ് നിരീക്ഷിക്കുന്നത് DNS എവിടെ സംഭവിച്ചു എന്ന് അളക്കുന്നതിന് തുല്യമല്ല.