Windows portproxy ഉപയോഗിച്ച് നിശ്ചിത ലക്ഷ്യത്തിലേക്കുള്ള TCP റിലേ
portproxy നിയമം ഒരു ലിസണറെ നിശ്ചിത ലക്ഷ്യത്തിലേക്ക് അയയ്ക്കുന്നു. പ്രോക്സി അറിയുന്ന ക്ലയന്റുകൾ പ്രതീക്ഷിക്കുന്ന SOCKS അല്ലെങ്കിൽ HTTP CONNECT ചർച്ച അത് ചേർക്കുന്നില്ല.
Windows-ന്റെ portproxy നിയമം TCP ഒരു കോൺഫിഗർ ചെയ്ത ലക്ഷ്യത്തിലേക്ക് റിലേ ചെയ്യുന്നു. ബ്രൗസറിന്റെ HTTP പ്രോക്സി അഭ്യർത്ഥനയോ SOCKS ലക്ഷ്യ അഭ്യർത്ഥനയോ അത് ചർച്ച ചെയ്യുന്നില്ല.
| സേവനം | ലക്ഷ്യം ആരാണ് തിരഞ്ഞെടുക്കുന്നത്? |
|---|---|
| സ്ഥിര TCP റിലേ | ലിസണറുടെ ഫോർവേഡിംഗ് കോൺഫിഗറേഷൻ. |
| SOCKS5 പ്രോക്സി | ക്ലയന്റിന്റെ അഭ്യർത്ഥന, സെർവർ നയത്തിനുള്ളിൽ. |
| HTTP ഫോർവേഡ് പ്രോക്സി | HTTP പ്രോക്സി അഭ്യർത്ഥന, സാധാരണ HTTPS ടണലിംഗിനുള്ള CONNECT ഉൾപ്പെടെ. |
netsh interface portproxy show all ഉപയോഗിച്ച് നിലവിലുള്ള റിലേ പരിശോധിക്കുക. അതിന്റെ കോൺഫിഗർ ചെയ്ത backend നിങ്ങളുടെ ക്ലയന്റ് അയയ്ക്കുന്ന പ്രോട്ടോക്കോളുമായി താരതമ്യം ചെയ്യുക. netsh റഫറൻസ് ലിസണറുടെയും ലക്ഷ്യത്തിന്റെയും വിലാസങ്ങളും പോർട്ടുകളും വിവരിക്കുന്നു; TCP സ്വീകരിക്കുന്നത് HTTP അല്ലെങ്കിൽ SOCKS ഹാൻഡ്ഷേക്ക് സ്ഥാപിക്കുന്നില്ല.
സാധാരണ റിലേയിലേക്ക് അയയ്ക്കുന്ന SOCKS ചർച്ച ആ സ്ഥിര backend-ൽ എത്തുന്നു മാത്രം. SOCKS അല്ലാത്ത സേവനത്തെ അഭ്യർത്ഥന മനസ്സിലാക്കാനോ പുതിയ ലക്ഷ്യം തിരഞ്ഞെടുക്കാനോ അതിന് കഴിയില്ല.
യഥാർത്ഥ പ്രോക്സിക്ക് മുന്നിലുള്ള റിലേ വ്യത്യസ്തമാണ്. അപ്സ്ട്രീം പ്രോക്സി ഇപ്പോഴും ലക്ഷ്യങ്ങളും പ്രാമാണീകരണവും ചർച്ച ചെയ്യുന്നു; റിലേ കണക്ഷൻ അതിലേക്ക് കൊണ്ടുപോകുന്നു. നെറ്റ്വർക്കിൽ തുറന്ന റിലേ ആ backend-ലേക്കുള്ള പ്രവേശനം വിപുലീകരിക്കാം, അതിനാൽ ലിസണറുടെ പ്രവേശന പരിധി ബോധപൂർവം നിലനിർത്തുക.
ആവശ്യം പൊതുവായ HTTP അല്ലെങ്കിൽ SOCKS എക്സിറ്റ് ആണെങ്കിൽ പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്ന സേവനം തിരഞ്ഞെടുക്കുക. ഫോർവേഡ് ചെയ്ത പോർട്ട് ആ പാതയുടെ ഒരു ഭാഗം മാത്രമാണ്.