ادعاهای قابل‌تأیید.

رمز فقط برای بازکردن نخستین اتصال SSH و نصب یک کاربر سرویس لازم است. به‌عنوان احراز هویت SSH برای اتصال ما فرستاده می‌شود — نه به‌عنوان آرگومان اسکریپت یا متغیر محیطی. پایگاه‌داده ما فیلدی برای آن ندارد؛ وارد محیط‌های اجرای اسکریپت نمی‌شود و در لاگ‌ها نوشته نمی‌شود (خطاهای اتصال فقط شامل آدرس و پورت هستند، هرگز رمز). در حافظه پس از استفاده پاک می‌شود (تا حد امکان) — این دفاعِ لایه‌لایه است، نه یک تضمین: Go ممکن است تا زمان جمع‌آوری زباله، نسخه‌هایی از این مقدار را روی heap نگه دارد.

ملاحظه صادقانه: این همچنان رمز root روی سرور شماست. پس از نصب، ورود با رمز و ورود root از طریق SSH را غیرفعال می‌کنیم، اما خودِ رمز را تغییر نمی‌دهیم — اگر خواستید خودتان آن را عوض کنید. «ما آن را ذخیره نمی‌کنیم» درست است؛ «دیگر یک راز نیست» درست نیست.

PasswordAuthentication no، PermitRootLogin no، انتقال SSH به یک پورت غیراستاندارد (به‌طور پیش‌فرض 12011)، فعال‌بودن fail2ban (یک ساعت مسدودسازی پس از ۵ تلاش ناموفق)، ورود فقط با کلید. کلید عمومی پیش از استفاده به‌شکل سخت‌گیرانه اعتبارسنجی می‌شود: خطوط جدید (محافظت در برابر سُر دادنِ کلیدهای اضافی به authorized_keys) و کلیدهای نامعتبر از نظر نحوی رد می‌شوند.

ضدِ قفل‌شدن: پورت 22 بسته نمی‌شود تا زمانی که کرنل (از طریق ss) تأیید کند که پورت جدید SSH واقعاً در حال شنیدن است؛ پیکربندی با sshd -t و قاعده sudo با visudo -cf بررسی می‌شود و هر دو در صورت خطا بازگردانده می‌شوند.

پنل نه با رمز شما، بلکه با یک کلید جداگانه (ed25519) کار می‌کند که خودش تولید می‌کند. بخش خصوصیِ آن در پایگاه‌داده به‌صورت رمزگذاری‌شده با AES-256-GCM قرار دارد. کلید رمزگذاری (KEK) جدا از پایگاه‌داده نگهداری می‌شود — در یک متغیر محیطیِ سرور — و در محیط تولید اجباری است (هیچ پیش‌فرضِ ناامنی وجود ندارد: بدون KEK زیرسیستم رمزنگاری اصلاً راه نمی‌افتد). همین رمزگذاری از رازهای سنگین در پایگاه‌داده محافظت می‌کند — رمز/توکن/JWT مدیر Marzban، کلیدهای Reality، کلیدهای ارائه‌دهنده پرداخت، کشِ اعتبارنامه پروکسی، پیکربندی پشتیبان.

رمزگذاری نه‌تنها پنهان می‌کند بلکه داده را احراز هویت می‌کند (برچسب احرازِ GCM): دستکاریِ یک فیلد رمزگذاری‌شده هنگام رمزگشایی تشخیص داده و رد می‌شود. هر فیلد با یک nonce تصادفیِ تازه رمزگذاری می‌شود؛ مقدار KEK هرگز به لاگ‌ها نمی‌رسد — فقط شناسه کوتاه آن.

درباره توکن‌های قابلیت: توکن اشتراک /sub یک رازِ حامل است. برای جست‌وجو فقط SHA-256 آن را ذخیره می‌کنیم، در حالی که نسخه‌ی لازم برای نمایش دوباره‌ی لینکِ پیش‌تر صادرشده به‌صورت متن‌رمزِ AES-GCM نگه داشته می‌شود. رکوردهای متن‌ساده قدیمی‌تر پیش از راه‌اندازیِ سرور HTTP، به‌شکل fail-closed به قالب جدید مهاجرت داده می‌شوند. شناسه URL وب‌هوکِ پرداخت به‌صورت آشکار ذخیره می‌شود اما به‌تنهایی یک رویداد را احراز هویت نمی‌کند: اصالت جداگانه با یک امضای HMAC تأیید می‌شود.

