رمزنگاری VLESS
رمزنگاری VLESS (VLESS Encryption) خود جریان VLESS را رمزنگاری می‌کند، درون TLS یا اصلاً بدون TLS. یک کلید روی یک اینباند VLESS است، و فقط اپ‌های مبتنی بر Xray و اپ‌های Clash جدید آن را می‌خوانند.
چه چیزی اضافه می‌کند
- حریم خصوصی فراتر از CDN. پشت یک فرانت دامنه، CDN پایانه‌ی TLS است و می‌تواند آنچه را از آن می‌گذرد بخواند. با رمزنگاری VLESS روشن، به‌جای ترافیک VLESS کاربرهایتان متن رمزشده می‌بیند.
- یک تبادل کلید پساکوانتومی روی هر اتصال (ML-KEM-768 همراه با X25519)، چه TLS دورش باشد چه نباشد.
- VLESS بدون TLS که اپ‌ها می‌پذیرند. اپ‌های امروزی مبتنی بر Xray، VLESS ساده بدون TLS و بدون REALITY را رد می‌کنند؛ با رمزنگاری VLESS روشن، همان اینباند پذیرفته می‌شود.
روشن کردن آن
اینباند VLESS را باز کنید (اینباندها، سپس دکمه‌ی ویرایش ردیف)، یا یکی بسازید. ببینید اینباندها.
روی زبانه‌ی Protocol، رمزنگاری VLESS را پیدا کنید و یک احراز هویت انتخاب کنید:
- X25519 (غیرپساکوانتومی)، یا
- ML-KEM-768 (پساکوانتومی).
این کلیدی است که هویت سرور را ثابت می‌کند. یکی را انتخاب کنید؛ تبادل درون هر اتصال در هر دو حالت پساکوانتومی است.
ذخیره کنید. پنل کلید را می‌سازد، نیمه‌ی سرور را روی اینباند نگه می‌دارد، آن را برای نود می‌فرستد، و نیمه‌ی کلاینت را در هر لینک و فایل اشتراک می‌گذارد.
| فیلد | |
|---|---|
| حالت | native، xorpub یا random: چه مقدار از handshake پوشانده شود. هزینه‌ی هر سه یکی است |
| عمر بلیت | چند ثانیه کلاینت می‌تواند بدون handshake کامل دوباره وصل شود. 0 هر اتصال را یک handshake کامل می‌کند |
| رشتهٔ سرور | نیمه‌ی خصوصی. روی اینباند نگه داشته و برای نود فرستاده می‌شود، هرگز در لینک قرار نمی‌گیرد. تولید کلید جدید آن را عوض می‌کند |
| رشتهٔ کلاینت | از رشته‌ی سرور به دست می‌آید و از قبل در هر لینک هست. برای کلاینتی نمایش داده می‌شود که دستی راه می‌اندازید |
همه‌ی لینک‌ها را از نو صادر می‌کند
لینکی که پیش از روشن کردن آن، یا پیش از تغییر احراز هویت یا کلید، ساخته شده در handshake رد می‌شود. آن را پیش از اینکه مشتری‌ها اینباند را وارد کنند تنظیم کنید، یا برای این برنامه بریزید که همه‌ی کاربرهای اینباند اشتراکشان را تازه کنند. همین قاعده درباره‌ی فیلدهای پیشرفته‌ی XHTTP هم صدق می‌کند.
کدام اپ‌ها می‌توانند از آن استفاده کنند
| اپ‌ها | |
|---|---|
| اپ‌های مبتنی بر Xray (v2rayNG، v2rayN، Streisand، Happ) | بله، به‌طور کامل |
| اپ‌های Clash روی mihomo 1.19.14 یا بالاتر | بله |
| اپ‌های sing-box (SFA، Karing، NekoBox) | خیر. اشتراکشان اینباند را کنار می‌گذارد |
چون اپ‌های sing-box نمی‌توانند از اینباند رمزشده استفاده کنند، برای کاربرهای این اپ‌ها یک اینباند دیگر در همان قالب نگه دارید.
فلوی vision کنار گذاشته می‌شود
xtls-rprx-vision روی اینباند رمزشده کار نمی‌کند، پس پنل آن را آنجا کنار می‌گذارد، هم روی نود و هم در لینک‌ها. کاربرهایی که Flow (وی‌لس) روی حسابشان تنظیم شده آن را برای اینباندهای VLESS دیگرتان نگه می‌دارند؛ لازم نیست چیزی روی کاربر تغییر کند.
کی از آن استفاده کنیم
- اینباند VLESS پشت CDN (WebSocket، gRPC، HTTPUpgrade یا XHTTP با فرانت): دلیل اصلی روشن کردنش.
- اینباند VLESS بدون TLS، مثلاً پشت CDNای که با نود شما HTTP ساده حرف می‌زند.
روی اینباند REALITY بیشتر همان تبادل پساکوانتومی را اضافه می‌کند، به بهای از دست دادن همه‌ی کاربرهای اپ‌های sing-box روی آن اینباند. پیش از روشن کردنش آنجا، این را بسنجید.
مرتبط
- XHTTP: ترنسپورتی که بیشتر از همه با آن جفت می‌شود
- دامین فرانتینگ: بردن یک اینباند پشت CDN
- VLESS با REALITY: فلوی vision و REALITY