3proxy સાથે SOCKS ક્લાયન્ટ્સને HTTP CONNECT પેરેન્ટ સાથે જોડો

એપ્લિકેશનને SOCKS જોઈએ છે. તમારી મંજૂર અપસ્ટ્રીમ સેવા HTTP CONNECT સ્વીકારે છે. એપ્લિકેશનના SOCKS ક્ષેત્રમાં HTTP એન્ડપોઇન્ટ મૂકવાથી પ્રોટોકોલ વચ્ચે અનુવાદ થતો નથી.

ગેટવે એપ્લિકેશન તરફથી SOCKS સ્વીકારી શકે, વિનંતી કરેલ ગંતવ્ય વાંચી શકે અને તે ગંતવ્ય માટે HTTP પેરેન્ટને CONNECT ટનલ માટે પૂછી શકે. પછી તે એપ્લિકેશનનો પ્રવાહ ટનલમાંથી પસાર કરે છે.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

દરેક ઇન્ટરફેસ સ્પષ્ટ કરો

આ ગોઠવણીને સમર્થન આપતા ગેટવે માટે તેનો પેરેન્ટ પ્રકાર મહત્વનો છે. 3proxy નું દસ્તાવેજીકરણ connect પેરેન્ટને સામાન્ય HTTP ફોરવર્ડિંગ પ્રોક્સી તરીકે વપરાતા પેરેન્ટથી અલગ પાડે છે.

હાલના 3proxy વપરાશકર્તા અને પ્રમાણીકરણ સેટઅપ સાથે, ફક્ત-સ્થાનિક રાઉટિંગ ટુકડો આ સ્વરૂપ લઈ શકે છે:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

આ ટુકડો ધારે છે કે ખાતું પહેલેથી વ્યાખ્યાયિત છે. તે HTTP પેરેન્ટ પોતે માંગતી કોઈ પણ ઓળખપત્રો ઉમેરતો નથી અને હાલની ઍક્સેસ નીતિ બદલતો નથી. પ્રમાણીકરણ વગરના જાહેર HTTP પેરેન્ટને મંજૂરી આપતા માર્ગ પર જાહેર ગંતવ્યો માટે, HTTP પ્રોક્સી યાદી યજમાન અને પોર્ટના ઉમેદવારો આપે છે. તે શાખા માટે પેરેન્ટ ઓળખપત્રો ગેરહાજર રાખો અને વાસ્તવિક લક્ષ્ય માટે પરવાનગીની પુષ્ટિ કરો; ગેટવેનું પોતાનું ખાતું સ્થાનિક જ રહે છે. parent નિયમ 3proxy ના દસ્તાવેજીકૃત રૂપરેખાંકન મોડેલ હેઠળ પહેલાના allow નિયમ સાથે સંકળાયેલો છે.

એપ્લિકેશન સ્થાનિક SOCKS એન્ડપોઇન્ટ વાપરે છે. ગેટવે પેરેન્ટ તરફ HTTP CONNECT વાપરે છે. વિનંતી કરેલ ગંતવ્ય યજમાન અને પોર્ટ મંજૂર છે કે નહીં તે હજુ પણ પેરેન્ટ જ નક્કી કરે છે.

અહીં ઉપયોગી વ્યાપ સામાન્ય TCP પ્રવાહ ટનલિંગ છે. સામેનો શ્રોતા SOCKS5 સ્વીકારે એટલે જ SOCKS5 UDP સંગઠન સમર્થિત બનતું નથી. HTTP CONNECT પેરેન્ટ જરૂરી UDP રિલે આપમેળે આપતું નથી.

HTTPS આ માર્ગમાં એન્ડ-ટુ-એન્ડ રહી શકે છે; પ્રોક્સી ઇન્ટરફેસ વચ્ચે અનુવાદ માટે ગંતવ્ય વેબસાઇટનું નકલ કરવાની જરૂર નથી. ગેટવે માટે પ્રમાણીકરણ, પેરેન્ટ માટે પ્રમાણીકરણ અને વેબસાઇટ પ્રમાણીકરણ અલગ ઓળખપત્રો અને વિનિમય જ રહે છે.