🛜 Matrix + IPtables tunneling

سپاس از دوستانی که پروژه رو تست و باگ ها رو ریپورت کردند. یک سری باگ ها فردا رفع میشه.

این تانل بر اساس Matrix+IPtables زده شده برای تست پایداری و عملکرد پروژه است. بر روی سرور فیلتر شده تانل انجام شده است.

vless://a143245e-446b-47f3-bf48-8beb70f84104@194.5.54.182:2057?type=tcp&headerType=http&host=fast.com&path=/&security=none#%F0%9F%9A%80%20Matrix%20+%20IPtables

استفاده کنید که نتیجه رو ببینیم. سرعت سرور بالا نیست. اینجا نتایج رو بگید.

💫 فردا رنگ ها رو برمیدارم که کندی اسکریپت رفع شه.
💫 مشکل تایم اوت شدن نودها پس از اتصال چند نود رو حل میکنم
💫 تانل سرور ایران به خارج فیلتر شده رو با کم کردن ping interval استیبل میکنم.

#matrix
👁@Gozar_Xray

کسانی که فروش وپن انجام میدن این روش اصلا مقرون به صرفه نیست براشون
چون دیاگرام برای این دوستان اینجوری میشه

یوزر => نود ۱ <=> هاست <=> نود ۲

هم نود ۱ و هم هاست باید ایران باشند در صورتیکه اگر فروشنده نباشید دیوایستون میتونه نود ۱ باشه


📝پ.ن

این روش در حال حاضر و با توجه به امکانات موجود برای فروش و تجاری سازی اصلا مناسب و مقرون به صرفه نیست و اگر قرار باشه فقط هاست و نود خارج و استفاده کنید که خیلی روش های کارآمدتری از این هستن مثل رتهول همین سازنده که بسیار مینیمال و بهینه کامپایل کردن هسته رو


اما در حالتی که دیوایس خودتون نود ۱ باشه و هاست(main) سرور ایران و نود ۲ خارج باشه مسلما tinc رقیبی براش نیست

سلام
این مطلب رو که من قسمتی از اون رو نقل قول کردم، قلم یکی از دوستان از کانال OPIran Club هست که برای بنده فرستادند. در مورد اسکریپت ماتریکس نوشتند. اول این که ممنونم که وقت گذاشتند و بررسی کردند. اما لازمه توضیح بدم چون این توضیحات اشتباهه و با مفهوم Mesh Network هم در تضاده.

در اسکریپت ماتریکس نود اصلی وظیفه ی تعیین روتینگ رو برعهده داره و ترافیکی از خودش برای نودهایی که به همدیگه ارتبط مستقیم دارند، عبور نمیده. یعنی اگر A سرور مرکزی باشه برخلاف توضیح دوستمون ترافیک B به A و بعد C نمیره بلکه مستقیم به C میره. اثبات این روش با nload و پینگ هست.

پس نگرانی برای مصرف تجاری نداره. در پست بعدی با پینگ این موضوع رو ثابت میکنم. البته Tinc آپشن های زیادی داره و به صورتی کانفیگ شده که این اتفاق رخ بده. پس با کانفیگ هم میشه به اون چیزی که دوستمون در OPIran توضیح دادند رسید اما در اسکریپت ماتریکس فعلا ارتباطات فقط مستقیم بوده و نود مرکزی وظیفه ی شناسایی نودهای جدید و تعیین روتینگ ها رو برعهده داره.

درباره هسته ی تینک هم که در کانال، ویدئو و کانال به اون اشاره شده، بیشترین محدودیتی که من الان دیدم پیک ترافیک هست که بالای ۴۰۰ مگابیت رو عبور نمیده. در بقیه موارد از رتهول بالاتر هست. ترافیک ۴۰۰ مگابیت هم با توجه به Encrypted بودن دیتا برای شرایط فعلی به نظرم کافی هست.

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

