Reza

یک سوال جالب

6 min read

ساکس سرور روی یک پورت خاص لیستن میکنه؟ من حس میکنم یک نوع دیگه لیستن میکنه چون من در کنارش میتونم nc -l بزنم!

ChatGPT said:

ChatGPT

بله، SOCKS سرور هم روی یک پورت خاص گوش می‌دهد، اما نحوه گوش دادن آن متفاوت از nc (netcat) معمولی است. این تفاوت به دلیل مکانیزم‌های خاصی است که در سرورهای SOCKS و نحوه مدیریت سوکت‌ها استفاده می‌شود.

چرا SOCKS سرور و nc می‌توانند کنار هم کار کنند؟

  1. SOCKS سرور از سوکت‌های چندگانه (Multiple Sockets) استفاده می‌کند:

    • یک SOCKS سرور، مثل Dante یا OpenSSH در حالت فورواردینگ، ممکن است از یک سوکت برای مدیریت ارتباطات ورودی (لیسن روی پورت) استفاده کند و سپس برای هر اتصال جدید، یک سوکت جداگانه (child socket) ایجاد کند.
    • به همین دلیل، ممکن است تصور شود که برنامه دیگری می‌تواند همزمان روی همان پورت گوش کند، اما در واقع این پورت به SOCKS سرور اختصاص دارد.

  2. استفاده از سوکت‌های غیرفعال (Passive Listening):

    • در بسیاری از پیاده‌سازی‌های SOCKS سرور، سوکت اصلی برای “لیسن کردن” به صورت غیرفعال (passive) باقی می‌ماند، اما ارتباطات واقعی در سوکت‌های جدید مدیریت می‌شوند. این معماری اجازه می‌دهد که فرآیندهای دیگری مثل tcpdump یا حتی nc بتوانند در برخی موارد روی پورت مشابه داده‌ها را ببینند.

  3. لیسن کردن nc در محدوده متفاوتی:

    • وقتی از nc برای گوش دادن روی همان پورت استفاده می‌کنید، ممکن است به‌جای دریافت داده‌های مستقیم، فقط بسته‌هایی که از سمت SOCKS سرور رد می‌شوند را مشاهده کنید.
    • اگر nc بعد از SOCKS سرور روی همان پورت گوش کند، ممکن است نتیجه متفاوتی ببینید و بسته‌های واقعی از دست بروند.

چگونه تست کنیم؟

برای این‌که مطمئن شوید یک پورت به SOCKS سرور اختصاص یافته یا خیر، می‌توانید مراحل زیر را دنبال کنید:

۱. بررسی پورت با ss یا netstat:

SOCKS سرور باید روی یک پورت خاص گوش کند. بررسی کنید:

bash

Copy code

ss -tuln | grep 1080

خروجی باید چیزی شبیه این باشد:

ruby

Copy code

tcp LISTEN 0 128 0.0.0.0:1080 0.0.0.0:*

این نشان می‌دهد که پورت ۱۰۸۰ توسط SOCKS سرور گرفته شده است.

۲. تلاش برای لیسن کردن با nc:

حالا با استفاده از nc روی همان پورت گوش کنید:

bash

Copy code

nc -l -k 1080

اگر پورت ۱۰۸۰ در حال حاضر توسط SOCKS سرور گرفته شده باشد، با خطایی مانند زیر مواجه می‌شوید:

makefile

Copy code

nc: Address already in use

اگر خطایی دریافت نکردید و nc روی همان پورت گوش کرد، احتمالاً SOCKS سرور به‌درستی در حال لیسن نیست یا از مکانیزم خاصی برای اشتراک‌گذاری پورت استفاده می‌کند.

۳. بررسی دقیق‌تر با lsof:

برای اطمینان، ببینید چه فرآیندی پورت ۱۰۸۰ را گرفته است:

bash

Copy code

sudo lsof -i :1080

خروجی چیزی شبیه این خواهد بود:

Copy code

sshd 12345 root 3u IPv4 123456 TCP *:1080 (LISTEN)

اگر SOCKS سرور روی این پورت در حال گوش دادن باشد، نام فرآیند (مثلاً sshd یا danted) مشخص می‌شود.

جمع‌بندی:

  • SOCKS سرور به صورت فعال روی یک پورت خاص گوش می‌دهد.
  • امکان اجرای همزمان nc -l روی همان پورت به مکانیزم SOCKS سرور و نحوه مدیریت سوکت‌ها بستگی دارد.
  • برای درک دقیق‌تر، بهتر است از ابزارهایی مثل ss، lsof یا tcpdump استفاده کنید تا رفتار شبکه و سوکت‌ها را مشاهده کنید.

nc -l -k 1080

