ارسال دینامیک SSH به عنوان پروکسی SOCKS روی VPN شما
برنامه‌ای که فقط SOCKS می‌فهمد در یک VPN ساده هیچ نقطه پروکسی ندارد. دو پرش، یک شنونده روی لوکال‌بک و یک جست‌وجوی نام که خود سرور SSH باید انجام دهد.
برنامه‌ای که فقط SOCKS می‌فهمد، در یک VPN ساده چیزی برای گفت‌وگو ندارد، چون تونل بسته‌ها را حمل می‌کند و برنامه یک نقطه پروکسی می‌خواهد. OpenSSH می‌تواند آن نقطه را فراهم کند وقتی صاحب دسترسی اجازه دهد، چون ارسال دینامیک یک نشست SSH را به پروکسی محلی تبدیل می‌کند. بعد دو پرش هست که باید جدا نگه داشته شوند: تونلی که به میزبان SSH می‌رسد، و اتصالی که آن میزبان پس از آن باز می‌کند. جدا کردن این دو توضیح می‌دهد که چرا این چیدمان کار می‌کند و چه کاری را هرگز انجام نخواهد داد.
شنونده SSH چه می‌شود و چه نمی‌شود
ارسال دینامیک باعث می‌شود کلاینت SSH به‌صورت محلی گوش دهد و با هر چیزی که وصل می‌شود SOCKS4 یا SOCKS5 صحبت کند. هر درخواست یک مقصد را نام می‌برد و سرور SSH اتصال بعدی را باز می‌کند، به همین دلیل جست‌وجوی مقصد می‌تواند در سمت دور انجام شود. این ارسال TCP در سطح برنامه است، نه یک VPN برای کل دستگاه. هیچ انجمن UDP، هیچ ICMP و هیچ چیزی برای برنامه‌هایی که تنظیمات پروکسی را کاملاً نادیده می‌گیرند حمل نمی‌کند. پرش از سرور SSH به برنامه هم داخل تونل شما نیست، و این وقتی مهم است که مقصد ترافیک را فقط از شبکه‌های شناخته‌شده می‌پذیرد.
پیش‌نیازها واقعی‌اند: مسیری به میزبان SSH، حسابی مجاز، کلید میزبان سرور تأییدشده و اجازه ارسال. هیچ‌یک از آن‌ها را پروکسی نمی‌سازد، و مورد آخر معمولاً اولین چیزی است که غایب است. پیش از عیب‌یابی هر چیز دیگری هر چهار مورد را تأیید کنید، چون از دید کلاینت شکست یکسان به نظر می‌رسد، هر کدام که غایب باشد.
آن را روی لوکال‌بک با پورت صریح راه بیندازید
یک پورت محلی بی‌استفاده انتخاب کنید و آن را صریحاً به لوکال‌بک ببندید، به‌جای اینکه آدرس را خالی بگذارید. سه گزینه زیر هر یک به یک دلیل وجود دارند.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N دستور راه دور را رد می‌کند و -T ترمینال شبه را رد می‌کند، پس نشست فقط برای ارسال وجود دارد. ExitOnForwardFailure باعث می‌شود کلاینت زمانی که شنونده ساخته نمی‌شود خارج شود، به‌جای اجرا بدون ارسالی که خواسته‌اید. ControlPath=none نشست را بیرون از یک اتصال چندگانه موجود نگه می‌دارد که ممکن است ارسال‌های خودش را اضافه کند. لوکال‌بک شنونده را بیرون از LAN نگه می‌دارد، اما روی ماشین مشترک مرز مجوز نیست، چون پردازش‌های محلی دیگر هم می‌توانند به آن برسند. مرجع کلاینت OpenSSH همه این گزینه‌ها را مستند می‌کند، و هشدار لوکال‌بک از آنچه یک سوکت شنونده است نتیجه می‌شود.
نام‌ها را از داخل پروکسی بفرستید، نه از کنارش
کلاینت SOCKS5 می‌تواند مقصد را خودش حل کند یا از پروکسی بخواهد این کار را بکند، و همین انتخاب تعیین می‌کند کدام تحلیل‌گر پاسخ دهد. با socks5h، curl نام میزبان را از داخل پروکسی می‌فرستد، پس جست‌وجو روی سرور SSH انجام می‌شود. با socks5 ساده، لپ‌تاپ اول حل می‌کند و فقط اتصال سفر می‌کند، که وقتی نام داخلی است بی‌صدا هدف را از بین می‌برد. درخواست زیر فهرست بدون‌پروکسی را هم پاک می‌کند، تا مقدار به‌ارث‌رسیده NO_PROXY نتواند آن را از کنار پروکسی ببرد.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthاعتبارسنجی گواهی و ورود خود برنامه هنوز اعمال می‌شوند، چون پروکسی هیچ‌یک را جایگزین نمی‌کند. دو جست‌وجو باقی می‌ماند: لپ‌تاپ باید از مسیر مجاز VPN و DNS به میزبان SSH برسد، و سرور SSH باید نام برنامه را خودش حل کند. دومی را می‌توان جداگانه آزمود پیش از آنکه هیچ ترافیکی از پروکسی بگذرد.
ssh [email protected] getent hosts app.corp.exampleیک مقصد مجاز را اثبات کنید، سپس نشست را ببندید
مقصدی را که سیاست اجازه می‌دهد و مقصدی را که باید رد کند بیازمایید، چون ارسال کارکننده فقط ثابت می‌کند شنونده کار می‌کند و نه چیزی بیشتر. برنامه نشانی مبدأ را که سرور SSH انتخاب می‌کند می‌بیند، و این نشانی تونل لپ‌تاپ شما نیست. جایی که سمت دور اتصال‌ها را بر اساس مبدأ ثبت می‌کند، همین تفاوت اولین چیزی است که هنگام رد شدن یک درخواست باید بررسی شود.
نشست را از طریق پردازشی که مالک آن است متوقف کنید، نه با کشتن یک پوسته بی‌ربط. سپس تأیید کنید که شنونده رفته است، چون پورتی که هنوز پاسخ می‌دهد نشستی است که واقعاً نبسته‌اید. فقط تنظیم پروکسی را که این تمرین معرفی کرد بردارید، و بقیه پیکربندی برنامه را رها کنید. پایانه‌ای بدون نظارت که یک قاعده ارسال را نگه می‌دارد سرویس نیست، و پروکسی دائمی به چرخه عمر تأییدشده نیاز دارد، نه به پنجره‌ای فراموش‌شده.
ss -ltn | grep 1080شکست‌هایی که این چیدمان نمی‌تواند برطرف کند
برخی نشانه‌ها مستقیماً به محدودیت‌های بالا اشاره می‌کنند، و شناخت زودهنگام آن‌ها یک بعدازظهر عیب‌یابی پروکسی را صرفه‌جویی می‌کند. جدول آنچه می‌بینید را با آنچه معمولاً معنا می‌دهد تطبیق می‌دهد. هر چیزی در ستون آخر یک پرسش طراحی است، نه خطای پیکربندی.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
سه ردیف اول همان‌هایی هستند که مردم اشتباه تشخیص می‌دهند، چون هر یک تلاش برای اتصال تولید می‌کند نه خطایی درباره خود پروکسی. نامی که روی لپ‌تاپ حل می‌شود هیچ چیزی درباره تحلیل‌گر سرور نمی‌گوید، و شکست به‌جای آن به‌صورت مشکل گواهی یا پایان مهلت خوانده می‌شود. برنامه‌های فقط UDP بیرون از طراحی می‌ایستند، نه خراب درون آن، و هیچ گزینه اضافی ssh این را تغییر نمی‌دهد. ردیف مرورگر یادآور معمول این است که تنظیمات پروکسی برای هر برنامه جداست. ردیف آخر دلیل وجود بررسی بستن است: پورتی که هنوز گوش می‌دهد یعنی اکنون چیز دیگری مالک آن است.