به یک Pi راه‌دور از طریق کلاینت SSH خود یک پروکسی SOCKS بدهید

شما فرض می‌کنید که پروکسی SOCKS باید همان‌جا اجرا شود که دسترسی شبکه از قبل وجود دارد. OpenSSH می‌تواند شنونده را کاملاً جای دیگری قرار دهد. یک ارسال دینامیک راه‌دور پورت SOCKS را روی یک میزبان راه‌دور باز می‌کند و هر اتصال را از کلاینت SSH محلی شما آغاز می‌کند که مسیر VPN تأییدشده لپ‌تاپ شما را حمل می‌کند. Pi یک پروکسی محدود می‌گیرد؛ این پروکسی تونل یا اختیارات شما را به ارث نمی‌برد.

شنونده و سمت آغاز اتصال می‌توانند متفاوت باشند

یک ssh -D 1080 معمولی شنونده را روی ماشین خودتان اجرا می‌کند و اتصال‌ها را از همان‌جا می‌فرستد. ارسال دینامیک راه‌دور این را برعکس می‌کند: شنونده روی میزبان راه‌دور ظاهر می‌شود و هر اتصالی که می‌پذیرد از سمت محلی باز می‌شود. راهنمای کلاینت OpenSSH گزینه -R را بدون مقصد ثابت دقیقاً همین ترتیب SOCKS4/5 مستند می‌کند.

یک دستور پشتیبانی‌شده از لپ‌تاپ چنین است، با فرض اینکه حساب، میزبان‌ها و پورت جای‌نگهدار هستند:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

سه جزئیات در آنجا کار مفیدی انجام می‌دهند. -S none نشست را از یک کنترل‌مستر مشترک دور نگه می‌دارد، ExitOnForwardFailure به‌جای باقی گذاشتن یک نشست نیمه‌باز سریع شکست می‌خورد، و PermitRemoteOpen محدود می‌کند که شنونده راه‌دور به چه چیزی برسد. از یک حساب مجاز Pi استفاده کنید و پیش از افزودن هر یک از این‌ها کلید میزبان را بررسی کنید.

شنونده راه‌دور در واقع چه چیزی را آشکار می‌کند

پیش از تکیه بر شنونده، سیاست ارسال سرور را بررسی کنید. با GatewayPorts no ارسال راه‌دور به loopback مقید می‌ماند و این همان میزان در معرض بودنی است که می‌خواهید. سروری که برای تحمیل ارسال عمومی پیکربندی شده باشد همان پورت را روی همه رابط‌ها منتشر می‌کند و این یک پروکسی شخصی را به چیزی تبدیل می‌کند که شبکه محلی به آن دسترسی دارد.

loopback هم مرز میان کاربران نیست. فرایند دیگری روی Pi اگر پورت را بداند می‌تواند به 127.0.0.1:1080 وصل شود، پس حساب‌های محلی Pi و هر چیزی که روی آن اجرا می‌شود بخشی از طراحی دسترسی شما هستند. این دلیلی برای باریک نگه داشتن فهرست مقصدها است، نه دلیلی برای نادیده گرفتن بررسی سیاست.

مقصد مجاز را مخصوص همان برنامه‌ای نگه دارید که می‌خواهید به آن برسید. جایگزین کردن آن با ارسال بی‌محدود برای کار کردن یک برنامه بی‌ربط، مسیر را بسیار فراتر از مشکلی که با آن شروع کردید گسترش می‌دهد. فهرست مقصد همچنین ثبت می‌کند که نشست برای چه بود، و این به کسی که بعداً آن را حسابرسی می‌کند کمک می‌کند. آن را کنار حسابی که استفاده کردید بنویسید.

یک برنامه را از پروکسی عبور دهید

کلاینتی روی Pi که پروکسی را می‌فهمد سپس می‌تواند درخواست را بفرستد. پیشوند socks5h نام مقصد را به پروکسی می‌سپارد، پس جست‌وجو و اتصال هر دو در سمت لپ‌تاپ رخ می‌دهند، و با مقصد نام‌دار در PermitRemoteOpen مطابقت دارد:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

اعتبارسنجی معمول گواهی و احراز هویت خود برنامه را حفظ کنید. پروکسی جای ایجاد اتصال TCP را تغییر می‌دهد؛ نه یک سرویس بدون احراز هویت را امن می‌کند و نه یک نقطه پایانی خودامضا را به یک نقطه مورد اعتماد تبدیل می‌کند.

لپ‌تاپ همچنان به مسیر خود و دسترسی به resolver نیاز دارد، هم به سرور SSH و هم به برنامه. ترافیک کلاینت SSH آن باید توسط سیاست VPN تأییدشده انتخاب شود، و یک استثنای split-tunnel می‌تواند آن ترافیک را از مسیری جز مسیری که آزمایش کردید بفرستد.

مسیر را اثبات کنید و آن را ببندید

تأیید کنید که شنونده همان‌جایی است که انتظار دارید و فقط مقصد مورد نظر پاسخ می‌دهد:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure می‌تواند اثبات کند که ارسال برقرار شده است، و باز هم نمی‌تواند گواهی کند که ورود به برنامه در پایین‌دست موفق است. خود برنامه را آزمایش کنید، نه فقط پورت را. شنونده‌ای که می‌پذیرد و بعد هر درخواست را شکست می‌دهد معمولاً یعنی نام مقصد یا مسیر لپ‌تاپ اشتباه است، نه اینکه تونل شکست خورده باشد.

این ترتیب فقط TCP را حمل می‌کند. UDP، ICMP و برنامه‌هایی که تنظیمات پروکسی را نادیده می‌گیرند بیرون از آن می‌مانند، و ارسال همان لحظه‌ای که نشست SSH تمام شود پایان می‌یابد. وقتی کارتان تمام شد آن نشست را متوقف کنید و تنظیم پروکسی را که به برنامه افزوده بودید بردارید.

برای دسترسی دائمی، به‌جای آن از ثبت‌نام پشتیبانی‌شده مالک شبکه یا یک دروازه مدیریت‌شده استفاده کنید. پروکسی معکوس ابزار نادرستی برای دور زدن محدودیت‌های دستگاه یا منابع VPN است؛ اگر داخل این محدودیت‌ها به کار رود، فقط یک مسیر مجاز برنامه با محدودیت‌های صریح است.