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

ലക്ഷണം: ലക്ഷ്യസ്ഥാനം LAN വിലാസം കാണുന്നു

ഒരു ക്ലയന്റ് LAN വിലാസത്തിൽ പ്രോക്സിയുമായി ബന്ധിപ്പിക്കുന്നു, പ്രോക്സി ലക്ഷ്യസ്ഥാനത്തേക്ക് സ്വന്തം കണക്ഷൻ തുറക്കുന്നു. ആ രണ്ടാം കണക്ഷൻ കർണലിന്റെ നിയമങ്ങൾ പ്രകാരം ഉറവിട വിലാസം തിരഞ്ഞെടുക്കുന്നു, സ്വതവേ അത് റൂട്ട് തിരയൽ തിരഞ്ഞെടുക്കുന്നതാണ്. അതിനാൽ ഓരോ ബൈറ്റും പ്രോക്സിയിലൂടെ കടന്നുപോയിട്ടും ലക്ഷ്യസ്ഥാനം ഹോസ്റ്റിന്റെ പ്രാഥമിക വിലാസം രേഖപ്പെടുത്തുന്നു. കൈമാറ്റത്തിന്റെ കാര്യത്തിൽ ഒന്നും തകർന്നിട്ടില്ല, അതുകൊണ്ടാണ് പ്രോക്സി ലോഗിന് ഇതേക്കുറിച്ച് പറയാൻ ഒന്നുമില്ലാത്തത്.

ആ തകരാറിന്റെ കണ്ണാടി ചിത്രം കണ്ടെത്താൻ എളുപ്പമാണ്: പുറത്തേക്കുള്ള ഉറവിടം ടണൽ വിലാസത്തിൽ പിന്നിയിട്ടാൽ LAN ക്ലയന്റുകൾ ശ്രോതാവിനെ ഒട്ടും എത്തിപ്പിടിക്കില്ല. ആ പതിപ്പ് സ്വയം പ്രഖ്യാപിക്കുന്നു, ആദ്യത്തേത് പ്രവർത്തിക്കുന്ന അഭ്യർത്ഥനയുടെ പിന്നിൽ ഒളിക്കുന്നു. രണ്ടും ഒരു നിർദ്ദേശം രണ്ട് ചോദ്യങ്ങൾക്കും ഉത്തരം നൽകുന്നതായി കാണുന്നതിൽ നിന്നാണ് ഉണ്ടാകുന്നത്.

മൂന്ന് നിർദ്ദേശങ്ങൾ, മൂന്ന് വ്യത്യസ്ത വിലാസങ്ങൾ

Listen പ്രോക്സി ക്ലയന്റുകളെ സ്വീകരിക്കുന്ന പ്രാദേശിക വിലാസത്തെ പേരിടുന്നു. Bind പുറത്തേക്ക് പ്രോക്സി ഉണ്ടാക്കുന്ന കണക്ഷനുകൾക്ക് ഉറവിട വിലാസം നൽകുന്നു, BindSame ഇപ്പോൾ സ്വീകരിച്ച കണക്ഷന്റെ പ്രാദേശിക വിലാസം വീണ്ടും ഉപയോഗിക്കാൻ അതിനോട് പറയുന്നു. ഇവ മൂന്ന് വെവ്വേറെ ചോദ്യങ്ങളാണ്, ഒരു വരി അവയിൽ ഒന്നിന് മാത്രം ഉത്തരം നൽകുന്നു. അവ കൂട്ടിക്കലർത്തുന്നതാണ് മാറ്റം ഒന്നും ചെയ്യാത്തതായി തോന്നുന്നതിന്റെ സാധാരണ കാരണം.

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

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

ശ്രോതാവിനെയും പുറത്തേക്കുള്ള ഉറവിടത്തെയും വെവ്വേറെ ക്രമീകരിക്കുക

LAN വിലാസം 192.168.50.10 ഉം ടണൽ വിലാസം 10.90.0.3 ഉം ഉള്ള ഒരു ഹോസ്റ്റ് എടുക്കുക. LAN ക്ലയന്റുകൾ പ്രോക്സിയിൽ എത്തണമെങ്കിൽ, അവരുടെ അഭ്യർത്ഥനകൾ ടണലിലൂടെ പുറത്തുപോകണമെങ്കിൽ, ഇവ രണ്ട് സ്വതന്ത്ര തീരുമാനങ്ങളാണ്, രണ്ടും എഴുതണം. താഴെയുള്ള ഭാഗം കൃത്യമായി അതു മാത്രം പറയുന്നു.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