کلید فقط روی سرور و در حافظه رمزگشایی می‌شود؛ APIهای معمولی هرگز آن را برنمی‌گردانند. تنها راه به‌دست‌آوردنش یک تابع اکسپورتِ عمدی است («کلیدت را بردار»)، که با ورود به‌همراه یک کد یک‌بارمصرفِ ایمیلی محافظت می‌شود (کد فقط به‌صورت هش HMAC ذخیره می‌شود، در زمان ثابت مقایسه می‌شود، TTL ده‌دقیقه‌ای، ۵ تلاش). بنابراین کلید را می‌توان عمداً بازیابی کرد، اما نمی‌توان از طریق یک درخواست عادی «لو» داد.

پیش از تغییر وضعیت سرور و پیش از هر عملیات شبکه‌ای در پس‌زمینه، فیلدهای نگهدارنده‌ی کلید مدیریت به‌صورت همگام صفر می‌شوند. اگر پایگاه‌داده پاک‌شدن را تأیید نکند، عملیات یک خطا برمی‌گرداند و می‌توان دوباره تلاش کرد. حذف «نرم» باقی می‌ماند: ردیف و داده‌های غیرمحرمانه‌ی سرویس حفظ می‌شوند. این به معنای پاک‌شدن فیزیکیِ پشتیبان‌های ازپیش‌ساخته‌شده نیست — چرخه عمر آن‌ها را سیاست نگهداری پشتیبان تعیین می‌کند.

مسیرهای شریکِ ممیزی‌شده بر اساس partner_id مجوز می‌دهند، که سرور آن را از توکن ورودِ امضاشده استخراج می‌کند — نه از آنچه کلاینت در مسیر یا بدنه فرستاده. پیش از برگرداندن یا تغییر هر چیزی، سیستم دوباره بررسی می‌کند که سرور، کلاستر، اینباند، مسیر، کاربر VPN یا پرداختِ درخواستی به حساب شما تعلق دارد؛ کوئری‌های متناظرِ پایگاه‌داده با partner_id شما محدود می‌شوند، و شِما (کلیدهای یکتای ترکیبی به‌همراه کلیدهای خارجیِ ترکیبی) پیوندهای نامعتبرِ میان‌شریکی را رد می‌کند. جداسازی لایه‌لایه است: اپلیکیشن، بازبینیِ دوباره در usecase، یک فیلترِ partner_id، و شِما.

ملاحظه صادقانه: این با یک ممیزیِ کد در طول مسیر درخواست تأیید شده، نه با یک تست نفوذِ عمومی — بنابراین SR-16، مانند بقیه، در باگ‌باونتی برای رد‌شدن باز است.

برای پیکربندی خودکارِ همه‌چیز (نصب Xray+Reality، اعمال پیکربندی، خواندن سنجه‌ها) پنل دسترسیِ کاملِ مدیریتی روی سرور دارد (معادلِ root، از طریق یک کاربر سرویس با sudo بدون رمز). این برای مدیریت لازم است، و ما آن را «محدود» نمی‌نامیم.

آنچه ریسک را کاهش می‌دهد: رازها فقط از طریق stdin فرایند به سرور فرستاده می‌شوند (نه به‌عنوان آرگومان دستور — در فهرست فرایندها دیده نمی‌شوند)؛ پس از نصب اولیه، هر اتصال مدیریتی کلید میزبانِ پین‌شده‌ی سرور را تأیید می‌کند — جابه‌جاییِ «وسطِ راهِ» سرور رد می‌شود. آنچه شما کنترل می‌کنید: دسترسی بر پایه‌ی کلیدی است که هر زمان می‌توانید باطلش کنید — با حذف سرور (کلید صفر می‌شود) یا صرفاً حذف VPS نزد میزبان خودتان (آنگاه همه‌چیز ناپدید می‌شود).

