Squid દ્વારા Proxychains: પોર્ટ 80 પર CONNECT પ્રતિબંધો
જ્યારે લક્ષ્ય પોર્ટ 80 નકારવામાં આવે ત્યારે સામાન્ય HTTP પ્રોક્સી વિનંતીઓને proxychains HTTP CONNECT ટનલથી અલગ પાડો.
બ્રાઉઝર Squid દ્વારા HTTP પૃષ્ઠ લોડ કરે છે. એ જ લક્ષ્ય proxychains હેઠળ નિષ્ફળ જાય છે. એનો અર્થ એ નથી કે બેમાંથી કોઈ એક પ્રોગ્રામે ખોટું પ્રોક્સી IP પસંદ કર્યું છે.
સામાન્ય HTTP-સમજતું ક્લાયન્ટ વેબ વિનંતીને HTTP પ્રોક્સી સ્વરૂપમાં ફોરવર્ડ પ્રોક્સીને મોકલી શકે છે. જ્યારે સામાન્ય સોકેટ આવરણને એપ્લિકેશન જે કનેક્શન ખોલવા માંગતી હતી તેના માટે બાઇટ ટનલની જરૂર પડે છે. પોતાની ચેઇનમાંના HTTP પ્રોક્સી માટે proxychains CONNECT વાપરે છે.
એટલે કે પોર્ટ 80 પરની સાદી ટેક્સ્ટ વેબસાઇટ પોર્ટ 80 માટે CONNECT વિનંતી પેદા કરી શકે છે. ફક્ત મંજૂર TLS પોર્ટ સૂચિ તરફ CONNECT ની પરવાનગી આપતી Squid નીતિ તે ટનલને નકારી શકે છે, જ્યારે પોર્ટ 80 પરની સામાન્ય HTTP વિનંતીઓને પરવાનગી હોય.
વિનંતીઓની તુલના કરો, ફક્ત હોસ્ટનામોની નહીં
proxychains-ng નું દસ્તાવેજીકરણ તેનું HTTP CONNECT સમર્થન વર્ણવે છે. Squid ના ઍક્સેસ નિયમો પદ્ધતિ અને લક્ષ્ય પોર્ટને અલગ કરી શકે છે. આ એ જ વેબસાઇટ તરફની અલગ વિનંતી માર્ગો છે.
બદલતા પહેલાં નકાર અને ઇચ્છિત નીતિ વાંચો. CONNECT ઍક્સેસને દરેક પોર્ટ સુધી વિસ્તારવો એ નોંધપાત્ર ફેરફાર છે; આવરણની અસંગતિ માટે એ ડિફૉલ્ટ પ્રતિભાવ ન હોવો જોઈએ.
જો એપ્લિકેશનમાં મૂળ HTTP પ્રોક્સી સમર્થન હોય, તો તેનો ઉપયોગ સાદા ટેક્સ્ટ HTTP માટે બિનજરૂરી સામાન્ય ટનલ ટાળી શકે છે. જો ખરેખર કાચી TCP ટનલની જરૂર હોય, તો તે પૂરી પાડતું મંજૂર પ્રોક્સી પ્રોટોકોલ અને પોર્ટ નીતિ પસંદ કરો.
સફળ બ્રાઉઝર વિનંતી પ્રોક્સીની પહોંચ અને એક સમર્થિત વિનંતી પદ્ધતિ વિશે ઉપયોગી પુરાવો છે. પણ એ સાબિત કરતી નથી કે દરેક ટનલ પદ્ધતિ, લક્ષ્ય પોર્ટ કે એપ્લિકેશન પ્રોટોકોલ તે પ્રોક્સી દ્વારા પરવાનગી પામેલા છે.