VPN വീണ്ടും കണക്ട് ചെയ്ത ശേഷവും പ്രോക്സി പഴയ ടണൽ വിലാസത്തിൽ തന്നെയാണോ?

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

രണ്ടാമത്തെ പരാജയമാണ് അപകടകരമായത്: ടണൽ പ്രവർത്തിക്കുന്നു, പേജുകൾ ലോഡ് ചെയ്യുന്നു, പുറത്തേക്കുള്ള വിലാസം മാത്രം തെറ്റാണ്.

ടണലിൽ നിന്നല്ല, ലിസണറിൽ നിന്ന് തുടങ്ങുക

കളിയിൽ മൂന്ന് വിലാസങ്ങളുണ്ട്, വീണ്ടും കണക്ട് ചെയ്യുന്നത് അവയിൽ ചിലതിനെ മാത്രം നീക്കുന്നു. ലിസണർ എന്നത് നിങ്ങളുടെ ബ്രൗസർ ചൂണ്ടുന്ന സ്ഥലമാണ്, സാധാരണയായി 127.0.0.1 അല്ലെങ്കിൽ ഒരു LAN വിലാസം, ടണൽ മാറിയതിനെക്കുറിച്ച് അതിന് കാര്യമില്ല. പുറത്തേക്കുള്ള പ്രാദേശിക ഉറവിടം എന്നത് ഫോർവേഡർ അടുത്ത ചുവട് ഡയൽ ചെയ്യുമ്പോൾ കെർണലിനോട് ഉപയോഗിക്കാൻ ആവശ്യപ്പെടുന്നതാണ്, അത് ടണൽ ഉപകരണവുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. പൊതു എക്സിറ്റ് എന്നത് ഒരു വെബ് സെർവർ രേഖപ്പെടുത്തുന്നതാണ്, അത് പല ചുവടുകൾ അകലെയുള്ള വിവർത്തനം ചെയ്ത വിലാസമായിരിക്കാം.

പൊതു IP തിരയൽ അവസാന ചോദ്യത്തിന് മാത്രം ഉത്തരം നൽകുന്നു. ഒരു പൊതു എക്സിറ്റിന് പല ആന്തരിക ഉറവിടങ്ങളും മറയ്ക്കാനാകുന്നതിനാൽ, ഫോർവേഡർ ഏത് പ്രാദേശിക വിലാസത്തിൽ ബന്ധിക്കണമെന്ന് അത് പറയാനാവില്ല. കണക്ഷൻ സ്വന്തമായുള്ളവരിൽ നിന്ന് വിലാസം വായിക്കുക: ക്ലയന്റിന്റെ സ്റ്റാറ്റസ് ഔട്ട്പുട്ട്, ഇന്റർഫേസ് തന്നെ, അല്ലെങ്കിൽ ടണൽ കഴിയുന്ന നെയിംസ്പേസ്. ടണലിനോട് സാമ്യമുള്ള പേരുള്ള ആദ്യ ഇന്റർഫേസ് എടുക്കുന്നത് രണ്ടാമതൊരു പ്രൊഫൈൽ ഉള്ള നിമിഷം തെറ്റായ ഉത്തരം നൽകുന്നു.

കണ്ടെയ്നർ, നെയിംസ്പേസ് ക്രമീകരണങ്ങൾ ഈ അനുമാനം നിശബ്ദമായി തകർക്കുന്നു. ഒരു നെറ്റ്വർക്ക് നെയിംസ്പേസിലെ ഫോർവേഡർ മറ്റൊന്നിലുള്ള ടണലിൽ ബന്ധിക്കാനാവില്ല, കോൺഫിഗറേഷൻ എത്ര തിരുത്തിയാലും അത് ശരിയാകില്ല.

എന്തെങ്കിലും തിരുത്തുന്നതിന് മുൻപ് നാല് പരിശോധനകൾ

ഇവ ക്രമത്തിൽ ചെയ്യുക. ആദ്യം പരാജയപ്പെടുന്ന പരിശോധനയാണ് നിങ്ങൾ നിർത്തുന്നിടം, കാരണം പിന്നീടുള്ളവ മുൻപുള്ളവ ശരിയെന്ന് അനുമാനിക്കുന്നു.

