طی چند روز اخیر گزارشات متعددی در مورد ضریب زدن روی مصرف بسته‌های اینترنت توسط اپراتورهای اینترنت ایران مشاهده کردم.
یعنی اگه از پلتفرم‌ها، سایت‌های خارجی و در مجموع VPN استفاده کنید، حجم اینترنتتون چیزی حدود 2.5 برابر بیشتر از پلتفرم‌ها و سایت‌های داخلی مصرف میشه و بسته‌ی اینترنتتون زودتر تموم میشه.

دزدی که دیگه شاخ و دم نداره...

سعی می‌کنم در آپدیت بعدی DoH Proxy تا حد ممکن کاری کنم که حجم اینترنتتون بصورت عادی و شاید حتی نیم‌بها محاسبه بشه.

🟢 آپدیت DoH Proxy - نسخه‌ی Pro

🔘 تغییرات این آپدیت:

✅ بازطراحی کامل مکانیزم Anti-DPI Fragmentation در پنل DoH Proxy با هدف عبور از DPI بدون نیاز به تغییر مسیر ترافیک از طریق VPN یا Proxy Tunnel. در این نسخه، الگوی Fragmentation در سطح TCP/TLS Handshake و همچنین Routing مبتنی بر GeoIP/GeoSite بهینه‌سازی شده تا ارتباط با سرویس‌ها و پلتفرم‌های خارجی، در صورت امکان، مستقیما از طریق Public IP اپراتور برقرار شود و تنها فرآیند DNS Resolution از طریق DoH انجام گیرد. این معماری باعث می‌شود ترافیک کاربردی Payload همچنان با IP ایران برقرار شده و صرفا مکانیزم شناسایی و اعمال فیلترینگ مبتنی بر DPI دور زده شود.

✅ نتیجه‌ی این تغییرات، در بسیاری از سناریوها، امکان دسترسی به سرویس‌ها و وب‌سایت‌های خارجی بدون استفاده از IP خارجی است؛ بنابراین اپراتور ترافیک را بصورت کامل به‌عنوان ترافیک با مبدا IP ایران مشاهده می‌کند. این موضوع می‌تواند بسته به سیاست و نحوه‌ی محاسبه‌ی ترافیک هر اپراتور، باعث محاسبه‌ی حجم اینترنت به‌صورت عادی یا حتی نیم‌بها شود، در حالی که همچنان قابلیت دسترسی به سرویس‌های خارجی حفظ می‌شود.

🔘 نسخه‌های موجود:
✅ Cloudflare Workers
✅ Cloudflare Pages

🟢 برای دریافت کد DoH Proxy جهت استفاده در Cloudflare Workers، فقط کافیه عبارت DoH (دقیقا به همین شکل) رو در ربات ارسال کنید. یا اینکه روی این لینک مستقیم کلیک کنید:

https://t.me/An0nymou3Bot?start=DoH

⚠️ توجه داشته باشید که این آموزش با فرض داشتن یک حداقل دانش فنی تهیه شده.
یعنی فرض من بر اینه که کاربران با مراحل پایه‌ای مثل ساخت حساب کاربری در Cloudflare، ایجاد یک Worker جدید، و قرار دادن این کد در محیط Cloudflare Workers Editor آشنایی اولیه دارن.

برای علاقه‌مندان به دنیای Open Source:

تمامی کدها، مستندات فنی، و آموزش‌های مربوط به راه‌اندازی پروژه‌ی DoH Proxy رو به‌صورت کامل در GitHub منتشر کردم.
این پروژه رو تحت لایسنس MIT ارائه دادم، تا همه بتونن آزادانه ازش استفاده کنن، توسعه‌ش بدن، یا در پروژه‌های خودشون به‌کار ببرن.

https://github.com/4n0nymou3/cloudflare-doh-proxy

Anonymous

🟢 آپدیت Tunnel Config Builder (TCB) ورژن 5.2

- اضافه شدن بخش جدید Observatory Settings به تنظیمات پیشرفته‌ی پنل TCB. این بخش شامل پنج تنظیم است:

leastPing Interval
leastLoad Interval
leastLoad Mode (HEAD/GET)
leastLoad Sampling
leastLoad Timeout