#matrix
👁@Gozar_Xray

پینگ دو سرور ایران به هم در مش نتورک / نود اصلی یا مستر در انگلیس قرار گرفته است.

#matrix
👁@Gozar_Xray

کلی بررسی کردیم که چرا روی سرور رسپینا با ماتریکس تانل زدیم و ترافیک از ۳۰ مگابیت بالاتر نمیره! فکر می کنید دلیل چی بود:

Crypto speeds: AES_128_GCM: 13.5 MiB/s, AES_256_GCM: 5.7 MiB/s, CHACHA20_POLY1305: 54.0 MiB/s

سرعت انکریپشن پردازنده نهایتا ۵۴ مگ در بهترین حالت بود. و چون تینک در حالت تک هسته ای اجرا میشه یک core دائم روی ۱۰۰٪. هست. پس حواستون باشه سرور آشغال بهتون نندازن!

نحوه ی تست:

openssl speed -evp chacha20-poly1305

اگر openssl بزنید انکرپیشن های موجود رو نشون میده.

✅ اگر پردازنده خوب باشه انتظار میره تا ۴۰۰ مگابیت سرعت بره.

#matrix
👁@Gozar_Xray

✅ WaterWall Project

یه پروژه جالب با زبان C مشابه ی هسته ی Xray-Core و SingBox با تمرکز بر تانلینگ و بررسی و مقابله با فایروال ایران.

در گیت هاب پروژه میخونیم:

واتروال یه هسته هست؛ هسته یعنی چی؟ در کل یعنی اینکه این برنامه فقط برای یه روش تونل خاص نیست و روش های زیادی داره که می‌تونید انتخاب کنید و اجرا کنید
درکل تمرکز اصلی این پروژه اول این بوده که بشه باهاش یه تونل خوب اجرا کرد
ولی بعد از تونل هدف این بوده که بشه باهاش کانفیگ مستقیم هم ساخت که باهاش فایروال ایران رو برسی کنیم و هرچی دستگیرمون شد روش اجرا کنیم تا جلوی فیلتر شدنش رو هم بگیریم، و با اخرین تغییرات فایروال ایران پیش بریم

یه کار باارزش و نیازمند حمایت هستش. داشتن یه هسته‌ی اختصاصی برای خودمون یه پیشرفت بزرگ و منحصر به فرد هست.


⭐️ لینک گیت هاب پروژه:

https://github.com/radkesvat/WaterWall?tab=readme-ov-file

#waterwall
👁@Gozar_Xray

✅ به زودی یه آپدیت کوچولو برای Rathole میدم که بشه TCP No_Delay رو خاموش کرد. درباره TCP NoDelay و کاربردش در شبکه و الگوریتم Nagle هم یه توضیح کوتاه میدم.

⁉️ این که در عمل چقدر تفاوت ایجاد کنه رو هم دوستان زحمت تستش رو می کشند. یه بنچمارک هایی هم البته در سطح نت براش هست. اگر کاربر بالا دارید به نظر خاموش کردنش بهتر باشه.

#rathole #TCP_NODELAY
👁@Gozar_Xray

⁉️بخش اول: الگوریتم Nagle چیست؟

یک تکنیک بهینه‌سازی برای کاهش تعداد بسته‌های کوچک داده‌ای در شبکه‌های TCP/IP است. این الگوریتم توسط جان ناگل در سال ۱۹۸۴ ابداع شد و هدف اصلی آن بهبود کارایی انتقال داده‌ها در شبکه‌های کند یا شبکه‌هایی با پهنای باند محدود است.

❓ نحوه کار الگوریتم Nagle

الگوریتم Nagle به این صورت عمل می‌کند که زمانی که داده‌های کوچکی برای ارسال وجود دارند، فرستنده این داده‌ها را تا زمانی که تاییدیه (ACK) از داده‌های قبلی دریافت نکرده باشد، جمع‌آوری و ادغام می‌کند. به عبارت دیگر، اگر فرستنده داده‌های کوچکی داشته باشد که باید ارسال شوند، منتظر می‌ماند تا یا:

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

