تونل پویای SSH، از جمله فوروارد پویای PuTTY، رابط SOCKS ارائه می‌دهد. برنامه‌ای که فقط پراکسی HTTP را می‌پذیرد نمی‌تواند آن پورت را فقط با نامیدن آن HTTP استفاده کند.

یک پل پروتکل محلی می‌تواند میان آن دو بنشیند. برنامه درخواست‌های پراکسی HTTP را به پل می‌فرستد و پل اتصال‌های مقصد را از طریق سرویس SOCKS باز می‌کند.

Privoxy این ترتیب را از طریق قواعد فوروارد خود مستند می‌کند. برای یک تونل SOCKS5 محلی موجود، یک قطعه پیکربندی چنین است:

forward-socks5 / 127.0.0.1:1080 .

برنامه به شنوندهٔ HTTP مربوط به Privoxy وصل می‌شود، نه به پورت 1080. آن شنونده را بر اساس سیاست دسترسی موردنظر محلی نگه دارید. نقطهٔ پایانی در قاعده معنای مستندی دارد؛ جایگزینی برای نام میزبان اینترنتیِ گمشده نیست.

این ترجمهٔ پروتکل است

مستندات فوروارد Privoxy نحو فوروارد SOCKS و نحوهٔ برخورد با نام میزبان را توضیح می‌دهد. فوروارد سادهٔ پورت TCP همان ترجمه را انجام نمی‌دهد: بایت‌های HTTP کلاینت را بدون تغییر به شنوندهٔ SOCKS می‌رساند که هنوز انتظار مذاکرهٔ SOCKS دارد.

پل همچنین بخشی از پیکربندی می‌شود که باید درک کنید. Privoxy می‌تواند تنظیمات فیلتر محتوا و دسترسی خودش را داشته باشد. افزودن آن با نیتیو کردن پشتیبانی برنامهٔ اصلی از SOCKS یکی نیست.

برای وب‌سایت‌های HTTPS، برنامه معمولاً از پل HTTP درخواست CONNECT می‌کند و پل اتصال مقصد را از طریق SOCKS می‌گیرد. TLS معمول وب‌سایت همچنان رابطه‌ای میان برنامه و وب‌سایت می‌ماند؛ پل برای ارائهٔ این مسیر لازم نیست خود را جای وب‌سایت جا بزند.

اگر برنامه بتواند مستقیماً از SOCKS استفاده کند، مؤلفهٔ اضافی ممکن است لازم نباشد. از پل برای حل یک ناسازگاری واقعی پروتکل استفاده کنید، با تفکیک روشن شنونده و بالادست.

مقالات مرتبط