Privoxy. HTTP վստահելի սերվերի հաճախորդը միացնել SOCKS թունելին

SSH դինամիկ թունելը, ներառյալ PuTTY-ի դինամիկ փոխանցումը, տալիս է SOCKS ինտերֆեյս: Միայն HTTP վստահելի սերվեր ընդունող հավելվածը չի կարող օգտագործել այդ պորտը՝ պարզապես այն HTTP անվանելով:

Նրանց միջև կարող է տեղադրվել տեղական արձանագրության կամուրջ: Հավելվածը HTTP վստահելի սերվերի հարցումները ուղարկում է կամրջին, իսկ կամուրջը բացում է նպատակակետի միացումները SOCKS ծառայության միջոցով:

Privoxy-ն այս կարգը փաստաթղթավորում է իր փոխանցման կանոններով: Գոյություն ունեցող տեղական SOCKS5 թունելի համար կոնֆիգուրացիայի հատվածը հետևյալն է.

forward-socks5 / 127.0.0.1:1080 .

Հավելվածը միանում է Privoxy-ի HTTP լսողին, ոչ թե 1080 պորտին: Պահեք այդ լսողը տեղական՝ նախատեսված մուտքի քաղաքականության համաձայն: Կանոնի վերջին կետն ունի փաստաթղթավորված իմաստ. այն բացակայող ինտերնետ հոսթանվան տեղապահ չէ:

Սա արձանագրության թարգմանություն է

Privoxy-ի փոխանցման փաստաթղթերը բացատրում են SOCKS փոխանցման շարահյուսությունը և հոսթանունների հետ աշխատանքը: Սովորական TCP պորտի փոխանցումը նույն թարգմանությունը չի կատարում. այն հաճախորդի HTTP բայթերը անփոփոխ հասցնում է SOCKS լսողին, որը դեռ սպասում է SOCKS պայմանավորվածության:

Կամուրջը նաև դառնում է այն կոնֆիգուրացիայի մասը, որը պետք է հասկանալ: Privoxy-ն կարող է ունենալ սեփական բովանդակության զտման և մուտքի կարգավորումներ: Այն ավելացնելը նույնը չէ, ինչ սկզբնական հավելվածը բնիկ կերպով SOCKS աջակցի:

HTTPS կայքերի համար հավելվածը սովորաբար HTTP կամրջից խնդրում է CONNECT, և կամուրջը նպատակակետի միացումը ստանում է SOCKS-ի միջոցով: Կայքի սովորական TLS-ը մնում է հավելված-կայք հարաբերություն. կամուրջը պետք չէ ներկայանալ կայքի փոխարեն այս ուղին տալու համար:

Եթե հավելվածը կարող է ուղղակիորեն օգտագործել SOCKS, լրացուցիչ բաղադրիչը կարող է ավելորդ լինել: Օգտագործեք կամուրջը իրական արձանագրային անհամապատասխանություն լուծելու համար՝ լսողին և վերին հոսքը հստակ տարբերակելով: