هدایت محلی SSH به یک پراکسی HTTP موجود: دو نشانی loopback

پراکسی تأییدشدهٔ شما روی یک میزبان پرش اجرا می‌شود که فقط روی loopback گوش می‌دهد، بنابراین هیچ‌چیز بیرون از آن ماشین نمی‌تواند به آن برسد. شما به یک VPN یا یک پراکسی تازه نیاز ندارید؛ به یک پورت از آن ماشین نیاز دارید که به یکی از پورت‌های خودتان منتقل شود. یک هدایت محلی دقیقاً همین کار را می‌کند و تنها یک فرمان و یک تنظیم برنامه می‌خواهد. سردرگمی معمولاً از این می‌آید که کدام نشانی loopback به کدام ماشین تعلق دارد.

تصمیم بگیرید که آیا پراکسی ثابتی از پیش وجود دارد

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

اگر این را اول تأیید کنید، از عیب‌یابی تونلی که هرگز به چیزی وصل نشده بود در امان می‌مانید.

هدایت را بسازید و فرمان را بخوانید

شکلی که می‌خواهید یک پورت loopback روی لپ‌تاپ شما مقید می‌کند و آن را از سمت سرور به نشانی پراکسی، همان‌گونه که سرور می‌بیند، وصل می‌کند.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N یک فرمان دور را سرکوب می‌کند و -T تخصیص termios را سرکوب می‌کند، چون شما تونل می‌خواهید و نه پوسته. نشانی loopback نخست جایی است که لپ‌تاپ گوش می‌دهد؛ دومی توسط سرور SSH تحلیل می‌شود، بنابراین 127.0.0.1 در آنجا یعنی پراکسی روی همان ماشین. ExitOnForwardFailure باعث می‌شود فرمان اگر پورت محلی از قبل اشغال باشد با صدای بلند شکست بخورد، به‌جای اینکه نشستی را شروع کند که هیچ‌چیز را هدایت نمی‌کند. نشانی مقصد را همان‌گونه که سرور تحلیل می‌کند بنویسید، زیرا نامی که فقط لپ‌تاپ شما می‌تواند تحلیل کند در سمت دیگر شکست می‌خورد.

سیاست خود سرور پیش از آنکه هر یک از این‌ها کار کند اعمال می‌شود. AllowTcpForwarding باید آن را اجازه دهد، و PermitOpen ممکن است محدود کند که یک نشست به کدام مقصدها و پورت‌ها برسد، بنابراین هدایتی که کلاینت می‌پذیرد هنوز هم ممکن است توسط سرور رد شود. رد شدن به‌صورت خطای هدایت یا کانال در کلاینت ظاهر می‌شود، و خواندن آن پیام از ویرایش فرمان سریع‌تر است.

یک برنامه را به هدایت اشاره دهید

برنامه را طوری پیکربندی کنید که از پراکسی HTTP روی http://127.0.0.1:13128 استفاده کند، با اعتبارنامه اگر پراکسی دور آن‌ها را لازم دارد. تأیید گواهی خود برنامه را برای مقصدهای HTTPS نگه دارید، چون تونل پراکسی جای آن را نمی‌گیرد. این هدایت ثابت یک سرویس است، بنابراین باید به برنامه گفت که پراکسی وجود دارد، نه اینکه رهایش کرد تا خودش یکی را کشف کند.

یک بررسی سریع پیش از هر پیکربندی دائمی: curl -x http://127.0.0.1:13128 -I https://example.com، که روش HTTP CONNECT را که پراکسی باید پشتیبانی کند تمرین می‌کند.

اختیار را همان‌جا که بود نگه دارید

پراکسی دور هنوز تصمیم می‌گیرد کدام مقصدها و روش‌ها را اجازه می‌دهد، و ورود SSH نباید بی‌صدا به هر حساب یک رله وب عمومی بدهد. مقید کردن به 127.0.0.1 روی لپ‌تاپ از انتشار پورت در شبکه محلی شما جلوگیری می‌کند، و پورت را از دیگر فرآیندهای همان ماشین خصوصی نمی‌کند. جایگزین کردن آن مقیدسازی با یک نشانی wildcard برای به اشتراک گذاشتن پراکسی همان راهی است که یک رله باز مدیریت‌نشده ساخته می‌شود.

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

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

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

وقتی کارتان تمام شد، فرآیند SSH مالک را متوقف کنید، تنظیم پراکسی را از برنامه بردارید و تأیید کنید که پورت محلی رفته است، نه اینکه شنونده‌ای بگذارید که از وظیفه عمر بیشتری کند.