sshuttle در برابر VPN کامل: روش آن واقعاً چه چیزی را پوشش می‌دهد
sshuttle فقط آنچه روش ارسالش پشتیبانی می‌کند حمل می‌کند: ابتدا پوشش TCP، DNS و UDP، دسترسی محلی مورد نیاز و کمک‌کننده راه دور را بررسی کنید.
sshuttle انتخاب می‌شود چون SSH از قبل کار می‌کند و رمزنگاری آشنا به نظر می‌رسد، و این استدلال تنها پرسشی را نادیده می‌گیرد که درباره مناسب بودن تصمیم می‌گیرد. کدام بسته‌ها ماشین را ترک می‌کنند، کدام حساب آن‌ها را در طرف دیگر حمل می‌کند و ابزار چه مقدار دسترسی محلی می‌خواهد. این سه پاسخ بسته به روش ارسال متفاوت است، بنابراین پیکربندی‌ای که برای یک برنامه کار می‌کند می‌تواند برای برنامه بعدی بی‌صدا شکست بخورد. بررسی زیر از پروتکلی آغاز می‌شود که برنامه واقعاً به آن نیاز دارد.
با پروتکلی شروع کنید که برنامه به آن نیاز دارد
پشتیبانی پروتکل در sshuttle 2.0 به روشی بستگی دارد که انتخاب می‌کنید. روش‌های NAT و nft در لینوکس TCP و DNS را مدیریت می‌کنند و TPROXY پروتکل UDP عمومی را اضافه می‌کند. هر سکو و هر روش محدودیت‌های خودش را دارد و macOS با سازوکاری کاملاً متفاوت شنود می‌کند. پیش از انتخاب هر چیز، نسخه نصب‌شده، روش انتخاب‌شده و پروتکل‌های مورد نیاز برنامه را یادداشت کنید.
بنابراین یک درخواست TCP موفق درباره یک برنامه UDP یا درباره هر جستجوی DNS چیز بسیار کمی اثبات می‌کند. sshuttle همچنین TCP را به‌صورت جریان می‌بیند نه اینکه بسته‌های کامل IP را تونل کند، پس نتیجه‌ای درباره توان عبوری که از یک VPN متعارف گرفته شده اینجا منتقل نمی‌شود. سازوکاری که واقعاً اجرا می‌کنید را با باری که واقعاً دارید مقایسه کنید.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
آنچه کارخواه به‌صورت محلی نیاز دارد
چیدمان مستند کارخواه به root یا sudo نیاز دارد، چون قواعد شنود محلی نصب می‌کند نه اینکه یک واسط تونل بسازد. همین یک واقعیت داستان امنیت را تغییر می‌دهد: فرایندی با آن دسترسی می‌تواند ترافیک کل ماشین را تغییر مسیر دهد، نه فقط یک برنامه را. دسترسی را بخشی از طراحی بدانید نه جزئیات نصب.
تأیید کنید که ابزار کدام قواعد را نصب کرده و اینکه هنگام خروج ناپدید می‌شوند. نشستی که از کار بیفتد و قواعد شنود را باقی بگذارد می‌تواند ترافیک را مدت‌ها پس از آنکه بهره‌بردار گمان می‌کند اتصال رفته است به سیاه‌چاله بفرستد، و نشانه مانند قطعی شبکه به نظر می‌رسد نه مانند یک قاعده باقی‌مانده.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeفرمان نخست شکل یک فراخوانی معمول است، با پیشوندی که واقعاً نیاز دارید. دومی نشان می‌دهد ابزار چه نصب کرده و سومی تأیید می‌کند که هیچ واسط تونلی ظاهر نشده، که نتیجه انتظاری این طراحی است.
طرف دور چه چیزی اجرا می‌کند
طرف دور یک حساب SSH مجاز به‌همراه محیط کمک‌کننده سازگار پایتون است. ورودی که زیر یک پوسته محدود موفق می‌شود به‌طور خودکار اجازه اجرای آن کمک‌کننده را نمی‌دهد، و حسابی که می‌تواند کمک‌کننده را اجرا کند به‌طور خودکار به هر سرویس هدف نمی‌رسد. هر دو واقعیت به درخواست دسترسی تعلق دارند نه به یادداشت‌های عیب‌یابی.
از بررسی هویت میزبان و احراز هویت حساب محافظت کنید. پذیرفتن یک کلید میزبان ناشناخته برای اینکه نخستین اتصال کار کند بررسی اینکه طرف دور همان ماشین مورد نظر شماست را حذف می‌کند، و اینجا اهمیت بیشتری از ارسال برای یک هدف واحد دارد.
حساب دور را به سرویس‌هایی محدود کنید که گردش کار نیاز دارد، و این دامنه را با کسانی که میزبان را اداره می‌کنند مذاکره کنید. آن‌ها بخشی از رابطه اعتماد هستند و هیچ تنظیمی در سمت کارخواه آن را تغییر نمی‌دهد.
مرز اعتماد کجاست
ارسال یک اتصال API خصوصی از طریق SSH به هر عملیات API مجوز نمی‌دهد. TLS برنامه و ورود به برنامه همچنان اعمال می‌شوند و ابزار نمی‌تواند یک سرویس بدون احراز هویت را ایمن کند. پرش بعدی از میزبان دور نیز به‌طور خودکار همان بخش محافظت‌شده کانال SSH نیست، چون آن اتصال دوم از هر سیاستی که میزبان دور دارد پیروی می‌کند.
مرز را در یک جمله بنویسید: ترافیک به این پیشوندها از این حساب روی آن میزبان خارج می‌شود. اگر جمله به یک بند استثنا نیاز دارد، طراحی بیش از آنچه مستنداتش ادعا می‌کند انجام می‌دهد و پیش از رسیدن به تولید ارزش نگاه دوباره دارد.
آن را برای هر پروتکل اثبات کنید، سپس ابزار را انتخاب کنید
هر پروتکل مورد نیاز را با یک درخواست بی‌خطر آزمایش کنید، همراه با مسیر حل‌کننده و خانواده‌های نشانی که برنامه استفاده می‌کند. قطع اتصال را هم در آزمون بگنجانید تا رفتار مجاز برنامه در شکست نتیجه‌ای شناخته‌شده باشد نه غافلگیری در زمان رخداد. نشستی که تا وقتی برپا بود درست ارسال می‌کرد چیزی درباره آنچه پس از افتادنش رخ می‌دهد نمی‌گوید.
برای چند سرویس که صریحاً نام برده شده‌اند، یک ارسال محلی معمولی آسان‌تر برای مالکیت و آسان‌تر برای حسابرسی است. برای ترافیک برنامه‌ای که با روشش سازگار است، sshuttle یک راه میانه مشروع پیشنهاد می‌کند. وقتی نیاز اتصال گسترده IP است، طراحی VPN پاسخ صادقانه است، و انتخاب از پوشش و مسئولیت عملیاتی پیروی می‌کند نه از رتبه‌بندی الگوریتم‌های رمزنگاری.