کاربران می‌توانند مقادیر زمانی را با پسوند m (دقیقه) یا s (ثانیه) وارد کنند و پنل به‌صورت خودکار از ورود مقادیر نامعتبر در این کادرها جلوگیری می‌کند. این تنظیمات فقط روی کانفیگ JSON مخصوص هسته‌ی Xray اعمال می‌شوند و تاثیری روی کانفیگ‌های Sing-box و Clash ندارند.

- حذف کامل گزینه‌ی allowInsecure از تمام کانفیگ‌های JSON مخصوص هسته‌ی Xray (شامل کانفیگ اصلی و Chain Proxy)، چرا که این گزینه به‌طور کامل از تنظیمات TLS هسته‌ی Xray حذف شده است. همراه این تغییر، حداقل نسخه‌ی موردنیاز هسته‌ی Xray در کانفیگ JSON پنل به نسخه‌ی 26.7.28 ارتقاء یافت.

⚠️ توجه: برای بهره‌مند شدن از قابلیت‌ها و امکانات جدید پنل TCB (بخش Observatory Settings و سازگاری کامل با حذف allowInsecure)، کاربران حتما باید از حداقل ورژن 2.3.1 کلاینت v2rayNG که مبتنی بر هسته‌ی Xray ورژن 26.7.28 است استفاده کنند. استفاده از ورژن‌های قدیمی‌تر کلاینت ممکن است باعث بروز خطا در بارگذاری کانفیگ یا عدم سازگاری کامل با تنظیمات جدید شود.

- رفع یک باگ ظاهری در رابط کاربری پنل مربوط به عدم نمایش چک‌باکس Ads در بخش قوانین مسیریابی که به دلیل تداخل با فیلترهای عمومی افزونه‌های AdBlock مرورگرها رخ می‌داد و اکنون کاملا برطرف شده است.

- تمام این تغییرات صرفا در لایه‌ی رابط کاربری، فرمت کانفیگ JSON مخصوص هسته‌ی Xray و سازگاری آن با آخرین نسخه‌های هسته‌ی Xray و کلاینت v2rayNG بوده و هیچ تاثیری روی کد Worker ندارد.

🌐 ابزار آنلاین:
https://4n0nymou3.github.io/tcb/

🔘 گیت‌هاب پروژه و آموزش راه‌اندازی و استفاده:
https://github.com/4n0nymou3/tcb

Anonymous

🟢 آپدیت DoH Proxy - نسخه‌ی Pro

🔘 تغییرات این آپدیت:

✅ از این آپدیت به بعد، پنل DoH Proxy در هر بار بارگذاری، جدیدترین نسخه‌ی کانفیگ Fragment رو بصورت خودکار و مستقیم از ریپازیتوری گیت‌هاب پروژه دریافت و در کادر مربوطه بارگذاری می‌کنه. یعنی دیگه لازم نیست بعد از هر آپدیت کانفیگ Fragment، کد Worker یا Pages رو در کلادفلر جایگزین کنید؛ صرفا کافیه دفعه‌ی بعد که پنل رو باز می‌کنید، نسخه‌ی جدید رو ببینید. جایگزینی کد Worker/Pages فقط در مواقعی لازمه که خود هسته‌ی اصلی DoH Proxy (نه کانفیگ Fragment) آپدیت بشه.

✅ الگوریتم Fragmentation در کانفیگ جدید بازبینی و بهینه‌سازی شد؛ از جمله فعال‌سازی محافظت نویزدهی (Noise) روی کل ترافیک UDP باقی‌مانده (خارج از QUIC که همچنان مسدود می‌مونه).

✅ دامنه‌ها و سرویس‌های بیشتری (از جمله پلتفرم‌های هوش مصنوعی و توسعه‌ی نرم‌افزار) به مسیر اتصال مستقیم اضافه شدن تا این سرویس‌ها با سرعت و تاخیر بهتری بارگذاری بشن.

✅ کانفیگ برای سازگاری با جدیدترین ورژن هسته‌ی Xray یعنی 26.7.28 به‌روزرسانی شد.

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

🔘 نسخه‌های موجود:
✅ Cloudflare Workers
✅ Cloudflare Pages

