پورت ارسال‌شده از طریق SSH همیشه پروکسی SOCKS نیست
پیش از پیکربندی یک برنامه، ارسال محلی ثابت SSH را از شنونده پویای SOCKS تشخیص دهید.
یک تونل SSH می‌سازید، 127.0.0.1 و پورت آن را در تنظیمات پروکسی مرورگر می‌گذارید و هیچ چیز بارگذاری نمی‌شود. ممکن است شنونده کاملاً درست کار کند. شاید فقط منتظر نوع اشتباهی از ترافیک است.
| ارسال | برنامه محلی چه می‌فرستد | انتخاب مقصد |
|---|---|---|
-L | پروتکل معمول سرویس مقصد | در فرمان SSH ثابت شده است |
-D | مذاکره SOCKS و سپس ترافیک برنامه | توسط کارخواه SOCKS درخواست می‌شود |
برای یک وب‌سرور واحد، این یک ارسال ثابت است:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]به http://127.0.0.1:9080/ به‌عنوان یک وب‌سایت بروید. پورت 9080 را SOCKS برچسب نزنید: بایت‌ها را به همان یک وب‌سروری می‌فرستد که در فرمان نام برده شده است. باز کردن یک سایت با نام میزبان دیگر نیز می‌تواند بر میزبانی مجازی، تغییرمسیرها یا کوکی‌های آن اثر بگذارد.
برای یک شنونده SOCKS شکل تغییر می‌کند:
ssh -N -D 127.0.0.1:1080 [email protected]برنامه را طوری پیکربندی کنید که از SOCKS در 127.0.0.1:1080 استفاده کند. وارد کردن مستقیم آن نشانی در نوار نشانی مرورگر یک درخواست وب را به شنونده SOCKS می‌فرستد، که ناسازگاری دیگری در پروتکل است.
راهنمای OpenSSH هر دو شکل را مستند می‌کند. یک استثنای سودمند وجود دارد: ارسال یک پروکسی HTTP موجود با -L پورت محلی‌ای می‌سازد که پروتکل پروکسی HTTP را می‌فهمد، زیرا مقصد ثابت آن خودش یک پروکسی HTTP است. این سرویس در انتهای دور است که تعیین می‌کند چه چیزی به یک ارسال ثابت تعلق دارد. ارسال یک پروکسی موجود از طریق SSH پروتکل و حساب آن پروکسی را حفظ می‌کند.