پل زدن کلاینتهای 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 طبق مدل پیکربندی مستند 3proxy با قاعده allow پیشین مرتبط است.
برنامه از نقطه پایانی SOCKS محلی استفاده میکند. دروازه از HTTP CONNECT به سمت والد استفاده میکند. والد همچنان تصمیم میگیرد که آیا میزبان و پورت مقصد درخواستی مجاز هستند.
دامنه مفید در اینجا تونلسازی جریان TCP معمولی است. انجمن UDP در SOCKS5 تنها به این دلیل که شنونده جلویی SOCKS5 را میپذیرد پشتیبانی نمیشود. والد HTTP CONNECT بهطور خودکار رله UDP لازم را فراهم نمیکند.
HTTPS میتواند در این مسیر سرتاسری بماند؛ ترجمه بین رابطهای پروکسی نیازی به جعل هویت وبسایت مقصد ندارد. احراز هویت به دروازه، احراز هویت به والد و احراز هویت وبسایت اعتبار و تبادلهای متفاوتی میمانند.