🟢 برای دریافت کد DoH Proxy جهت استفاده در Cloudflare Workers، فقط کافیه عبارت DoH (دقیقا به همین شکل) رو در ربات ارسال کنید. یا اینکه روی این لینک مستقیم کلیک کنید:

https://t.me/An0nymou3Bot?start=DoH

⚠️ توجه داشته باشید که این آموزش با فرض داشتن یک حداقل دانش فنی تهیه شده.
یعنی فرض من بر اینه که کاربران با مراحل پایه‌ای مثل ساخت حساب کاربری در Cloudflare، ایجاد یک Worker جدید، و قرار دادن این کد در محیط Cloudflare Workers Editor آشنایی اولیه دارن.

برای علاقه‌مندان به دنیای Open Source:

تمامی کدها، مستندات فنی، و آموزش‌های مربوط به راه‌اندازی پروژه‌ی DoH Proxy رو به‌صورت کامل در GitHub منتشر کردم.
این پروژه رو تحت لایسنس MIT ارائه دادم، تا همه بتونن آزادانه ازش استفاده کنن، توسعه‌ش بدن، یا در پروژه‌های خودشون به‌کار ببرن.

https://github.com/4n0nymou3/cloudflare-doh-proxy

Anonymous

درود بر شما
استاد آیا این امکان وجود داره که از متد جدید patterniha در پنل tcb استفاده کنید تا سرعت آپلود کانفیگهای کلودفلر بیشتر بشه؟
ممنون بخاطر همه زحماتتون ❤️🙏

طی یکی دو روز اخیر حدودا پنج تا از دوستان در این خصوص پیام‌های مشابهی دادن که دیگه لازم دونستم در موردش یه مطلب بنویسم:

اول اینکه این تکنیک واقعا یک مکانیزم جدید و اختصاصی از Patterniha نیست؛ ایشون داره از قابلیتی به اسم finalMask استفاده می‌کنه که خود هسته‌ی Xray (ورژن 26.3.27 به بعد) به‌صورت رسمی اضافه کرده. Patterniha فقط این قابلیت رو در UI فورک v2rayNG خودش (که هنوز در v2rayNG اصلی و رسمی پیاده نشده) در دسترس کاربر گذاشته و یک کانفیگ آماده هم براش پیشنهاد داده.

حالا این finalMask چیه؟
قبلا تنظیمات fragment/noise فقط داخل outbound از نوع freedom قابل استفاده بود. در آپدیت اخیر Xray، این‌ها (به‌همراه قابلیت‌های جدیدتری مثل header custom) به یک زیرسیستم مستقل و یکپارچه به اسم finalMask منتقل شدن که می‌تونه روی هر استریم TCP/UDP اعمال بشه و در قالب پارامتر fm در لینک‌های اشتراک‌گذاری هم قابل انتقال باشه. یعنی چیزی که من در worker/TCB اون رو پیاده کردم (همون fragment کردن ClientHello). این هم دقیقا از همون خانواده‌ست، فقط الان زیر یک ساختار رسمی‌تر و گسترده‌تر جمع شده.

کاری که این کانفیگ خاص انجام می‌ده اینه:

1- دو مرحله Fragment زنجیره‌ای (نه یک مرحله)
- مرحله اول (packets: tlshello) دقیقا پکت ClientHelloی TLS رو در بایت‌های 5، 94 و 1 می‌شکنه.
- مرحله دوم (packets: 1-1) روی همون قطعه‌ی اول، یک شکستن دیگه با طول 109 و 1 بایت با تاخیر 1 میلی‌ثانیه و maxSplit=355 انجام می‌ده.
نتیجه: بسته‌ی ClientHello به‌جای یک‌بار، دوبار و در نقاط متفاوت خرد می‌شه. این باعث می‌شه الگوی TLS handshake که DPI/فایروال دنبالش می‌گرده (طول مشخص، ترتیب مشخص بایت‌ها) به‌هم بریزه و تشخیص یا بلاک سخت‌تر بشه. خصوصا روی شبکه‌هایی که محدودیت شدید روی آپلود و هندشیک دارن.