تا این رو قبول کردم و درسته حالا چطور من رو همین 1080 که توسط socks گرفته شده میتونم ریورس بزنم و کار میکنه! ssh -R 1080:localhost:1080 root@107.175.73.102 مگه ریورس پراکسی هم یک نوع لیستن ایجاد نمیکنه ؟

ChatGPT said:

ChatGPT

سؤال بسیار خوبی است! دلیل اینکه وقتی روی پورتی که توسط SOCKS سرور گرفته شده، با دستور زیر ریورس پراکسی (ssh -R) ایجاد می‌کنید و همچنان کار می‌کند، به نحوه مدیریت سوکت‌ها در SSH و SOCKS برمی‌گردد. اجازه دهید این رفتار را دقیق‌تر تحلیل کنیم:

۱. ریورس پراکسی (ssh -R) چگونه کار می‌کند؟

وقتی دستور زیر را اجرا می‌کنید:

bash

Copy code

ssh -R 1080:localhost:1080 root@107.175.73.102

  • این دستور یک سوکت لیسن روی سرور مقصد (مثلاً 107.175.73.102) روی پورت ۱۰۸۰ ایجاد می‌کند.
  • هر اتصالی که به پورت ۱۰۸۰ روی سرور برسد، از طریق تونل SSH به ماشین لوکال شما فوروارد می‌شود (در اینجا به localhost:1080).
  • این فورواردینگ فقط داده‌ها را منتقل می‌کند و جایگزین سوکت اصلی نمی‌شود.

۲. چرا این کار ممکن است؟

ریورس پراکسی در واقع یک فورواردینگ سوکت انجام می‌دهد، نه لیسن مستقیم روی سوکت. این تفاوت کلیدی باعث می‌شود بتوانید از پورت ۱۰۸۰ که قبلاً توسط SOCKS سرور گرفته شده است، استفاده کنید.

مکانیزم دقیق:

  1. SSH ریورس پراکسی به SOCKS سرور متصل می‌شود:

    • وقتی ریورس پراکسی را اجرا می‌کنید، SSH سرور روی سرور مقصد (پورت ۱۰۸۰) گوش می‌دهد و داده‌ها را از طریق تونل SSH به ماشین لوکال شما ارسال می‌کند.
    • در ماشین لوکال، داده‌ها به پورت ۱۰۸۰ که توسط SOCKS سرور مدیریت می‌شود، منتقل می‌شوند.

  2. SOCKS سرور اتصال‌های جدید را مدیریت می‌کند:

    • SOCKS سرور همچنان روی پورت ۱۰۸۰ در حال گوش دادن است و به‌عنوان یک سوکت مادر (parent socket) عمل می‌کند.
    • اتصال‌های ورودی جدید (چه از تونل SSH و چه از جای دیگر) را می‌پذیرد و آن‌ها را پردازش می‌کند.

  3. SSH لیسن مستقیم روی سوکت نمی‌کند:

    • SSH فقط یک تونل برای انتقال داده‌ها ایجاد می‌کند و در عملکرد لیسنر SOCKS سرور اختلالی ایجاد نمی‌کند.

۳. چرا nc -l همزمان کار نمی‌کند؟

بر خلاف ریورس پراکسی، دستور nc -l یک لیسن فعال روی پورت انجام می‌دهد. وقتی سعی می‌کنید nc -l -k 1080 را اجرا کنید:

  • nc مستقیماً سعی می‌کند روی پورت ۱۰۸۰ لیسن کند.
  • از آنجا که پورت قبلاً توسط SOCKS سرور گرفته شده است، سیستم‌عامل اجازه نمی‌دهد دو برنامه همزمان به‌صورت فعال روی یک پورت گوش دهند.

۴. چرا tcpdump و ابزارهای مانیتورینگ کار می‌کنند؟

ابزارهایی مثل tcpdump یا socat می‌توانند داده‌های ورودی/خروجی روی پورت ۱۰۸۰ را مشاهده کنند، چون:

  • آن‌ها “مانیتورینگ غیرفعال” انجام می‌دهند و در عملکرد سوکت اصلی اختلالی ایجاد نمی‌کنند.
  • در این حالت، سوکت اصلی همچنان توسط SOCKS سرور مدیریت می‌شود.

جمع‌بندی:

  • ریورس پراکسی (با ssh -R) به‌جای لیسن مستقیم روی پورت، یک تونل SSH برای انتقال داده‌ها ایجاد می‌کند و به همین دلیل تداخلی با SOCKS سرور ایجاد نمی‌کند.
  • در مقابل، ابزارهایی مثل nc مستقیماً روی پورت گوش می‌دهند و در صورت اشغال بودن پورت، خطا می‌دهند.
  • رفتار SOCKS سرور و نحوه مدیریت سوکت‌ها این امکان را فراهم می‌کند که ریورس پراکسی روی همان پورت بدون مشکل کار کند.

Graph View