1. ഉപയോഗിക്കുന്ന ടണൽ പ്രോക്സി നിർമ്മിച്ച പ്രൊഫൈൽ തന്നെയാണെന്ന് ഉറപ്പാക്കുക, സ്വയം കണക്ട് ചെയ്ത രണ്ടാമത്തെ പ്രൊഫൈൽ അല്ല.
2. ആ ഉപകരണത്തിൽ ഇപ്പോഴുള്ള വിലാസം പ്രിന്റ് ചെയ്ത് പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനിലെ വിലാസവുമായി താരതമ്യം ചെയ്യുക.
3. ഡിസ്കിലെ ഫയൽ അവകാശപ്പെടുന്നതല്ല, ഫോർവേഡർ ഏത് ഉറവിടമാണ് കണ്ടെത്തിയതെന്ന് ചോദിക്കുക.
4. ഫോർവേഡറിൽ നിന്നുള്ള ട്രാഫിക് യഥാർത്ഥത്തിൽ നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന റൂട്ടിംഗ്, ഫയർവാൾ നയത്തിന് വിധേയമാണെന്ന് ഉറപ്പാക്കുക.

ഉപകരണ വിലാസം എളുപ്പമാണ്: ip -4 addr show dev tun0 നിലവിലുള്ളത് പ്രിന്റ് ചെയ്യുന്നു, ip -4 route get 1.1.1.1 ആ ലക്ഷ്യത്തിന് കെർണൽ ഏത് ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുമെന്ന് കാണിക്കുന്നു. കൃത്യമായ വിലാസത്തിൽ ബന്ധിക്കുന്ന ഫോർവേഡർ വിലാസം അപ്രത്യക്ഷമാകുമ്പോൾ ഉച്ചത്തിൽ പരാജയപ്പെടുന്നു. ഉപകരണത്തിൽ ബന്ധിക്കുന്നതോ ഡിഫോൾട്ട് ഉറവിടത്തിലേക്ക് മടങ്ങുന്നതോ ആയ ഫോർവേഡർ പ്രവർത്തനം തുടരുകയും ചോരുകയും ചെയ്യുന്നു, അതാണ് നിശബ്ദ ഫലം.

ഡോക്യുമെന്റേഷൻ നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന പതിപ്പുമായി ചേർക്കുക, തിരയലിന്റെ ഏറ്റവും മുകളിലെ ഫലവുമായി അല്ല. Squid-ന്റെ ഔട്ട്ഗോയിംഗ് വിലാസ നിർദ്ദേശം v7-നും അതിന് മുൻപുള്ളവയ്ക്കും ഡോക്യുമെന്റ് ചെയ്തിരിക്കുന്നു, v8 ഡോക്യുമെന്റേഷൻ ആ നിർദ്ദേശം അവിടെ ലഭ്യമല്ലെന്ന് വ്യക്തമായി പറയുന്നു, അതിനാൽ അതിനെ ആശ്രയിച്ചുള്ള സ്ക്രിപ്റ്റ് ആ അതിർത്തി കടക്കില്ല (Squid tcp_outgoing_address റഫറൻസ് കാണുക). എന്തെങ്കിലും വീണ്ടും ലോഡ് ചെയ്യുന്നതിന് മുൻപ് ഉൽപ്പന്നത്തിന്റെ സ്വന്തം പാഴ്സർ ഉപയോഗിച്ച് സാധൂകരിക്കുക: squid -k parse പിശകുകൾ റിപ്പോർട്ട് ചെയ്ത് പ്രവർത്തിക്കുന്ന പ്രോസസ്സ് തൊടാതെ പുറത്തുപോകുന്നു.

ഓരോ ടണലിനും നമ്പർ നൽകി പഴയ മാറ്റങ്ങൾ ഒഴിവാക്കുക

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

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

തുറന്ന സോക്കറ്റുകൾ പുതിയ വിലാസത്തെ പിന്തുടരില്ല

ഫോർവേഡർ വീണ്ടും കോൺഫിഗർ ചെയ്യുന്നത് ഇതിനകം സ്ഥാപിച്ച കണക്ഷനുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. അവ ഒഴിഞ്ഞുപോകുമോ മരിക്കുമോ എന്നത് ഉൽപ്പന്നത്തെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ അനുമാനിക്കാതെ സ്വഭാവം നിരീക്ഷിക്കുക.