2- اون fingerprint = unsafe + لیست دستی cipherSuites چیه؟
حالت unsafe یعنی Xray به‌جای تقلید از یک اثرانگشت مرورگر واقعی (chrome/firefox/...)، ClientHello رو خودش می‌سازه با هر cipherSuite که بهش بدی. چرا این مهمه؟ چون نقاط شکستن fragment (بایت 5، 94، 109...) دقیقا بر اساس طول واقعی ClientHello حساب شده‌ن. اگه فینگرپرینت مرورگر واقعی استفاده بشه، طول cipherSuites متغیره و offsetها جابه‌جا می‌شن و fragmentation درست کار نمی‌کنه. با ثابت‌کردن یک لیست مشخص cipherSuite، طول ClientHello قابل پیش‌بینی و ثابت می‌مونه، پس نقاط شکستن همیشه دقیق می‌افتن.

3- آدرس IP مستقیم کلادفلر به‌جای دامنه
وارد کردن مستقیم 188.114.97.6 (یکی از IPهای anycast کلادفلر) به‌جای resolve از روی دامنه‌ی Worker، مسیر اتصال رو یکنواخت‌تر و قابل پیش‌بینی‌تر می‌کنه؛ این بیشتر مربوط به دور زدن فیلترینگ سطح DNS/دامنه‌ست تا خود fragmentation.

🔘 پس این روش یک مکانیزم جدید نیست، بلکه نسخه‌ی دقیق‌تر و دو مرحله‌ای همون تکنیک fragmentation که TCB از قبل داشت، به‌علاوه‌ی کنترل دقیق‌تر روی طول ClientHello (از طریق fingerprint=unsafe + cipherSuites ثابت) تا نقاط شکستن همیشه درست بیفتن. دلیل بهبود آپلود روی نت‌های محدودیت‌شدید هم اینه: هندشیک TLS (که جهت آپلود کلاینت < سرور رو مصرف می‌کنه) با این خرد شدن دومرحله‌ای، از فیلترهایی که روی الگوی اندازه/توالی بسته‌های ابتدایی TLS تمرکز دارن راحت‌تر عبور می‌کنه.

طی بررسی‌هایی که دارم در یک فروم روسی انجام میدم، اگه مطمئن بشم این مکانیز قراره بصورت همه‌گیر جا بیوفته، حتما اون رو در پنل TCB پیاده‌سازی می‌کنم.

🟢 آپدیت Tunnel Config Builder (TCB) ورژن 5.3

- اضافه شدن بخش تنظیمات پیشرفته Finalmask به تنظیمات Fragment پنل TCB، مخصوص کاربرانی که با محدودیت شدید در آپلود (خصوصا در اینترنت‌های همراه) مواجه هستند.

🔘 این بخش شامل سه قابلیت جدید است:

1- فعال‌سازی مرحله‌ی دوم قطعه‌بندی (دو لایه): با فعال کردن این گزینه، خروجی مرحله اول Fragment یک‌بار دیگر هم قطعه‌قطعه می‌شود و می‌توانید برای این مرحله هم مقادیر Packets، Interval، Length و Max Split اختصاصی تعریف کنید.

2- استفاده از فینگرپرینت خام به‌جای فینگرپرینت‌های پیشفرض: با فعال کردن این گزینه، هسته‌ی Xray به‌جای تقلید از فینگرپرینت یک مرورگر خاص، یک بسته ClientHello خام و با طول ثابت و قابل پیش‌بینی می‌سازد.

3- امکان وارد کردن Cipher Suites سفارشی و دلخواه.

- همچنین در فیلدهای Fragment Interval و Fragment Length (هم در مرحله‌ی اول و هم در مرحله‌ی دوم) اکنون می‌توانید به‌جای یک رنج ساده، چند مقدار متوالی را با کاما از هم جدا کرده و وارد کنید (مثلا 5,94,1) تا هر قطعه اندازه یا فاصله متفاوتی داشته باشد.

- هدف اصلی این سه قابلیت با هم این است که طول واقعی بسته‌ی ClientHello ثابت و قابل پیش‌بینی بماند تا نقاط شکستن Fragment همیشه دقیق و درست بیفتند؛ همین موضوع باعث بهبود سرعت آپلود در شبکه‌های با محدودیت شدید می‌شود. این تنظیمات فقط روی کانفیگ JSON مخصوص هسته‌ی Xray اعمال می‌شوند و هیچ تاثیری روی کانفیگ‌های Sing-box و Clash ندارند.