خودِ حساب‌های VPN (VLESS/Reality) در Marzban روی سرور مسترِ شما ساخته می‌شوند و آنجا قرار دارند. به‌صورت متمرکز فقط چیزی را ذخیره می‌کنیم که برای صدور یک لینک اشتراک لازم است: یک توکن اشتراکِ تصادفی و یک عکس‌فوریِ رمزگذاری‌شده از اعتبارنامه‌های پروکسی (یک کش؛ منبعِ حقیقت، Marzban شماست). ما هیچ تاریخچه‌ی ترافیک، IP یا بازدید کاربر نداریم.

در اینجا فهرستی صادقانه از جاهایی می‌آوریم که ایمیل کاربر نهایی واقعاً از پایگاه دادهٔ مرکزی ما عبور می‌کند: ایمیل حاوی کد ورود را ما ارسال می‌کنیم، پس آدرس از صف ارسال ما عبور می‌کند (برای هر ورودی به ویترین، از جمله ورود رایگان)؛ هنگام پرداخت، ایمیل خریدار در webhook پرداخت می‌رسد و وارد گزارش پرداخت‌ها می‌شود؛ هنگام اتصال Telegram، ایمیل در پروفایل ذخیره می‌شود. اینها تنها نقاط تماس هستند — خدماتی و از سرِ ضرورت؛ به ترافیک یا رفتار کاربران مربوط نمی‌شوند.

این داده‌های سرویسی را تنها تا زمانی که لازم است نگه می‌داریم و به‌طور خودکار پاک می‌کنیم: ایمیل بلافاصله پس از ارسال از صف ارسال حذف می‌شود، بدنهٔ یک رویداد پرداخت پس از پردازش، و رویدادهای در انتظار تلاش مجدد تا یک بازهٔ ۹۰روزه. می‌توانید با تماس با پشتیبانی، حساب خود را همراه با داده‌های مرتبط با آن حذف کنید (برای جزئیات، خطر ۷ را ببینید). ما این را صادقانه افشا می‌کنیم، نه اینکه پشت عبارات مبهم پنهانش کنیم.

پلتفرم CreateYourVPN اطلاعاتی درباره‌ی اینکه شما یا کاربرانتان چه سایت‌هایی را باز می‌کنید دریافت یا ذخیره نمی‌کند. شمای دریافتِ سنجه‌ها بسته است: از نظر فیزیکی هیچ فیلدی برای IP، دامنه یا بازدید ندارد — فقط تجمیع‌ها (شمار یکتای آنلاین، مجموع بایت‌ها، CPU/RAM/بار). هر نود با یک توکن HMAC که به شناسه خودش گره خورده احراز هویت می‌شود و فقط برای خودش می‌تواند سنجه بنویسد. متعادل‌کننده‌ی روی نود (HAProxy) به‌عنوان یک مسیریابِ TCP بر اساس SNI کار می‌کند و ترافیک را رمزگشایی نمی‌کند. روی خودِ سرور، ژورنال‌های سیستم بیش از حدود یک ساعت نگه داشته نمی‌شوند و به syslog ارسال نمی‌شوند.

فراتر از سطح پلتفرم، سرورها نیز هیچ دفترِ بازدیدی نگه نمی‌دارند: لاگ‌گیریِ دسترسیِ Xray در هر بار اعمالِ پیکربندی به‌اجبار خاموش می‌شود (پلتفرم log.access را روی none تنظیم می‌کند)، بنابراین پراکسیِ لبه ثبت نمی‌کند که کاربران به چه نشانی‌هایی متصل می‌شوند. این در کد اِعمال شده و روی کل ناوگان مستقر گردیده است.

برای درکِ نحوه‌ی استفاده از سایت و پنل، Google Analytics را به‌کار می‌گیریم (بنر کوکی درباره‌ی جمع‌آوری کوکی و آمار هشدار می‌دهد؛ جزئیات در سیاست حفظ حریم خصوصی است). هیچ ردیاب شخص ثالث دیگری وجود ندارد: نه Sentry، نه PostHog، نه Mixpanel و نه پیکسل‌های تبلیغاتی (با جست‌وجو در هر دو فرانت‌اند تأیید شده). بک‌اند هیچ تله‌متریِ شخص ثالثی ندارد. فروشگاه کاربر نهایی به‌هیچ‌وجه تحت پوشش تحلیل نیست — نه GA، نه ردیاب (از منابع آن قابل‌تأیید است).

