Windows portproxy સાથે નિશ્ચિત ગંતવ્ય પર TCP રિલે
portproxy નિયમ લિસનરને નિશ્ચિત ગંતવ્ય પર મોકલે છે. તે પ્રોક્સી-જાગરૂક ક્લાયન્ટ જે SOCKS કે HTTP CONNECT વાટાઘાટની અપેક્ષા રાખે છે તે ઉમેરતું નથી.
Windows નો portproxy નિયમ TCP ને એક ગોઠવેલા ગંતવ્ય પર રિલે કરે છે. તે બ્રાઉઝરની HTTP પ્રોક્સી વિનંતી કે SOCKS ગંતવ્ય વિનંતી પર વાટાઘાટ કરતું નથી.
| સેવા | ગંતવ્ય કોણ પસંદ કરે છે? |
|---|---|
| નિશ્ચિત TCP રિલે | લિસનરની ફોરવર્ડિંગ ગોઠવણી. |
| SOCKS5 પ્રોક્સી | ક્લાયન્ટની વિનંતી, સર્વર નીતિની અંદર. |
| HTTP ફોરવર્ડ પ્રોક્સી | HTTP પ્રોક્સી વિનંતી, સામાન્ય HTTPS ટનલિંગ માટે CONNECT સહિત. |
netsh interface portproxy show all સાથે હાલનું રિલે તપાસો. તેનું ગોઠવેલું બેકએન્ડ તમારા ક્લાયન્ટ મોકલે છે તે પ્રોટોકોલ સાથે સરખાવો. netsh સંદર્ભ લિસનર અને ગંતવ્યના સરનામાં/પોર્ટ વર્ણવે છે; TCP સ્વીકારવું HTTP કે SOCKS હેન્ડશેક સ્થાપિત કરતું નથી.
સામાન્ય રિલેને મોકલેલી SOCKS વાટાઘાટ ફક્ત તે નિશ્ચિત બેકએન્ડ સુધી પહોંચે છે. તે બિન-SOCKS સેવાને વિનંતી સમજવા કે નવું લક્ષ્ય પસંદ કરવા મજબૂર કરી શકતી નથી.
સાચા પ્રોક્સીની સામેનું રિલે અલગ છે. અપસ્ટ્રીમ પ્રોક્સી હજી પણ ગંતવ્યો અને પ્રમાણીકરણની વાટાઘાટ કરે છે; રિલે તેના સુધી કનેક્શન લઈ જાય છે. નેટવર્ક પર ખુલ્લું રિલે તે બેકએન્ડ સુધીની પહોંચ વધારી શકે છે, તેથી લિસનરની પ્રવેશ સીમા ઇરાદાપૂર્વક રાખો.
જ્યારે જરૂરિયાત સામાન્ય HTTP કે SOCKS એક્ઝિટ હોય ત્યારે પ્રોટોકોલ-સક્ષમ સેવા પસંદ કરો. ફોરવર્ડ કરેલો પોર્ટ તે માર્ગનો ફક્ત એક ભાગ છે.