⚠️ توجه: برای بهره‌مند شدن از قابلیت تنظیمات پیشرفته Finalmask، کاربران باید از یک کلاینت مبتنی بر آخرین نسخه‌ی هسته‌ی Xray (مثلا v2rayNG ورژن 2.3.2 به بعد) استفاده کنند. استفاده از ورژن‌های قدیمی‌تر کلاینت که این قابلیت را پشتیبانی نمی‌کنند، ممکن است باعث بروز خطا در بارگذاری کانفیگ شود.

- تمام این تغییرات صرفا در لایه‌ی رابط کاربری و فرمت کانفیگ JSON مخصوص هسته‌ی Xray بوده و هیچ تاثیری روی کد Worker ندارد.

🌐 ابزار آنلاین:
https://4n0nymou3.github.io/tcb/

🔘 گیت‌هاب پروژه و آموزش راه‌اندازی و استفاده:
https://github.com/4n0nymou3/tcb

Anonymous

🟢 برای دریافت تنظیمات پیشرفته‌ی Fragment جهت استفاده در پنل TCB، کافیست عبارت TCB (با حروف بزرگ) را برای ربات ارسال کنید یا روی این لینک مستقیم کلیک کنید:

https://t.me/An0nymou3Bot?start=TCB

Fav song 🔒

🚴🏽 🎧 ❤️ ☝🏽

🟢 آپدیت Telegram API Proxy

- افزوده شدن قابلیت دانلود فایل
مسیر جدید /file/bot{TOKEN}/{FILE_PATH} اضافه شد که امکان دریافت مستقیم فایل‌ها (بعد از فراخوانی متد getFile) رو از طریق پروکسی فراهم می‌کنه.

- استریم کردن پاسخ فایل‌ها
برای دانلود فایل، بدنه‌ی پاسخ به‌جای بافر شدن کامل در حافظه، به‌صورت stream عبور داده می‌شه که مصرف حافظه‌ی worker رو برای فایل‌های حجیم به‌شکل قابل‌توجهی کاهش می‌ده.

- سخت‌گیرتر شدن اعتبارسنجی مسیر API
به regex تشخیص مسیرهای /bot{TOKEN}/{METHOD} انتهابند یا anchored شد تا هیچ محتوای اضافه‌ای بعد از نام متد پذیرفته نشه.

- پشتیبانی از توکن‌های URL encode شده
توکن بات حالا در صورت نیاز تا دو مرحله decode می‌شه تا با کلاینت‌هایی که توکن رو encode می‌فرستن هم سازگار باشه.

- تنظیم جداگانه‌ی retry و timeout برای دانلود فایل
درخواست‌های دانلود فایل از timeout طولانی‌تر (مشابه آپلود) برخوردار شدن و منطق retry به‌شکلی اصلاح شد که فقط برای درخواست‌های امن و idempotent فعال باشه.

- حذف هدر Content Security Policy در پاسخ فایل‌ها.

🔘 برای درست کردن Telegram API Proxy شخصی خودتون، از کد worker.js موجود در این ریپازیتوری گیت‌هاب استفاده کنید:

https://github.com/4n0nymou3/Telegram-API-Proxy

🟢 نمونه پنل آماده جهت تست API:

https://anonymous-telegram-api.q39t3.workers.dev/

Anonymous

Being unstoppable means never becoming the thing you fight against.

شکست‌ناپذیر بودن یعنی هرگز تبدیل به همان چیزی نشوی که با آن می‌جنگی.

🟢 آپدیت Clean IP Scanner ورژن 3.6.1

- بهبود در سه ثابت و پنج تابع مربوط به تست تانل جهت بهبود عملکرد اسکن با هسته‌ی Xray.
- نمایش نتایج نهایی اکنون به‌صورت طیف رنگی Gradient بر اساس کیفیت IPها است.
- جدول نمایش ده IP برتر به‌طور کامل بازطراحی شد؛ تا در صفحه‌ی گوشی‌های موبایل داخل Termux، بدون شکستن خط و بیرون‌زدگی از عرض صفحه، به‌درستی نمایش داده شود.

