socat SOCKS બ્રિજ: વેબસાઇટનું TLS હોસ્ટનામ જાળવો

એપ્લિકેશનમાં SOCKS વિકલ્પ નથી, પણ તે પસંદ કરેલા TCP સરનામા સાથે જોડાઈ શકે છે. સ્થિર-લક્ષ્ય એડેપ્ટર એક ગંતવ્ય માટે SOCKS વાતચીત પૂરી પાડી શકે છે. તેણે બીજું સામાન્ય ફોરવર્ડ પ્રોક્સી બનવાની જરૂર નથી.

SOCKS4A પૂરું પાડતા socat બિલ્ડ માટે એક ઉદાહરણ રચના આ છે:

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKS અંતિમ બિંદુ સ્થાનિક પોર્ટ 1080 છે. એડેપ્ટર સ્થાનિક પોર્ટ 9443 પર સાંભળે છે અને તે અંતિમ બિંદુને service.example.net:443 માટે પૂછે છે. આ ઉદાહરણ મૂલ્યો છે, સંપૂર્ણ સેવા તૈનાતી નથી.

એડેપ્ટરનું એક સ્થિર લક્ષ્ય છે

દરેક સ્વીકૃત TCP જોડાણ એ જ સેવા માગે છે. 9443 સાથે જોડાતી એપ્લિકેશન તેના સામાન્ય પ્રોટોકોલ બાઇટ્સ પૂરા પાડે છે; socat SOCKS4A વાટાઘાટ પૂરી પાડે છે. 9443 પર નવી HTTP CONNECT વિનંતી મોકલવાથી બીજું ગંતવ્ય પસંદ ન થાય—તે તે બાઇટ્સને સ્થિર સેવા તરફ મોકલશે.

SOCKS4A દૂરસ્થ ઉકેલ માટે SOCKS અંતિમ બિંદુને હોસ્ટનામ આપે છે. આ ક્લાયન્ટ-પસંદ કરેલા સરનામા વાપરતા SOCKS4 સ્વરૂપથી અલગ છે. પસંદ કરેલો અપસ્ટ્રીમ—SOCKS4 પ્રોક્સી યાદીમાંથી જાહેર ઉમેદવાર સહિત—SOCKS4A હોસ્ટનામ હેન્ડલિંગ અને જરૂરી પ્રમાણીકરણને સમર્થન આપવું જોઈએ; આ ઉદાહરણ SOCKS5 પાસવર્ડ-લોગિન રેસીપી નથી.

સ્થાનિક રીતે જોડાઓ, ખરી સેવા ઓળખો

HTTPS URL ને https://127.0.0.1:9443/ માં બદલવાથી ક્લાયન્ટ TLS અને HTTP માટે વાપરી શકે તે હોસ્ટનામ બદલાય છે. service.example.net માટેનું પ્રમાણપત્ર loopback માટે માન્ય પ્રમાણપત્ર નહીં બને.

જ્યાં ક્લાયન્ટ અલગ જોડાણ રૂટિંગને સમર્થન આપે છે, ત્યાં મૂળ URL ઓળખ રાખો. Curl તે તફાવત દર્શાવી શકે છે:

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

સોકેટ સ્થાનિક એડેપ્ટર તરફ જાય છે જ્યારે TLS ચકાસણી અને HTTP ગંતવ્ય service.example.net જ રહે છે. બીજી એપ્લિકેશનોને તેમનું પોતાનું સમાન સમર્થિત નિયંત્રણ જોઈએ; દરેક ક્લાયન્ટ તે આપતું નથી.

loopback બંધન નેટવર્ક એક્સપોઝર મર્યાદિત કરે છે, પણ બીજી લાયક સ્થાનિક પ્રક્રિયાઓ હજી પણ તેને પહોંચી શકે છે. સેવાનું આયુષ્ય અને વપરાશકર્તાઓ યોગ્ય રાખો. loopback URL ને કારણે થતી ઓળખ ભૂલ દબાવવાને બદલે TLS ચકાસણી રાખો.