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

റീഡയറക്ട് ചെയ്ത പാക്കറ്റ് യഥാർത്ഥത്തിൽ എവിടെ എത്തുന്നു

ഗേറ്റ്വേയിലെ സുതാര്യമായ പ്രോക്സി PREROUTING-ലെ nat പട്ടികയിൽ REDIRECT ഉപയോഗിച്ച് വരുന്ന കണക്ഷന്റെ ലക്ഷ്യം ലോക്കൽ പോർട്ടിലേക്ക് വീണ്ടും എഴുതുന്നു. വീണ്ടും എഴുതിയ ലക്ഷ്യം പാക്കറ്റ് എത്തിയ ഇന്റർഫേസിൽ നിന്ന് കാണുന്ന ലോക്കൽ വിലാസമാണ്, മറ്റെവിടെയോ ആരംഭിച്ച പ്രോസസ്സിന്റെ ലൂപ്പ്ബാക്ക് വിലാസമല്ല. 127.0.0.1-ൽ മാത്രം ബന്ധിപ്പിച്ച ശ്രോതാവ് ഹോസ്റ്റിൽ ഇതിനകം ലോക്കൽ ആയിരുന്ന കണക്ഷനുകൾ സ്വീകരിക്കുന്നു, ടണൽ ട്രാഫിക് പരാജയപ്പെടുമ്പോൾ പ്രവർത്തനം തുടരുന്ന അവസ്ഥ കൃത്യമായി അതാണ്. ക്ലയന്റിന്റെ സ്വന്തം ലൂപ്പ്ബാക്ക് മൂന്നാമത്തെ വിലാസമാണ്, ഒരിക്കലും ഗേറ്റ്വേ നിയമത്തിന്റെ ലക്ഷ്യമല്ല.

അതിനാൽ അപ്സ്ട്രീം ക്രെഡൻഷ്യലുകൾ തൊടുന്നതിന് മുമ്പ് രണ്ട് വസ്തുതകൾ ഉറപ്പാക്കുക: നിയമം ഏത് ലോക്കൽ വിലാസത്തിലേക്ക് വീണ്ടും എഴുതുന്നു, പ്രോക്സി സോക്കറ്റ് ഏത് വിലാസത്തിലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നു.

ശ്രോതാവും റീഡയറക്ട് നിയമവും ഒരുമിച്ച് വായിക്കുക

സോക്കറ്റ് പട്ടികയും nat നിയമങ്ങളും ഒരേ പാസിൽ അച്ചടിക്കുക, കാരണം ആർക്കും ഉടമസ്ഥതയില്ലാത്ത പോർട്ടിലേക്ക് ചൂണ്ടുന്ന നിയമം തെറ്റായ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന നിയമത്തിന് സമാനമായി കാണപ്പെടുന്നു. sudo ss -ltnp | grep redsocks ബൈൻഡ് വിലാസവും ഉടമ പ്രോസസ്സും കാണിക്കുന്നു. sudo iptables -t nat -S PREROUTING REDIRECT ലക്ഷ്യം കാണിക്കുന്നു, sudo iptables -t nat -L PREROUTING -v -n അതുമായി എന്തെങ്കിലും ഒത്തുപോയോ എന്ന് കാണിക്കുന്നു.

REDSOCKS എന്ന പേരിലുള്ള ഉപയോക്തൃ ശൃംഖലയിലേക്ക് ചാടുന്നത് ആ ശൃംഖല നിലവിലില്ലെങ്കിൽ, ഉദ്ദേശിച്ച ഒഴിവാക്കലുകളും REDIRECT പ്രവർത്തനവും വഹിക്കുന്നില്ലെങ്കിൽ ഒന്നും നേടുന്നില്ല. പേര് തന്നെ ജോലി ചെയ്യുമെന്ന് കരുതുന്നതിന് പകരം sudo iptables -t nat -S REDSOCKS ഉപയോഗിച്ച് അത് ചാടുന്ന ശൃംഖല വായിക്കുക.

പിന്നീട് രണ്ട് മൂല്യങ്ങളും താരതമ്യം ചെയ്യുക. നിയമം 12345 പോർട്ടിലെ ഗേറ്റ്വേ വിലാസത്തിലേക്ക് റീഡയറക്ട് ചെയ്യുകയും ശ്രോതാവ് 127.0.0.1:12345 റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്താൽ, പൊരുത്തക്കേട് കൂടുതൽ ഡയഗ്നോസ്റ്റിക്സ് ഇല്ലാതെ പരാജയം വിശദീകരിക്കുന്നു.

ഇടുങ്ങിയതായി ബന്ധിപ്പിക്കുക, പിന്നീട് എന്തിന് അതിൽ എത്താം എന്ന് പരിമിതപ്പെടുത്തുക

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

പൊതു ഇന്റർഫേസിൽ പോർട്ട് തുറക്കുന്നത് റീഡയറക്ട് ചെയ്ത VPN ട്രാഫിക്കിന് ഒരിക്കലും ആവശ്യമില്ല, കാരണം വീണ്ടും എഴുതിയതിന് ശേഷം കണക്ഷൻ ലോക്കലായി അവസാനിക്കുന്നു. ലോക്കൽ റീഡയറക്ട് പ്രവർത്തിക്കാൻ പ്രോക്സി ഇന്റർനെറ്റിലേക്ക് തുറക്കരുത്.

ക്ലയന്റിൽ നിന്നുള്ള പുതിയ കണക്ഷൻ കൊണ്ട് അത് തെളിയിക്കുക

ഗേറ്റ്വേയിലെ ഷെല്ലിൽ നിന്നല്ല, യഥാർത്ഥ VPN ക്ലയന്റിൽ നിന്ന് പുതിയ TCP കണക്ഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക. ക്ലയന്റിലെ curl -sS -o /dev/null -w '%{http_code}\n' http://example.com റീഡയറക്ട് ചെയ്ത പാത ആദ്യം മുതൽ അവസാനം വരെ പ്രവർത്തിപ്പിക്കുന്നു.

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

അവസാനമായി, ഈ പാത എന്ത് ഉൾക്കൊള്ളുന്നില്ല എന്ന് ഓർക്കുക. സാധാരണ redsocks TCP റീഡയറക്ട് UDP, QUIC അല്ലെങ്കിൽ DNS എന്നിവയെ SOCKS ട്രാഫിക്കാക്കി മാറ്റുന്നില്ല, സ്വകാര്യ ലക്ഷ്യങ്ങൾക്ക് സാധാരണയായി വ്യക്തമായ ഒഴിവാക്കലുകൾ വേണം. വിജയകരമായ ലോക്കൽ പരിശോധന ഒരിക്കലും പ്രശ്നമായിരുന്നില്ലാത്ത ലൂപ്പ്ബാക്ക് പാത മാത്രം തെളിയിക്കുന്നു.

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