توضیحات دقیق و آموزش نصب و اجرا در ریپازیتوری گیت‌هاب پروژه:

github.com/4n0nymou3/Clean-IP-Scanner

Anonymous

سلام
امروز از اسکنرت روی ترموکس استفاده کردم. عملکردش بد نبود. فقط نمیدونم متوجه باگ پکت لاس اسکن با xray هستی یا نه. همیشه 0 نمایش میده.
البته این باگ روی اسکن معمولی بدون xray نیست و پکت لاس رو واقعی محاسبه میکنه.
اول خواستم pr بزنم خودم برات این باگ رو برطرف کنم اما چون وقتشو ندارم گفتم به خودت بگم شاید بتونی باگو برطرف کنی.

من فعلا پاسخ این دوستمون رو نمیدم.
می‌خوام ببینم کسی می‌تونه علت محاسبه نشدن Packet loss در حالت اسکن با هسته‌ی Xray رو برام بنویسه؟
پاسخ درست رو فوروارد می‌کنم توی کانال :)

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

چقدر دوست داشتم این فیلم ساخته بشه!
پیشنهاد می‌کنم حتما ببینید :)

اگر روزی متوجه شوید که ما تنها نیستیم، اگر آن را به شما نشان دهند و با مدرک ثابت کنند، خواهید ترسید یا خیر؟ فیلم روز افشاگری داستان یک هواشناس و یک متخصص امنیت سایبری است که متحد می‌شوند تا اسرار دولتی مبنی بر وجود بیگانگان را فاش کنند.

👽

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

راستش این قضیه یه دیدگاهی که همیشه توی ذهنم بود رو کاملا تقویت کرد. اونم اینه که اکثر کاربرا طی این سال‌ها که با فیلترینگ و انواع ابزارهای ضدفیلتر سر و کله زدن، بیشتر یه تجربه‌ی دیداری و حسی و حداکثر آشنایی سطحی با چندتا اصطلاح فنی پیدا کردن. اما واقعا نمی‌دونن پشت هر ابزار یا هر خط کد، دقیقا چه اتفاقی داره می‌افته. مثلا چرا Packet Loss توی اسکن با هسته‌ی Xray محاسبه نمی‌شه و فکر می‌کنن این یه باگه :)
یا بسیاری از کاربرا نمی‌دونن زیرساخت خود کلادفلر یه سری قابلیت‌ها رو اصلا ساپورت نمی‌کنه و فکر می‌کنن کار نکردن فلان چیز، از ضعف داخلی کانفیگ فلان پروژه‌ست و...

خب بریم سراغ پاسخ صحیح :)
ببینید دوستان این دو تا حالت Normal و اسکن با هسته‌ی Xray اسکنر، دو چیز کاملا متفاوت رو اندازه می‌گیرن، برای همینه که نمی‌شه انتظار داشت رفتارشون شبیه هم باشه.

توی حالت Normal، اسکنر هر IP رو 4 بار خام و مستقیم روی لایه‌ی TCP پینگ می‌کنه؛ یعنی فقط یه SYN packet ساده، بدون هیچ رمزنگاری یا پروتکل خاصی. چون این یه تست سبک و آماریه، طبیعیه که گاهی از این 4 تا تلاش، یکی‌دو تاش به خاطر نویز لحظه‌ای شبکه جواب نده. همین نوسان می‌شه همون Packet Loss که می‌بینید.

اما توی حالت Xray، اسکنر اصلا packet ساده رد و بدل نمی‌کنه. برای هر IP کاندید، یه نمونه‌ی کامل و مستقل از هسته‌ی Xray رو با همون کانفیگ خود کاربر (VLESS/VMess/Trojan/SS) روشن می‌کنه، صبر می‌کنه پورت SOCKS محلیش بالا بیاد و بعد یه درخواست واقعی HTTPS رو از سر تا ته از دل کل تانل رد می‌کنه؛ یعنی هندشیک TLS، هندشیک پروتکل خود کاربر و پاسخ واقعی سرور، همه باید صد در صد با موفقیت انجام بشه. این یعنی یه تست تک‌مرحله‌ایه سنگین و قطعی (Pass یا Fail) روی کل زنجیره‌ی پروتکل، نه یه بسته‌ی ساده.