ഇത് പൂർണ്ണ കോൺഫിഗറേഷൻ അല്ല, അതിനാൽ അംഗീകരിച്ച പോർട്ട്, പ്രാമാണീകരണം, ക്ലയന്റ് പ്രവേശന നിയന്ത്രണങ്ങൾ, ലക്ഷ്യ നിയന്ത്രണങ്ങൾ എന്നിവ നിലനിർത്തുക. രണ്ട് വിലാസങ്ങളും Tinyproxy-യുടെ നെറ്റ്വർക്ക് നാമമിടത്തിനുള്ളിൽ ഈ ഹോസ്റ്റിന് ഉള്ളതായിരിക്കണം, കാരണം പ്രോസസ്സിന് കൈവശപ്പെടുത്താൻ കഴിയാത്ത Bind മൂല്യം തുടക്കത്തിലല്ല, കണക്ട് ചെയ്യുമ്പോൾ പരാജയപ്പെടുന്നു. BindSame yes മറ്റൊരു നയം വിവരിക്കുന്നു: സ്വീകരിച്ച കണക്ഷന്റെ പ്രാദേശിക വിലാസമാണ് പുറത്തേക്കുള്ള ഉറവിടമാകുന്നത്. നിലവിലെ റിലീസുകളിൽ ആ ശാഖയ്ക്ക് Bind പട്ടികയേക്കാൾ മുൻഗണനയുണ്ട്, അങ്ങനെയാണ് ക്രമീകരിച്ച ഉറവിടം പിശകില്ലാതെ അപ്രത്യക്ഷമാകുന്നത്.

ഉറവിടം സൂചിപ്പിക്കുന്ന പാത പരിശോധിക്കുക

ഉറവിട വിലാസം തിരഞ്ഞെടുക്കുന്നത് പാത ഉണ്ടാക്കുന്നില്ല, അതിനാൽ ആ ഉറവിടവും ആ ലക്ഷ്യവും കൊണ്ട് കർണൽ എന്ത് ചെയ്യുമെന്ന് ചോദിക്കുക. ടണൽ ഇന്റർഫേസ് പേരിടുന്ന തിരയൽ കുറഞ്ഞ തെളിവാണ്, LAN ഇന്റർഫേസ് പേരിടുന്നത് ഉറവിടം എഴുതിയതുപോലെ പ്രവർത്തിക്കാൻ കഴിയില്ല എന്നാണ് അർത്ഥം. തിരയൽ സന്ദർഭാധിഷ്ഠിതമാണ്: ആ നാമമിടത്തിന് ബാധകമായ നയ നിയമങ്ങളും പട്ടികയും അത് വിലയിരുത്തുന്നു. അത് ഒരു കണക്ഷനല്ല, താഴെയുള്ള NAT സേവനത്തിന് എന്ത് അവതരിപ്പിക്കും എന്നതിനെക്കുറിച്ചും ഒന്നും പറയുന്നില്ല.

ip -4 route get 203.0.113.25 from 10.90.0.3

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

ലക്ഷ്യസ്ഥാനത്ത് ഉറവിടം സ്ഥിരീകരിക്കുക

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

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl ട്രാഫിക് ജനറേറ്റർ മാത്രമാണ്; പരിശോധിക്കാൻ യോഗ്യമായ വിലാസം ദൂരെയുള്ള വശം രേഖപ്പെടുത്തിയതാണ്, curl യാദൃച്ഛികമായി ബന്ധിപ്പിച്ച പങ്കാളിയല്ല. രണ്ടും ഒത്തുപോകുന്നില്ലെങ്കിൽ, വ്യത്യാസം ഉറവിട-തിരഞ്ഞെടുപ്പിൽ നിന്നാണോ അതിൽ കൂടുതൽ മാറ്റത്തിൽ നിന്നാണോ എന്ന് തീരുമാനിക്കുക, കാരണം അവ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ ശരിയാക്കുന്നു. വിലാസ മാറ്റങ്ങളും പ്രോക്സി പുനരാരംഭങ്ങളും ഒരുമിച്ച് ആസൂത്രണം ചെയ്യുക, കാരണം ടണലിന് ഇനി ഇല്ലാത്ത വിലാസം ബന്ധിപ്പിക്കുന്നത് വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷം നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു. DNS, IPv6 സ്വഭാവവും വെവ്വേറെ നിർവചിക്കുക, കാരണം മുകളിലെ IPv4 ഭാഗം രണ്ടിനെക്കുറിച്ചും ഒന്നും തെളിയിക്കുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