❓ مزایا و معایب الگوریتم Nagle

مزایا:
کاهش تعداد بسته‌های کوچک: این امر منجر به کاهش سربار پروتکل TCP و بهبود کارایی کلی شبکه می‌شود.
بهینه‌سازی استفاده از پهنای باند: با ترکیب بسته‌های کوچک به یک بسته بزرگ‌تر، استفاده بهینه‌تری از پهنای باند موجود حاصل می‌شود.

معایب:
افزایش تأخیر در برخی کاربردها: برای برنامه‌هایی که نیاز به تأخیر کم دارند (مانند برنامه‌های تعاملی بلادرنگ)، الگوریتم Nagle ممکن است باعث تأخیر‌های غیرقابل قبول شود.
مشکل در ترکیب با تأییدیه تأخیری (Delayed ACK): در برخی موارد، ترکیب الگوریتم Nagle با مکانیزم تأییدیه تأخیری ممکن است باعث تأخیر‌های بیشتر شود.

✅ برای غیرفعال کردن الگوریتم Nagle در برنامه‌نویسی، معمولاً از گزینه TCP_NODELAY استفاده می‌شود که می‌توان آن را روی سوکت TCP تنظیم کرد.


#TCP_NODELAY
👁@Gozar_Xray

⁉️ گزینه TCP_NODELAY چیست؟

یک تنظیم در پروتکل TCP است که به شما اجازه می‌دهد الگوریتم Nagle را غیرفعال کنید. با فعال کردن این گزینه، داده‌ها به محض آماده شدن ارسال می‌شوند و دیگر منتظر ترکیب شدن با داده‌های دیگر یا دریافت تاییدیه از بسته‌های قبلی نخواهند بود.

❓ تأثیر فعال کردن TCP_NODELAY

- ارسال فوری داده‌ها: داده‌ها بلافاصله پس از آماده شدن برای ارسال به شبکه فرستاده می‌شوند.
- کاهش تأخیر: در برنامه‌های بلادرنگ یا تعاملی که نیاز به حداقل تأخیر دارند، فعال کردن TCP_NODELAY می‌تواند باعث کاهش تأخیر شود.
- افزایش تعداد بسته‌های کوچک: با فعال کردن این گزینه، تعداد بسته‌های کوچکی که در شبکه ارسال می‌شوند، افزایش می‌یابد که می‌تواند سربار پروتکل TCP و استفاده از پهنای باند را افزایش دهد.
تجارت الکترونیک و تراکنش‌های مالی: برای کاهش تأخیر در تراکنش‌ها و بهبود تجربه کاربر.

❓تأثیر بر مصرف پردازنده

بسته‌های بیشتر برای پردازش: با ارسال هر داده به محض آماده شدن، تعداد بسته‌هایی که پردازنده باید مدیریت کند، افزایش می‌یابد. این باعث می‌شود پردازنده مجبور باشد تعداد بیشتری بسته را مدیریت کند، که می‌تواند منجر به افزایش بار کاری و مصرف پردازنده شود.

افزایش فراخوانی‌های سیستمی: هر بار که داده‌ای ارسال می‌شود، یک فراخوانی سیستمی به سیستم‌عامل انجام می‌شود. افزایش تعداد این فراخوانی‌ها باعث افزایش سربار پردازنده می‌شود.

❓ تأثیر بر مصرف پهنای باند

سربار بسته‌های بیشتر: هر بسته TCP شامل سرباری (header) است که شامل اطلاعات کنترلی می‌باشد. وقتی بسته‌های کوچک‌تر ارسال می‌شوند، نسبت سربار به داده‌ها بیشتر می‌شود و در نتیجه، پهنای باند بیشتری مصرف می‌شود.

