Свързване на SOCKS клиенти с HTTP CONNECT родител чрез 3proxy

Обяснява шлюз от страната на SOCKS, поддържан от HTTP CONNECT родител, и изискванията за протокол и удостоверяване на всяка стъпка.

Приложението изисква SOCKS. Одобрената ви услуга нагоре приема HTTP CONNECT. Поставянето на HTTP крайната точка в полето SOCKS на приложението не превежда между протоколите.

Шлюзът може да приема 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 се свързва с предходното правило allow съгласно документирания модел на конфигурация на 3proxy.

Приложението използва локалната SOCKS крайна точка. Шлюзът използва HTTP CONNECT към родителя. Родителят все още решава дали заявеният хост и порт на дестинацията са разрешени.

Полезният обхват тук е тунелирането на обикновен TCP поток. UDP асоциация на SOCKS5 не става поддържана само защото фронталният слушател приема SOCKS5. HTTP CONNECT родител не предоставя автоматично необходимия UDP релей.

HTTPS може да остане от край до край в този път; преводът между прокси интерфейси не изисква да се представяме за целевия уебсайт. Удостоверяването към шлюза, удостоверяването към родителя и удостоверяването към уебсайта остават различни идентификационни данни и обмени.

Подобни статии