.\" Man page generated from reStructuredText .\" by the Docutils 0.22.3 manpage writer. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "SSHUTTLE" "1" "Dec 14, 2025" "1.3" "sshuttle" .SH "نام (NAME)" sshuttle \- ایجاد اتصال VPN از طریق SSH .SH "خلاصه دستور (SYNOPSIS)" .sp \fBsshuttle\fP [\fIoptions\fP] \fB\-r\fP \fI[username@]sshserver[:port]\fP <\fIsubnets\fP ...> .SH "توضیحات (DESCRIPTION)" .sp دستور \fBsshuttle\fP به شما اجازه می‌دهد تا از رایانه خود به هر سرور دوری که امکان اتصال از طریق ssh به آن وجود دارد یک اتصال VPN برقرار کنید، مادامی که روی آن سرور نسخه به اندازه کافی جدیدی از Python نصب باشد. .sp برای کارکرد این ابزار، داشتن دسترسی ریشه (root) روی رایانه محلی الزامی است، اما روی سرور داشتن یک حساب کاربری عادی کافی خواهد بود. .sp اجرای هم‌زمان بیش از یک نمونه از \fBsshuttle\fP بر روی یک رایانه کارخواه (کلاینت) و اتصال هر بار به یک سرور مجزا کاملاً معتبر است؛ بنابراین می‌توانید در آنِ واحد به بیش از یک VPN متصل باشید. .sp اگر \fBsshuttle\fP بر روی یک مسیریاب (روتر) اجرا شود، می‌تواند ترافیک تمام زیرشبکه (subnet) شما را به VPN بازفرستد. .SH "گزینه‌ها (OPTIONS)" .INDENT 0.0 .TP .B فهرستی از زیرشبکه‌ها برای مسیریابی از طریق VPN، به فرم \fBa.b.c.d[/width][port[\-port]]\fP\&. نمونه‌های معتبر عبارتند از 1.2.3.4 (یک آدرس IP تکی) و 1.2.3.4/32 (معادل با 1.2.3.4)، 1.2.3.0/24 (یک زیرشبکه ۲۴ بیتی، یعنی با ماسک شبکه 255.255.255.0). برای تطابق با تمام آدرس‌های IPv4 زیرشبکه 0/0 و برای تطابق با تمام آدرس‌های IPv6 زیرشبکه ::/0 را مشخص کنید. هر یک از نمونه‌های پیشین در صورت افزودن یک درگاه یا بازه‌ای از درگاه‌ها نیز معتبر هستند؛ بنابراین 1.2.3.4:8000 تنها ترافیکی را تونل می‌کند که درگاه مقصد آن 8000 از آدرس 1.2.3.4 باشد و 1.2.3.0/24:8000\-9000 ترافیک ارسالی به هر درگاهی بین 8000 تا 9000 (شامل هر دو) را برای تمام IPهای موجود در زیرشبکه 1.2.3.0/24 تونل خواهد کرد. به جای آدرس IP می‌توان یک نام میزبان وارد کرد. اگر نام میزبان به چندین IP ترجمه شود، تمامی آن IPها لحاظ می‌شوند. اگر به همراه نام میزبان یک پهنا (width) مشخص شود، آن پهنا به تمامی IPهای آن نام میزبان (در صورتی که همگی یا IPv4 و یا IPv6 باشند) اعمال می‌گردد. نمی‌توان پهنا را برای نام‌های میزبانی که هم به IPv4 و هم به IPv6 ترجمه می‌شوند مشخص کرد. نمونه‌های معتبر عبارتند از example.com، example.com:8000، example.com/24، example.com/24:8000 و example.com:8000\-9000. .UNINDENT .INDENT 0.0 .TP .B \-\-method کدام روش دیوار آتش (firewall) باید توسط sshuttle استفاده شود؟ برای auto، برنامه sshuttle تلاش می‌کند تا با توجه به آنچه در PATH می‌یابد، روش مناسب را حدس بزند. مقدار پیش‌فرض auto است. .UNINDENT .INDENT 0.0 .TP .B \-l <[ip:]port>, \-\-listen=<[ip:]port> استفاده از این آدرس ip و شماره درگاه به عنوان درگاه پروکسی شفاف (transparent proxy). به‌طور پیش‌فرض \fBsshuttle\fP به‌طور خودکار یک درگاه در دسترس پیدا کرده و روی IP 127.0.0.1 (localhost) گوش می‌دهد، بنابراین نیازی به بازنویسی آن ندارید و اتصالات تنها از رایانه محلی پروکسی می‌شوند، نه از رایانه‌های بیرونی. اگر می‌خواهید اتصالات را از سایر رایانه‌های موجود در شبکه خود بپذیرید (یعنی برای اجرای \fBsshuttle\fP روی یک مسیریاب)، فعال‌سازی IP Forwarding در هسته سیستم را بررسی کرده و سپس از \fB\-\-listen 0.0.0.0:0\fP استفاده کنید. می‌توانید از هر نامی که به یک آدرس IP رایانه اجراکننده \fBsshuttle\fP ترجمه می‌شود استفاده کنید، مانند \fB\-\-listen localhost\fP\&. .sp برای روش‌های nft، tproxy و pf این مقدار می‌تواند یک آدرس IPv6 باشد. در صورت نیاز، از این گزینه با مقادیر جداشده با کاما استفاده کنید تا هم آدرس IPv4 و هم IPv6 مشخص شوند، مانند \fB\-\-listen 127.0.0.1:0,[::1]:0\fP\&. .UNINDENT .INDENT 0.0 .TP .B \-H, \-\-auto\-hosts پویش برای یافتن نام‌های میزبان دوردست و به‌روزرسانی فایل محلی /etc/hosts با مدخل‌های منطبق تا زمانی که اتصال VPN برقرار است. این روش به چند دلیل از تغییر تنظیمات DNS سیستم (/etc/resolv.conf) بهتر است. اول اینکه نام‌های میزبان بدون پسوند نام دامنه اضافه می‌شوند، بنابراین می‌توانید بدون نگرانی از تطابق دامنه محلی با دامنه دوردست، دستور \fBssh thatserver\fP را اجرا کنید. دوم اینکه اگر هم‌زمان با \fBsshuttle\fP به بیش از یک VPN متصل شوید، در هر صورت استفاده هم‌زمان از بیش از یک سرور DNS غیرممکن است، اما \fBsshuttle\fP مدخل‌های /etc/hosts را به‌درستی بین تمام نمونه‌های در حال اجرا ترکیب (merge) می‌کند. سوم اینکه اگر تنها تعداد کمی زیرشبکه را از طریق VPN مسیریابی می‌کنید، احتمالاً ترجیح می‌دهید برای بقیه موارد همچنان از سرور DNS محلی خود استفاده کنید. .sp برنامه \fBsshuttle\fP تلاش می‌کند یک نسخه حافظه نهان (cache) از نام‌های میزبان را در فایل ~/.sshuttle.hosts روی میزبان دوردست ذخیره کند. همچنین، زمانی که بعداً با فعال بودن \-\-auto\-hosts مجدداً به میزبان متصل شوید، تلاش می‌کند این فایل را بخواند تا فهرست میزبان‌ها را به‌سرعت بارگذاری کند. هنگام عیب‌یابی این ویژگی، حذف این فایل را در میزبان دوردست در زمانی که sshuttle در حال اجرا نیست بررسی کنید. .UNINDENT .INDENT 0.0 .TP .B \-N, \-\-auto\-nets علاوه بر زیرشبکه‌های ارائه‌شده در خط فرمان، از سرور پرسیده می‌شود که فکر می‌کند کدام زیرشبکه‌ها باید مسیریابی شوند و آن‌ها را به‌طور خودکار مسیریابی می‌کند. این پیشنهادها به‌طور خودکار از جدول مسیریابی (routing table) سرور دریافت می‌شوند. .sp این ویژگی مسیرهای IPv6 را تشخیص نمی‌دهد. زیرشبکه‌های IPv6 را به‌صورت دستی مشخص کنید. برای نمونه، زیرشبکه \fB::/0\fP را در خط فرمان تعیین کنید تا تمام ترافیک IPv6 مسیریابی شود. .UNINDENT .INDENT 0.0 .TP .B \-\-dns رهگیری درخواست‌های DNS محلی و بازفرستادن آن‌ها به سرور DNS دوردست. تمام پرس‌وجوها به هر یک از سرورهای DNS سیستم محلی (/etc/resolv.conf و، در صورت وجود، /run/systemd/resolve/resolv.conf) رهگیری شده و در عوض در سمت دوردست تونل حل‌وفصل می‌شوند؛ در آنجا در صورت مشخص شدن، از DNS تعیین‌شده با گزینه \fB\-\-to\-ns\fP استفاده می‌شود. تنها ترافیک عادی DNS که به درگاه 53 این سرورها ارسال می‌شود رهگیری می‌گردد. .UNINDENT .INDENT 0.0 .TP .B \-\-ns\-hosts= رهگیری درخواست‌های DNS محلی ارسالی به سرور(های) مشخص‌شده و بازفرستادن آن‌ها به سرور DNS دوردست. برخلاف گزینه \fB\-\-dns\fP، این پرچم اجازه می‌دهد سرور(های) DNS که پرس‌وجوهای ارسالی به آن‌ها باید رهگیری شوند را مشخص کنید، به جای آنکه تمام ترافیک DNS رایانه محلی رهگیری شود. این مورد می‌تواند زمانی مفید باشد که تنها درخواست‌های DNS خاصی باید در سمت دوردست تونل حل‌وفصل شوند، مثلاً در ترکیب با dnsmasq. .UNINDENT .INDENT 0.0 .TP .B \-\-to\-ns= سرور DNS برای ارسال درخواست‌ها به آن در زمانی که حل‌وفصل نام دوردست فعال است. اگر تعیین نشود، sshuttle به سادگی با استفاده از تحلیل‌گر پیکربندی‌شده سیستم در سمت دوردست (از طریق /etc/resolv.conf سمت دوردست) درخواست‌ها را حل‌وفصل خواهد کرد. .UNINDENT .INDENT 0.0 .TP .B \-\-python نام یا مسیر مفسر python در سیستم دوردست را مشخص می‌کند. پیش‌فرض استفاده از \fBpython3\fP (یا \fBpython\fP، در صورت عدم موفقیت \fBpython3\fP) در PATH سیستم دوردست است. .UNINDENT .INDENT 0.0 .TP .B \-r <[username@]sshserver[:port]>, \-\-remote=<[username@]sshserver[:port]> نام میزبان دوردست و در صورت تمایل نام کاربری و شماره درگاه ssh برای اتصال به سرور دوردست. برای نمونه، example.com،‏ \%،‏ \%:2222 یا example.com:2244. این نام میزبان به ssh تحویل داده می‌شود، بنابراین هر نام مستعار (alias) و تنظیمی را که در ~/.ssh/config پیکربندی کرده باشید شناسایی خواهد کرد. .UNINDENT .INDENT 0.0.TP .B \-x , \-\-exclude= صریحاً این زیرشبکه را از بازفرستادن (forwarding) مستثنی می‌کند. قالب این گزینه مشابه گزینهٔ \fB\fP است. برای مستثنی کردن بیش از یک زیرشبکه، گزینهٔ \fB\-x\fP را بیش از یک بار مشخص کنید. به عنوان مثال، می‌توانید عبارتی مانند \fB0/0 \-x 1.2.3.0/24\fP را مشخص کنید تا همه چیز به جز زیرشبکهٔ محلی از طریق VPN هدایت شود. .UNINDENT .INDENT 0.0 .TP .B \-X , \-\-exclude\-from= زیرشبکه‌های مشخص‌شده در یک فایل را مستثنی می‌کند، یک زیرشبکه در هر خط. زمانی که زیرشبکه‌های زیادی برای مستثنی کردن دارید مفید است. .UNINDENT .INDENT 0.0 .TP .B \-v, \-\-verbose اطلاعات بیشتری دربارهٔ نشست چاپ می‌کند. این گزینه می‌تواند برای افزایش پرگویی بیش از یک بار استفاده شود. به طور پیش‌فرض، \fBsshuttle\fP فقط پیام‌های خطا را چاپ می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-e, \-\-ssh\-cmd دستوری که برای اتصال به کارساز دوردست استفاده می‌شود. مقدار پیش‌فرض فقط \fBssh\fP\& است. اگر کلاینت ssh شما در مکانی غیر استاندارد قرار دارد یا می‌خواهید گزینه‌های اضافی به دستور ssh بدهید، از این گزینه استفاده کنید؛ برای مثال، \fB\-e \(aqssh \-v\(aq\fP\&. .UNINDENT .INDENT 0.0 .TP .B \-\-remote\-shell برای مقصدهای ویندوزی (Windows)، برنامهٔ پوستهٔ دوردستِ پیکربندی‌شده‌ای را به عنوان جایگزین پوستهٔ استاندارد posix مشخص می‌کند. مقدار آن معمولاً \fBcmd\fP یا \fBpowershell\fP خواهد بود، مگر اینکه چیزی مانند git\-bash در حال استفاده باشد. .UNINDENT .INDENT 0.0 .TP .B \-\-no\-cmd\-delimiter پیش از فراخوانی پایتون روی میزبان دوردست، حائل خط تیرهٔ دوتایی (\-\-) را اضافه نمی‌کند. این گزینه زمانی مفید است که دستور ssh استفاده‌شده برای اتصال، یک دستور سفارشی باشد که این حائل را به درستی تفسیر نمی‌کند. .UNINDENT .INDENT 0.0 .TP .B \-\-seed\-hosts فهرستی از نام‌های میزبان که با کاما از هم جدا شده‌اند برای مقداردهی اولیه به الگوریتم پویش \fB\-\-auto\-hosts\fP. گزینهٔ \fB\-\-auto\-hosts\fP کارهایی مانند بررسی خروجی netstat برای دریافت فهرست نام‌های میزبان محلی را انجام می‌دهد، اما اگر با این گزینه چند نام برای شروع به آن بدهید، می‌تواند سرعت کار را افزایش دهد. .sp اگر این گزینه \fIبدون\fP \fB\-\-auto\-hosts\fP استفاده شود، نام‌های میزبان فهرست‌شده پویش و اضافه می‌شوند، اما نام میزبان دیگری اضافه نخواهد شد. .UNINDENT .INDENT 0.0 .TP .B \-\-no\-latency\-control تأخیر (latency) را فدای بهبود معیارهای پهنای باند می‌کند. ssh از بافرهای سوکت بسیار بزرگی استفاده می‌کند که اگر شروع به انتقال فایل‌های حجیم کنید، می‌تواند اتصال را بیش از حد بارگذاری کند و در نتیجه تمام نشست‌های دیگر شما درون همان تونل کند شوند. به طور معمول، \fBsshuttle\fP سعی می‌کند با استفاده از یک «بررسی پر بودن» (\(dqfullness check\(dq) که فقط اجازه می‌دهد مقدار معینی از داده‌های معلق در یک زمان بافر شوند، از این مشکل جلوگیری کند. اما در پیوندهای با پهنای باند بالا، این کار ممکن است باعث شود بخش زیادی از پهنای باند شما استفاده‌نشده باقی بماند. همچنین باعث می‌شود \fBsshuttle\fP در آزمون‌های ارزیابی پهنای باند کند به نظر برسد (آزمون‌های ارزیابی به‌ندرت تأخیر پینگ را که \fBsshuttle\fP تلاش در واپایش آن دارد، می‌سنجند). این گزینه قابلیت واپایش تأخیر را غیرفعال کرده و بهره‌برداری از پهنای باند را به حداکثر می‌رساند. با مسئولیت خودتان استفاده کنید. .UNINDENT .INDENT 0.0 .TP .B \-\-latency\-buffer\-size اندازهٔ بافر استفاده‌شده در واپایش تأخیر را تنظیم می‌کند. مقدار پیش‌فرض \fB32768\fP\& است. تغییر این گزینه امکان مصالحه بین تأخیر و پهنای باند را بدون غیرفعال‌سازی کامل واپایش تأخیر (توسط \fB\-\-no\-latency\-control\fP) فراهم می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-D, \-\-daemon پس از اتصال به کارساز دوردست، به طور خودکار به پس‌زمینه منشعب (fork) می‌شود. متضمن \fB\-\-syslog\fP\& است. .UNINDENT .INDENT 0.0 .TP .B \-s , \-\-subnets= زیرشبکه‌های مشخص‌شده در یک فایل را به جای خط فرمان لحاظ می‌کند؛ یک زیرشبکه در هر خط. .UNINDENT .INDENT 0.0 .TP .B \-\-syslog پس از اتصال، تمام پیام‌های گزارش را به جای stderr به سرویس \fBsyslog(3)\fP ارسال می‌کند. در صورت استفاده از \fB\-\-daemon\fP\& این حالت ضمنی است. .UNINDENT .INDENT 0.0 .TP .B \-\-pidfile= هنگام استفاده از \fB\-\-daemon\fP، شناسهٔ فرایند (pid) مربوط به \fBsshuttle\fP را در \fIpidfilename\fP ذخیره می‌کند. مقدار پیش‌فرض \fBsshuttle.pid\fP در دایرکتوری فعلی است. .UNINDENT .INDENT 0.0 .TP .B \-\-disable\-ipv6 پشتیبانی از IPv6 را برای روش‌هایی که از آن پشتیبانی می‌کنند (nat، nft، tproxy و pf) غیرفعال می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-\-firewall (فقط استفادهٔ داخلی) مدیر دیوار آتش (firewall manager) را اجرا می‌کند. این تنها بخشی از \fBsshuttle\fP است که باید به عنوان کاربر ریشه (root) اجرا شود. اگر \fBsshuttle\fP را به عنوان کاربری غیر از root اجرا کنید، به طور خودکار \fBsudo\fP یا \fBsu\fP را برای راه‌اندازی مدیر دیوار آتش اجرا می‌کند، اما هستهٔ اصلی \fBsshuttle\fP همچنان به عنوان یک کاربر عادی اجرا می‌شود. .UNINDENT .INDENT 0.0 .TP .B \-\-hostwatch (فقط استفادهٔ داخلی) دیمن hostwatch را اجرا می‌کند. این فرایند در سمت کارساز اجرا می‌شود و نام‌های میزبان را برای گزینهٔ \fB\-\-auto\-hosts\fP جمع‌آوری می‌کند. استفاده از این گزینه به تنهایی، اشکال‌زدایی و آزمایش قابلیت \fB\-\-auto\-hosts\fP را بسیار آسان‌تر می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-\-sudoers\-no\-modify دستور sshuttle پیکربندی خاصی را در خروجی استاندارد چاپ می‌کند که به کاربر اجازه می‌دهد sshuttle را بدون گذرواژه اجرا کند. این گزینه ناامن (INSECURE) است زیرا با کمی زیرکی، به کاربر اجازه می‌دهد تا هر دستوری را به عنوان کاربر ریشه بدون گذرواژه اجرا کند. خروجی همچنین شامل یک روش پیشنهادی برای نصب پیکربندی است. .sp برای تغییر کاربری که این پیکربندی روی آن اعمال می‌شود، از \-\-sudoers\-user استفاده کنید. .UNINDENT .INDENT 0.0 .TP .B \-\-sudoers\-user نام کاربر یا گروه را با %group_name برای عملیات بدون گذرواژه تعیین می‌کند. مقدار پیش‌فرض کاربر فعلی است. برای همهٔ کاربران مقدار آن را روی ALL تنظیم کنید (توصیه نمی‌شود: یادداشت مربوط به امنیت در مستندات \-\-sudoers\-no\-modify در بالا را ببینید). فقط با گزینهٔ \-\-sudoers\-no\-modify کار می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-t , \-\-tmark= گزینه‌ای که توسط روش tproxy استفاده می‌شود: از نشان (mark) ترافیک مشخص‌شده استفاده می‌کند. نشان باید یک مقدار هگزادسیمال باشد. پیش‌فرض 0x01 است. .UNINDENT .INDENT 0.0 .TP .B \-\-version نسخهٔ برنامه را چاپ می‌کند. .UNINDENT.SH "فایل پیکربندی (CONFIGURATION FILE)" .sp تمام گزینه‌های شرح‌داده‌شده در بالا می‌توانند به‌صورت اختیاری در یک فایل پیکربندی مشخص شوند. .sp برای اجرای \fBsshuttle\fP با گزینه‌های تعریف‌شده در مثلاً \fI/etc/sshuttle.conf\fP، تنها کافی است مسیر فایل را به‌همراه نویسهٔ \fI@\fP در ابتدای آن ارسال کنید؛ مانند \fI@/etc/sshuttle.conf\fP\&. .sp هنگام اجرای \fBsshuttle\fP با گزینه‌های تعریف‌شده در فایل پیکربندی، علاوه بر موارد تعریف‌شده در فایل، همچنان می‌توان گزینه‌ها را از طریق خط فرمان نیز ارسال کرد. اگر یک گزینهٔ مشخص هم در فایل و هم در خط فرمان تعریف شده باشد، مقدار خط فرمان اولویت خواهد داشت. .sp آرگومان‌های خوانده‌شده از فایل باید مطابق نمونهٔ زیر، در هر سطر یکی باشند: .INDENT 0.0 .INDENT 3.5 .sp .EX value \-\-option1 value1 \-\-option2 value2 .EE .UNINDENT .UNINDENT .sp فایل پیکربندی از یادداشت‌ها (کامنت‌ها) برای توضیحات خوانا توسط انسان پشتیبانی می‌کند. برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX # company\-internal API 8.8.8.8/32 # home IoT 192.168.63.0/24 .EE .UNINDENT .UNINDENT .SH "متغیر محیطی (ENVIRONMENT VARIABLE)" .sp می‌توانید گزینه‌های خط فرمان را با متغیر محیطی \fISSHUTTLE_ARGS\fP تعیین کنید. اگر گزینه‌ای هم در متغیر محیطی و هم در خط فرمان تعریف شده باشد، مقدار خط فرمان اولویت خواهد داشت. .sp برای نمونه: .INDENT 0.0 .INDENT 3.5 .sp .EX SSHUTTLE_ARGS=\(dq\-e \(aqssh \-v\(aq \-\-dns\(dq sshuttle \-r example.com 0/0 .EE .UNINDENT .UNINDENT .SH "مثال‌ها (EXAMPLES)" .sp از دستور زیر برای هدایت تمام ترافیک TCP در IPv4 از طریق میزبان دوردست (\-r) example.com (و احتمالاً ترافیک‌های دیگر، بسته به \-\-method انتخابی) استفاده کنید. زیرشبکهٔ 0/0 که کوته‌نوشت 0.0.0.0/0 است، با تمام نشانی‌های IPv4 مطابقت دارد. زیرشبکهٔ ::/0 نیز که با تمامی نشانی‌های IPv6 مطابقت دارد، می‌تواند به مثال افزوده شود. ما همچنین example.com:22 را مستثنی (\-x) می‌کنیم تا بتوانیم اتصال‌های ssh را از دستگاه محلی به میزبان دوردست بدون هدایت شدن از طریق sshuttle برقرار کنیم. مستثنی کردن میزبان دوردست ممکن است در برخی ماشین‌ها برای کارکرد درست sshuttle ضروری باشد. برای خروج کلید‌های Ctrl+C را فشار دهید. برای هدایت پرس‌وجوهای DNS از طریق sshuttle، افزودن \-\-dns را امتحان کنید. برای مشاهدهٔ اطلاعات بیشتر یا کمتر، گزینه‌های \-v را اضافه یا حذف کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sshuttle \-r example.com \-x example.com:22 0/0 Starting sshuttle proxy (version ...). [local sudo] Password: fw: Starting firewall with Python version 3.9.5 fw: ready method name nat. c : IPv6 disabled since it isn\(aqt supported by method nat. c : Method: nat c : IPv4: on c : IPv6: off (not available with nat method) c : UDP : off (not available with nat method) c : DNS : off (available) c : User: off (available) c : Subnets to forward through remote host (type, IP, cidr mask width, startPort, endPort): c : (, \(aq0.0.0.0\(aq, 0, 0, 0) c : Subnets to exclude from forwarding: c : (, \(aq...\(aq, 32, 22, 22) c : (, \(aq127.0.0.1\(aq, 32, 0, 0) c : TCP redirector listening on (\(aq127.0.0.1\(aq, 12299). c : Starting client with Python version 3.9.5 c : Connecting to server... user@example.com\(aqs password: s: Starting server with Python version 3.6.8 s: latency control setting = True s: auto\-nets:False c : Connected to server. fw: setting up. fw: iptables \-w \-t nat \-N sshuttle\-12299 fw: iptables \-w \-t nat \-F sshuttle\-12299 \&... Accept: 192.168.42.121:60554 \-> 77.141.99.22:22. ^C c : Keyboard interrupt: exiting. c : SW\(aqunknown\(aq:Mux#1: deleting (1 remain) c : SW#7:192.168.42.121:60554: deleting (0 remain) .EE .UNINDENT .UNINDENT .sp اتصال به یک سرور دوردست، با حدس خودکار نام میزبان و زیرشبکه: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sshuttle \-vNHr example.com \-x example.com:22 Starting sshuttle proxy (version ...). [local sudo] Password: fw: Starting firewall with Python version 3.9.5 fw: ready method name nat. c : IPv6 disabled since it isn\(aqt supported by method nat. c : Method: nat c : IPv4: on c : IPv6: off (not available with nat method) c : UDP : off (not available with nat method) c : DNS : off (available) c : User: off (available) c : Subnets to forward through remote host (type, IP, cidr mask width, startPort, endPort): c : NOTE: Additional subnets to forward may be added below by \-\-auto\-nets. c : Subnets to exclude from forwarding: c : (, \(aq...\(aq, 32, 22, 22) c : (, \(aq127.0.0.1\(aq, 32, 0, 0) c : TCP redirector listening on (\(aq127.0.0.1\(aq, 12300). c : Starting client with Python version 3.9.5 c : Connecting to server... user@example.com\(aqs password: s: Starting server with Python version 3.6.8 s: latency control setting = True s: auto\-nets:True c : Connected to server. c : seed_hosts: [] s: available routes: s: 77.141.99.0/24 fw: setting up. fw: iptables \-w \-t nat \-N sshuttle\-12300 fw: iptables \-w \-t nat \-F sshuttle\-12300 \&... c : Accept: 192.168.42.121:60554 \-> 77.141.99.22:22. ^C c : Keyboard interrupt: exiting. c : SW\(aqunknown\(aq:Mux#1: deleting (1 remain) c : SW#7:192.168.42.121:60554: deleting (0 remain) .EE .UNINDENT .UNINDENT .sp اجرای \fBsshuttle\fP با فایل پیکربندی \fI/etc/sshuttle.conf\fP: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sshuttle @/etc/sshuttle.conf .EE .UNINDENT .UNINDENT .sp استفاده از گزینه‌های تعریف‌شده در \fI/etc/sshuttle.conf\fP ولی با خروجی پرجزئیات‌تر: .INDENT 0.0 .INDENT 3.5 .sp .EX $ sshuttle @/etc/sshuttle.conf \-vvv .EE .UNINDENT .UNINDENT .sp جایگزینی سرور دوردستِ تعریف‌شده در \fI/etc/sshuttle.conf\fP: .INDENT 0.0 .INDENT 3.5.sp .EX $ sshuttle @/etc/sshuttle.conf \-r otheruser@test.example.com .EE .UNINDENT .UNINDENT .sp نمونه فایل پیکربندی: .INDENT 0.0 .INDENT 3.5 .sp .EX 192.168.0.0/16 \-\-remote user@example.com .EE .UNINDENT .UNINDENT .SH "بحث و بررسی (DISCUSSION)" .sp هنگام شروع، \fBsshuttle\fP یک نشست ssh با سرور مشخص‌شده توسط گزینه \fB\-r\fP ایجاد می‌کند. .sp پس از اتصال به سرور دوردست، \fBsshuttle\fP کد منبع (پایتون) خود را به سمت دوردست ارسال کرده و در آنجا اجرا می‌کند. بنابراین، نیازی به نصب \fBsshuttle\fP بر روی سرور دوردست نیست و هرگز تداخل نسخه‌ای برای \fBsshuttle\fP میان کلاینت و سرور پیش نخواهد آمد. .sp برخلاف بیشتر VPNها، \fBsshuttle\fP نشست‌ها را هدایت می‌کند، نه بسته‌ها را. بدین معنا که از پروکسی شفاف هسته (قوانین \fIiptables REDIRECT\fP در لینوکس) برای دریافت نشست‌های خروجی TCP استفاده کرده، سپس نشست‌های TCP کاملاً مجزایی را به سمت مقصد اصلی در سوی دیگر تونل ایجاد می‌کند. .sp هدایت در سطح بسته (مانند استفاده از دستگاه‌های tun/tap در لینوکس) در نگاه اول ایده‌آل به نظر می‌رسد، اما به چندین مشکل می‌انجامد، به‌ویژه مشکل \(aqtcp over tcp\(aq. پروتکل tcp اساساً برای پیاده‌سازی الگوریتم کنترل ازدحام خود به دور انداخته شدن بسته‌ها وابسته است؛ اگر بسته‌های tcp را از یک تونل مبتنی بر tcp (مانند ssh) عبور دهید، بسته‌های درونی tcp هرگز دور انداخته نخواهند شد، و در نتیجه کنترل ازدحام جریان درونی tcp کاملاً از کار می‌افتد و کارایی به شدت افت خواهد کرد. از این رو، VPNهای مبتنی بر بسته (مانند IPsec و openvpn) نمی‌توانند از جریان‌های رمزگذاری‌شده مبتنی بر tcp مانند ssh یا ssl استفاده کنند و مجبورند رمزگذاری خود را از پایه پیاده‌سازی نمایند، که بسیار پیچیده و مستعد خطا است. .sp سادگی \fBsshuttle\fP از این واقعیت سرچشمه می‌گیرد که می‌تواند با اطمینان از تونل رمزگذاری‌شده ssh موجود استفاده کند، بدون آنکه دچار افت کارایی شود. این کار با سپردن مدیریت جریان ورودی tcp به هسته سمت کلاینت و مدیریت جریان خروجی tcp به هسته سمت سرور انجام می‌شود؛ نیازی نیست کنترل ازدحام میان دو جریان مجزا به اشتراک گذاشته شود، بنابراین استفاده از یک تونل مبتنی بر tcp بدون مشکل خواهد بود. .sp \fBهمچنین ببینید:\fP .INDENT 0.0 .INDENT 3.5 \fBssh(1)\fP، \fBpython(1)\fP .UNINDENT .UNINDENT .SH "نویسندگان (AUTHORS)" Brian May .SH "کپی‌رایت و تکثیر (COPYRIGHT)" 2016, Brian May .\" End of generated man page.