کارایی کمتر: ارسال بسته‌های کوچک‌تر به جای بسته‌های ترکیب شده، منجر به استفاده ناکارآمد از پهنای باند موجود می‌شود.


❓ موارد کاربرد:

- بازی‌های آنلاین: برای اطمینان از اینکه حرکات و اقدامات بازیکنان بدون تأخیر به سرور بازی می‌رسد.
- برنامه‌های صوتی و تصویری بلادرنگ: برای اطمینان از انتقال بدون تأخیر داده‌های صوتی و تصویری.
- تجارت الکترونیک و تراکنش‌های مالی: برای کاهش تأخیر در تراکنش‌ها و بهبود تجربه کاربر.

#TCP_NODELAY
👁@Gozar_Xray

گزینه ی تنظیم TCP_NODELAY در رتهول فعال شد. طبق نیازی که دارید می‌تونید فعال یا غیرفعال کنید. برای استفاده شخصی به نظرم true و در صورت تعداد کاربر بالا false رو امتحان کنید.

مقدار این گزینه در سرور ایران و خارج باید یکسان باشند. مجددا باید کانفیگ کنید که گزینه نمایش داده باشه.

برای غیرفعال کردن باید مجدد کانفیگ کنید.

https://github.com/Musixal/rathole-tunnel/tree/main

#TCP_NODELAY
👁@Gozar_Xray

✅ پروژه ماتریکس رو که من استارت زدم، طبق تست های اولیه که در سیستم خودم داشتم پرفورمنس قابل قبولی داشت. از همون ابتدا هم میدونستم هسته ی Tinc که استفاده شده Single Thread هست و بهینه سازی های کافی روش انجام نشده و برنامه زمان زیادی رو در کرنل تلف میکنه اما پهناباند حدود ۳۰۰ مگابیت قابل قبول بود. مخصوصا این که تینک نسبت به رتهول بهتر از فایروال عبور میکنه.

احتمالا دلیل این که تینک در بعضی سیستم ها بسیار کند هست هم همینه و مربوط به کرنل هست اما این که چه ورژن هایی بهتره رو هنوز اطلاع ندارم و نیازمند تحقیق بیشتره. فعلا یه آپدیت کوچیک دادم و امکان حذف Encryption در گزینه های Expert رو فراهم کردم این کار کمی پهناباند رو بیش تر و مصرف پردازنده رو پایین تر میاره.

⁉️ همین الان هم میتونم جایگزین بهتر و قابل قبول تری برای هسته ی ماتریکس استفاده کنم اما مشغله ی کاری زیاد متاسفانه اجازه این کار و بازنویسی کدها رو نمیده. ممکنه در قالب پروژه دیگری ارائه بدم یا به یک آموزش ویدئویی بسنده کنم. قطعا آموزش ویدئویی با توجه به این که وقت گیر نیست برای من هم بهتره.

#matrix
👁@Gozar_Xray

✅ به زودی جایگزین اسکریپت ماتریکس رو معرفی می کنم. پروتکل های بیشتر، ساده تر، استیبل تر و سریع تر...

#easymesh
👁@Gozar_Xray

⁉️ ویژگی ها:

👾 پهناباند بالای ۴۰۰ مگابیت
👾 مالتی ترد
👾 پشتیبانی از udp, tcp, ws, wss
👾 استیبل تا اینجای کار
👾 فول مش
👾 انکریپشن دیتا
👾 عبور بهتر از فایروال نسبت به رتهول
👾 ارتباط بای دایرکشنال


🚀 فعلا کرنل Xanmod + BBRv3 رو نصب کنید. ممکنه باعث اختلال در سرورتون بشه. پس روی سرور اصلی‌تون تست نکنید.

😤 حوصله doc نوشتن ندارم، اگر موافق هستید تو گروه بگید به صورت ویدئویی توضیح بدم.