حالا چرا این تست فقط یه بار انجام می‌شه، نه 4 بار مثل حالت Normal؟
اول هزینه‌ش: هر بار تکرار این تست یعنی یه بار کامل روشن و خاموش کردن پردازش هسته‌ی Xray، نه فقط فرستادن یه packet. اگه بخوایم این کارو 4 بار برای هر IP کاندید تکرار کنیم، زمان کل اسکن (که همین الانشم روی چند هزار IP انجام می‌شه) عملا 4 برابر می‌شه. روی گوشی و با باتری محدود، این هزینه اصلا منطقی نیست.

دوم، کیفیت سیگنال: یه تست کامل پروتکلی، خیلی قوی‌تر و قابل‌اعتمادتر از یه پینگ خام TCP هست. خیلی از IP‌های کلادفلر هستن که به TCP SYN جواب می‌دن ولی وسط هندشیک TLS یا پروتکل قطع می‌شن. حالت Normal برای فهمیدن این مشکل مجبوره 4 بار پینگ کنه و بعد درصد بگیره؛ ولی حالت Xray چون مستقیما کل زنجیره رو محک می‌زنه، دیگه نیازی به این تخمین آماری نداره. همون یه تست، قطعی‌تر از میانگین 4 تا پینگ سبک‌وزنه.

پس IP‌هایی که از فیلتر حالت Xray رد می‌شن، چون از یه تست سخت‌گیرانه‌تر (پروتکل کامل، نه فقط TCP) عبور کردن، ذاتا کیفیت بالاتری دارن. برای همینه که محاسبه‌ی جداگانه‌ی Packet Loss براشون نه فقط لازم نیست، از نظر فنی هم اصلا معنی نداره؛ چون هر IP‌ای که توی نتایج نهایی می‌بینید، دقیقا همونیه که این تست سنگین رو صد در صد با موفقیت رد کرده. IP‌هایی که رد نشن، اصلا وارد لیست نتایج نمی‌شن، نه اینکه با درصد خطای بالا نمایش داده بشن.

عدد صفر توی ستون Loss حالت Xray، نتیجه‌ی مستقیم و منطقی طراحیشه، نه یه باگ :) اگه بخوایم Packet Loss واقعی رو هم برای این حالت حساب کنیم، باید هزینه‌ی زمانی اسکن رو چند برابر کنیم؛ در حالی که سیگنالی که همین الان از یه تست کامل پروتکل می‌گیریم، عملا دقیق‌تر و قابل‌اعتمادتر از میانگین‌گیری چندتا پینگ خامه.

به هرحال ممنون از اون دوستمون که خواستن این باگ رو برطرف کنن :)) و ممنون از همه‌ی دوستانی که وقت گذاشتن و پاسخ‌هاشون رو در ربات برام ارسال کردن 🙏🏽

Anonymous

این پست رو الان در یکی از کانال‌های تلگرامی دیدم و خیلی تحت تاثیر قرار گرفتم:

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

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

@techno_clan

آخرین پست کانالشون هم در زمینه‌ی رمزنگاری پسا-کوانتومی (PQC) هست.

در همین راستا، خوبه که بدونید این پروژه هم:

https://4n0nymou3.github.io/PassForgeMatrix/

قابلیت تولید پسوردهای مقاوم در برابر کامپیوترهای کوانتومی رو داره.

این یه پروژه‌ی قدیمیه و دلیل ساختش هم این بود که از الگوریتم‌های تولید پسورد ابزارهایی مثل Microsoft authenticator یا Google authenticator یا Bitwarden و... خوشم نمیاد.

یه فهرست شخصی هست که از سال 2023، یعنی از زمان شروع توسعه‌ی Fragment تا رسیدن به FinalMask، در حال تکامل بوده و احتمالا این روند همچنان ادامه خواهد داشت.

امروز صبح گفتم که این فهرست رو به Gemini بدم تا بر اساس اون یه پادکست بسازه ببینم چی تحویل میده.
نتیجه بسیار جالب بود و از شنیدنش لذت بردم.

حتما اینجا هم ارسالش می‌کنم تا ببینید در این سال‌ها چه جنگ سایبری تمام‌عیاری بین ما و سیستم‌های فیلترینگ در جریان بوده :)