ملاحظه: GA آی‌پی شما (در سمت Google) و آدرس‌های صفحات پنلِ بازدیدشده را دریافت می‌کند؛ URLهای پنل فقط شناسه‌ی یک کلاستر را در بر دارند، نه ایمیل.

پرداخت و همه‌ی داده‌های کارت در سمت ارائه‌دهنده مدیریت می‌شوند (Tribute / Lemon Squeezy). ما فقط یک وب‌هوکِ امضاشده دریافت می‌کنیم (HMAC-SHA256، مقایسه در زمان ثابت، که پیش از تجزیه‌ی بدنه و پیش از هر نوشتن در پایگاه‌داده تأیید می‌شود: بدون دانستنِ راز، یک رویداد در تأیید مردود می‌شود). ما شماره‌ی کامل کارت (PAN) یا CVV را دریافت نمی‌کنیم. ارسال دوباره‌ی همان وب‌هوک (تلاش‌های مجدد ارائه‌دهنده) باعث اعطای دوباره نمی‌شود — رویدادها حذف‌تکراری می‌شوند.

ملاحظه: ارائه‌دهنده ممکن است فراداده‌ی کارت (برند و ۴ رقم آخر) و نام و ایمیل پرداخت‌کننده را در بدنه‌ی وب‌هوک بگنجاند. بدنه‌ی اصلی تا پایان پردازش برای کارگر لازم است؛ پس از پردازش موفق، همراه با نشانه‌ی ایمیل حذف می‌شود. رویدادهای در انتظار تلاش مجدد یا بازبینی دستی بدنه‌ی اصلی را تنها تا پایان پنجره‌ی نگهداری (90 روز بدون فعالیت) نگه می‌دارند، که پس از آن فراداده‌ی کارت و ایمیل پرداخت‌کننده به‌طور خودکار پاک می‌شوند. «شماره‌ی کامل کارت وجود ندارد» درست است، اما این ویژگیِ ارائه‌دهنده‌هاست (ما خودمان بدنه را فیلتر نمی‌کنیم)؛ «ما اصلاً چیزی درباره‌ی کارت نمی‌بینیم» درست نیست.

ایمیل (برای ورود لازم است)، زمان آخرین ورود، حالت رابط؛ برای صورت‌حساب — موجودی و تلگرام (برای شارژ). آی‌پی شریک در پایگاه‌داده ذخیره نمی‌شود، و ما هیچ تاریخچه‌ی کلیک یا کنش در پنل نگه نمی‌داریم (جز یک لاگ دسترسیِ کوتاه هنگام خطاها).

دیوار آتش به‌طور پیش‌فرض ورودی را رد می‌کند. باز به سمت بیرون: 443 (VPN، Xray+Reality)، SSH روی یک پورت غیراستاندارد (به‌طور پیش‌فرض 12011)، و — روی سرور مستر — پورتِ پنل مدیر Marzban، فقط برای IPهای control-plane. پورت 80 جداگانه و فقط در حالت Let's Encrypt برای HTTP-01 باز می‌شود. پورت 22 پس از جابه‌جاییِ SSH بسته می‌شود.

پورت‌های مدیریتیِ نود فقط به آی‌پی سرور مستر باز هستند، نه به بیرون (شکستِ این محدودسازی نصب را متوقف می‌کند). اگر دیوار آتش فعال نشود، نصب شکست می‌خورد. ICMP echo فقط برای IPv4 محدود می‌شود؛ ما وعده نمی‌دهیم که سرور «نامرئی» است، و ICMP مربوط به IPv6 برای درست‌کارکردنِ IPv6 حفظ می‌شود.

ارتقاهای بدون‌نظارت، به‌روزرسانی‌های بسته‌های امنیتی را خودکار نصب می‌کنند. ملاحظه: راه‌اندازی مجددِ خودکار عمداً غیرفعال شده (تا یک کرنلِ تأییدنشده خودبه‌خود راه‌اندازی مجدد نشود) — یعنی اصلاحاتی که به راه‌اندازی مجدد نیاز دارند (کرنل، گاهی OpenSSH) فقط پس از یک راه‌اندازی مجددِ دستی یا زمان‌بندی‌شده اعمال می‌شوند. «وصله‌گذاریِ خودکار» برای فضای کاربر درست است، نه برای آنچه به راه‌اندازی مجدد نیاز دارد.