#easymesh
👁@Gozar_Xray

🌍 اسکریپت Easy Mesh


🌀 لینک پروژه در گیت هاب


#easymesh
👁@Gozar_Xray

🌀 توضیحاتی چند درباره تانل ها

۱) در مورد رتهول اون هایی که مشکل قطعی داشتند هیچ اطلاعات بیشتری ندادند که من بتونم مشکل رو reproduce کنم. بنابراین میذارم به حساب مشکلات دیتاسنتر و کانفیگ کردن اشتباه و اوپتیمایز نبودن OS. بارها هم گفتم رتهول در کانکشن های بالا معمولا ۲۰ هزار (بسته به سخت افزار سرورتون) دچار افزایش Latency میشه و نیاز به کرون جاب داره. پس بهتره کانفیگ هاتون رو با Mux به مشتری بدید. نصب اوپتیمایزر هم تاثیر داره.

- این که کرون جاب روی چه ساعتی تنظیم باشه رو با نصب Uptime Kuma میتونید متوجه بشید.
- قسمت Port Monitor هم باعث سردرگمی شده و به نظرم آپدیت بعدی حذفش میکنم.
- پیشنهاد این که پورت تانل و کانفیگ ها رو توی اسکریپت نشون بده جالب بود و ممکنه اضافه ش کنم.
- به نظرم وب سوکت مشکلات خودش رو داره و نیاز نیست به تانل اضافه بشه.
- مشکلات اتصال چند سرور خارج به یک سرور ایران اگر خیلی ریپورت شه اصلاحش میکنم.

۲) اسکریپت ماتریکس برای فروش نیست و برای استفاده شخصی کاربرد داره. اگر سرعت خوبی بهتون میده کاملا استیبل هست. هسته ی تینک آپدیت نمیشه و خیلی نمیشه روش حساب کرد که در آینده تغییر بزرگی کنه.

۳) اسکریپت ایزی مش خیلی آینده بهتری داره. از لایبرری قدرتمند Tokio استفاده میکنه و همین لایبرری در رتهول استفاده شده. دولوپر فعالی داره و من مشکلاتی که بود رو در گیت هاب در این لینک issue کردم و پاسخ دادند. برای استفاده شخصی تا این جای کار برای من اوکی بوده ولی برای کاربر زیاد فعلا توصیه نمیکنم مگر این که طبق تست خودتون نتیجه ی خوبی گرفته باشید.

#tunnel
👁@Gozar_Xray

⁉️ چرا تانل TCP over TCP خوب نیست و TCP meltdown چیست؟ و توضیح این که چرا تانل هایی مثل رتهول در کانکشن های بالا مشکل پیدا می‌کنند.

تو شبکه‌های کامپیوتری ارتباطات TCP رو داریم، این ارتباطات طوری طراحی شدن که مطمئن بشن داده‌ها به درستی و بدون خطا به مقصد می‌رسن. حالا فرض کنید که یه تانل TCP in TCP مثل رتهول داریم، یعنی یه اتصال TCP درون یه اتصال TCP دیگه قرار داره. در حالت معمولی، TCP مکانیزم‌هایی داره که اگر داده‌ها با مشکل مواجه بشن یا از دست برن، خودش رو تنظیم کنه. این مکانیزم‌ها شامل موارد زیر هستن:

اول Congestion Control رو داریم: TCP از روش‌هایی مثل Slow Start، Congestion Avoidance و Fast Recovery استفاده می‌کنه تا ترافیک رو مدیریت کنه و از شلوغ شدن بیش از حد شبکه جلوگیری کنه.

دوم Error Detection and Retransmission (تشخیص خطا و ارسال مجدد) رو داریم: اگر یه بسته داده گم بشه یا خراب بشه، TCP دوباره اون بسته رو می‌فرسته.