മാറ്റത്തിന് മുൻപ് തുറന്ന സോക്കറ്റിലൂടെ നൽകുന്ന അഭ്യർത്ഥന പുതിയ കോൺഫിഗറേഷൻ ശരിയാണെങ്കിലും പഴയ വഴിയിലൂടെയാണ് പുറത്തുപോകുന്നത്. അത് പ്രധാനമെങ്കിൽ വ്യക്തമായി തീരുമാനിക്കുക: ഒരു ചെറിയ ഒഴിവാക്കൽ കാലയളവ് അനുവദിച്ച് പുതിയ ജോലി സ്വീകരിക്കുന്നത് നിർത്തുക, അല്ലെങ്കിൽ പഴയ സോക്കറ്റുകൾ അവസാനിപ്പിച്ച് പിശകുകൾ സ്വീകരിക്കുക. തുടർന്ന് പുതിയ കണക്ഷനിൽ പരിശോധിച്ച് ആ ഫലം ഒഴിവാക്കൽ പരിശോധനയിൽ നിന്ന് വേർതിരിച്ചിടുക. ഉറവിടത്തിൽ ബന്ധിക്കുന്നതും സുരക്ഷാ അതിർത്തിയല്ല. ട്രാഫിക് ഒരിക്കലും സാധാരണ റൂട്ട് തൊടരുതെങ്കിൽ, അടയാളങ്ങളും ഫയർവാൾ നിയമങ്ങളും ഉപയോഗിച്ച്, DNS-ഉം IPv6-ഉം ഉൾപ്പെടെ നടപ്പാക്കുക, വീണ്ടും ലോഡ് ചെയ്യൽ പരാജയപ്പെട്ടാൽ പ്രോക്സി തുറന്നിടാതെ വ്യക്തമായി ഓഫ് ആയിരിക്കട്ടെ.

പുതിയ എക്സിറ്റ് പുതിയ അഭ്യർത്ഥനയിലൂടെ തെളിയിക്കുക

പ്രധാനമായത് സജീവമാക്കലിന് ശേഷം തുറന്ന അഭ്യർത്ഥനയാണ്, ping അല്ല, ഇതിനകം കാഷ് ചെയ്ത പേജുമല്ല. പ്രോക്സിയോട് യഥാർത്ഥ URL ആവശ്യപ്പെട്ട് ദൂരെയുള്ള അറ്റം റിപ്പോർട്ട് ചെയ്യുന്ന എക്സിറ്റ് വിലാസം വായിക്കുക, തുടർന്ന് ദാതാവ് ഒന്ന് കാണിക്കുമ്പോൾ ക്ലയന്റിന്റെ ടണലിനെക്കുറിച്ചുള്ള സ്വന്തം കാഴ്ചപ്പാടുമായി താരതമ്യം ചെയ്യുക.

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

വീണ്ടും ലോഡ് ചെയ്യൽ പരാജയപ്പെട്ടാൽ സേവനം നിർത്തി ഭാഗം നന്നാക്കുക; പഴയ എക്സിറ്റിനൊപ്പം സേവനം നൽകുന്ന പ്രോക്സി ഒരു ചെറിയ തടസ്സത്തേക്കാൾ മോശമാണ്. വീണ്ടും ലോഡ് ചെയ്യൽ വിജയിച്ചിട്ടും പുതിയ അഭ്യർത്ഥന ഇപ്പോഴും എവിടെയോ അപ്രതീക്ഷിതമായി പുറത്തുപോകുന്നെങ്കിൽ, വിലാസങ്ങൾ വീണ്ടും തിരുത്തുന്നതിന് പകരം റൂട്ടിംഗ് പരിശോധനയിലേക്ക് മടങ്ങുക. നിങ്ങൾ സാധൂകരിച്ച ടണൽ തലമുറ രേഖപ്പെടുത്തുക, അടുത്ത വീണ്ടും കണക്ഷന് താരതമ്യം ചെയ്യാൻ കൃത്യമായ എന്തെങ്കിലും ഉണ്ടാകട്ടെ.