ما ادعا نمی‌کنیم که سرور «نامرئی» است یا «نمی‌توان اسکنش کرد». پورت 443 باز است و مانند هر وب‌سروری به یک اتصال TCP پاسخ می‌دهد. ویژگیِ «در یک اتصال نادرست، شبیه یک وب‌سایتِ عادیِ بی‌ربط به نظر می‌رسد» را پروتکل Reality درون Xray فراهم می‌کند — یک مؤلفه‌ی جداگانه که آن را به یک حرف مطلق تبدیل نمی‌کنیم.

ورود شریک با یک کد یک‌بارمصرفِ ۶ رقمی است که به ایمیل فرستاده می‌شود. حساب رمز ندارد. این شامل اعتبارنامه‌های داخلیِ مؤلفه‌های مدیریت‌شده — مانند رمز مدیرِ تولیدشده‌ی Marzban — نمی‌شود. کدها با یک تولیدکننده‌ی رمزنگاری تولید می‌شوند؛ فقط هش HMAC آن‌ها ذخیره می‌شود، و مقایسه در زمان ثابت است. کد یک‌بارمصرف است: در صورت موفقیت بلافاصله حذف می‌شود (بدون بازپخش)؛ پس از ۵ تلاش نادرست زودتر خاموش می‌شود. محدودیت نرخِ صدور بر اساس هر ایمیل شمرده می‌شود، نه هر IP — با عوض‌کردن آدرس نمی‌توان دورش زد.

توکن نشست در یک کوکیِ HttpOnly و Secure قرار دارد (JS نمی‌تواند آن را بخواند)، و در بک‌اند تأیید می‌شود (نه فقط در لبه). مهلت بی‌کاری و خروج خودکار هنگام بی‌فعالیتی در کلاینت پیاده شده‌اند، نه در سرور. توکن با HS256 امضا می‌شود؛ هنگام تأیید، هر الگوریتم دیگری (از جمله «none») را به‌شکل سخت‌گیرانه رد می‌کنیم — حمله‌ی کلاسیکِ جابه‌جاییِ الگوریتم عبور نمی‌کند. توکن فروشگاه و توکن پنل شریک بر اساس مخاطب جدا می‌شوند: یک توکنِ کاربر نهایی از نظر فنی نمی‌تواند به API شریک برسد (و برعکس). یک شریکِ حذف‌شده حتی با یک توکن زنده رد می‌شود.

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

هیچ توکنی در حافظه‌ی محلیِ مرورگر وجود ندارد (فقط تنظیمات رابط)؛ هیچ رازی و آدرس API وارد بسته‌ی کلاینت نمی‌شود. فقط سرور (Next.js) توکن را در یک کوکیِ HttpOnly قرار می‌دهد. مرورگر فقط از طریق سرور (Server Actions) با هسته صحبت می‌کند: فرانت‌اند API را مستقیماً از مرورگر فرا نمی‌خواند، و CORS اجازه نمی‌دهد مرورگر پاسخ‌های API را از مبداهای دیگر بخواند.

توضیح به‌جای یک حرفِ مطلقِ پیشین: خودِ دامنه‌ی API یک میزبان عمومی است — از نظر فنی می‌توانید آن را از یک مرورگر باز کنید، اما بدون یک نشست هیچ داده‌ی محافظت‌شده‌ای را برنمی‌گرداند.

دامنه‌های عمومی CreateYourVPN از طریق HTTPS با HSTS (با max-age دو سال و includeSubDomains) ارائه می‌شوند. هم فرانت‌اند وب و هم دامنهٔ API مجموعه‌ای سختگیرانه از هدرهای امنیتی را ارسال می‌کنند: یک Content-Security-Policy محدودکننده، X-Content-Type-Options: nosniff، X-Frame-Options و یک Referrer-Policy قفل‌شده (no-referrer روی API؛ strict-origin-when-cross-origin روی فرانت‌اند که یک Permissions-Policy محدودکننده نیز ارسال می‌کند).

این در پرو‌داکشن روی هر دو دامنه کار می‌کند و به‌طور مستقل قابل بررسی است — با هر ابزار بازرسی هدرهای HTTP یا سرویسی مانند SSL Labs.