کدام ترافیک برنامه را یک ارسال SSH در واقع حمل می‌کند؟

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

پیش از مقایسه هر چیزی، رابط را نام ببرید

راهنمای کلاینت OpenSSH چهار سازوکار را از هم جدا می‌کند که به‌آسانی با هم اشتباه می‌شوند. پوسته یا فرمان راه دور روی میزبان SSH اجرا می‌شود. ارسال محلی یک سوکت شنود روی کلاینت باز می‌کند و اتصال بعدی را از سمت دور انجام می‌دهد. ارسال دور برعکس عمل می‌کند و در سمت سرور گوش می‌دهد. ارسال پویا یک نقطه پایانی SOCKS را برای برنامه‌هایی که می‌دانند چگونه از آن استفاده کنند ارائه می‌دهد.

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

هیچ‌یک از این‌ها مسیری نصب نمی‌کند. برنامه‌ای که تنظیمات پروکسی را نادیده می‌گیرد، یا UDP صحبت می‌کند، یا نام‌ها را خودش تفکیک می‌کند، از یک جلسه فعال SSH تأثیر نمی‌پذیرد. این نقص SSH نیست؛ این دامنه رابطی است که انتخاب کرده‌اید.

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

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

فرمان نخست درگاه 5432 را روی لپ‌تاپ می‌بندد و آن را به پایگاه داده همان‌گونه که از باستیون دیده می‌شود ارسال می‌کند. دومی یک پروکسی SOCKS روی درگاه 1080 می‌سازد. فرمان سوم تأیید می‌کند کدام فرایندها واقعاً گوش می‌دهند، و این تنها مدرکی است که ارسال وجود دارد، نه اینکه در سکوت به‌خاطر تعارض درگاه شکست خورده باشد.

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

حالت دستگاه تونل تنها استثنای واقعی شبکه است

OpenSSH همچنین ارسال دستگاه تونل -w را پشتیبانی می‌کند، که به‌جای یک شنونده TCP یک رابط نقطه‌به‌نقطه را عبور می‌دهد. آن یک تونل شبکه واقعی است و آگاهانه پیکربندی می‌شود، نه اثری جانبی از باز کردن یک پوسته.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

حتی در آن صورت، تونل در میزبان دور پایان می‌یابد. هر حفاظتی که انتقال SSH فراهم کرده باشد همان‌جا تمام می‌شود، و اتصال بعدی یک پرش جداست. دروازه VPN هم همین شکل مرز را دارد، از همین رو مقایسه باید درباره دامنه و نقطه پایان باشد نه اینکه کدام ابزار قوی‌تر است. نام بردن بلند این مرز، بحث درباره اینکه آیا یک تونل «همه چیز را رمزنگاری می‌کند» را هم فیصله می‌دهد، چون آشکارا چنین نمی‌کند.

بررسی کنید که برنامه‌تان از رابطی که ساخته‌اید استفاده می‌کند

راستی‌آزمایی برای هر برنامه است، نه برای جلسه. یک ارسال کارآمد ثابت می‌کند که درگاه بسته شده و سمت دور می‌تواند شماره‌گیری کند؛ ثابت نمی‌کند که برنامه‌ای که برایتان مهم است از آن عبور کرده است.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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