حالا تصور کنید که این مکانیزم‌ها دارن هم‌زمان در دو لایه TCP (یه TCP داخل یه TCP دیگه) اجرا می‌شن. این یعنی هر بار که یه خطا یا مشکل Congestion رخ می‌ده، هر دو لایه TCP باید اقدامات خودشون رو انجام بدن و به طور موازی تلاش کنن که مشکل رو حل کنن، که این خودش منجر به پیچیدگی بیشتر و مصرف بیشتر منابع می‌شه.

وقتی ترافیک شبکه خیلی زیاد بشه (congestion)، هر دو لایه TCP سعی می‌کنن با کاهش سرعت ارسال داده و تنظیم خودشون به ترافیک زیادی که هست پاسخ بدن. این مسئله باعث موارد زیر می‌شه:

افزایش تأخیر (Latency): چون هر لایه TCP باید منتظر بمونه تا لایه‌ی دیگه کار خودش رو انجام بده.

افزایش بار پردازشی (Processing Overhead): چون پردازنده باید دو بار مکانیزم‌های TCP رو اجرا کنه.

بیشتر شدن احتمال خطا و ارسال مجدد (Increased Retransmissions): چون هر خطا ممکنه دو بار توسط هر دو لایه تشخیص داده بشه و دوباره ارسال بشه.

همچنین، پدیده‌ی جبران (Compensation) هم تو این وضعیت مطرحه. TCP سعی می‌کنه که با کاهش سرعت ارسال و تنظیم مجدد Congestion رو مدیریت کنه. این فرآیندها در لایه‌های متعدد می‌تونن باعث بشن که سرعت کلی ارتباط در کانکشن های بالا به شدت کاهش پیدا کنه، چون هر لایه به تنهایی سعی می‌کنه که خودش رو تنظیم کنه.

این لایه‌لایه شدن بسته‌ها باعث می‌شه که پردازش هر بسته خیلی زمان‌بر و پیچیده بشه و این همون مشکل TCP Meltdown هست که تو شبکه ایجاد می‌شه.

برای جلوگیری از این مشکل، بهتره که از پروتکل‌های غیر TCP مثل UDP برای تانل‌زنی استفاده بشه یا به طور کلی طراحی شبکه رو طوری انجام بدیم که از لایه‌لایه شدن ارتباطات TCP جلوگیری کنیم.

#tcp
👁@Gozar_Xray

🤖 اضافه کردن Watchdog به اسکریپت EasyMesh

با وجود این که اسکریپت EasyMesh در مرحله ی بتاست و در حال صحبت با دولوپرش برای رفع باگ هاش هستم، اما بعضی دوستان علاقه داشتند از این اسکریپت بدون مشکل قطعی استفاده کنند. بنابراین یه گزینه به اسم Watchdog یا نگهبان سرویس به اسکریپت اضافه کردم.

✅ به این صورت عمل کنید. اسکریپت رو اجرا کنید (فقط سرور خارج) و گزینه ۷ رو انتخاب کنید. بعد گزینه اول یعنی Start watchdog رو بزنید. حالا آدرس Local IP ایران رو وارد کنید. بعد مقدار Latency رو مشخص کنید. چیزی حدود ۲۰۰ تا ۳۰۰ میلی ثانیه خوبه. بعد هم فاصله بین هر پینگ رو به ثانیه بزنید. مثلا ۵ یا ۱۰ خوبه. این یعنی هر ۵ ثانیه آدرس لوکال ایران چک میشه و اگر پینگش از عددی که تعیین کردید بالاتر بود، سرویس ریستارت میشه.
می تونید لاگ ها رو هم ببینید. گزینه ۷ و بعد گزینه ۳ برای مشاهده ی لاگ هست.

فعلا در همین حد میشه به این دوستان که قطعی دوره ای دارند کمک کرد. نصب XanMod Kernel رو هم قبلا توصیه کرده بودم. سوالی بود در گروه مطرح کنید.

#easymesh
👁@Gozar_Xray