VpnHood چگونه کار می‌کند
اپلیکیشن VpnHood ترافیک دستگاه را از طریق یک تونل رمزگذاری‌شده به سرور شما می‌فرستد و سرور آن را به اینترنت هدایت می‌کند. در این صفحه مسیر انتقال ترافیک را از ابتدا تا انتها بررسی می‌کنیم.
روی دستگاه کاربر
اپلیکیشن ترافیک دستگاه را از طریق آداپتور شبکه مجازی سیستم دریافت می‌کند. سه نوع ترافیک منتقل می‌شود: TCP، UDP و پینگ. بقیه بسته‌ها حذف می‌شوند.
مدیریت تونل‌زنی تفکیکی نیز روی دستگاه انجام می‌شود. ترافیکی که کاربر استثنا می‌کند (بر اساس اپلیکیشن، کشور، دامنه یا آدرس IP)، مستقیماً به اینترنت رفته و هرگز به سرور شما نمی‌رسد. بخش تونل‌زنی تفکیکی گزینه‌ها را بیشتر توضیح می‌دهد.
اپلیکیشن همچنین DNS دستگاه را تنظیم می‌کند: روی سرورهای انتخابی کاربر در اپلیکیشن یا روی سرور شما که به‌طور پیش‌فرض سرورهای عمومی گوگل است. درخواست‌ها داخل تونل باقی می‌مانند، حتی وقتی تونل‌زنی تفکیکی سایت مربوطه را دور می‌زند.
تونل ارتباطی
به‌طور پیش‌فرض، اپلیکیشن به پورت TCP سرور شما (مگر اینکه تغییرش دهید، 443) از طریق TLS وصل می‌شود؛ همان رمزگذاری امنی که HTTPS به کار می‌برد. ارتباط نیز درست مانند وب‌اپلیکیشن‌ها، در قالب پیام‌های WebSocket انجام می‌گیرد. همه چیز درون تونل از نخستین بایت تا آخرین بایت با TLS کاملاً رمزگذاری می‌شود.
اپلیکیشن پیش از ارسال هر داده‌ای، گواهی سرور شما را بررسی می‌کند. این گواهی یا باید توسط یک مرجع رسمی برای نام موجود در کلید دسترسی صادر شده باشد، یا اثر انگشت (Fingerprint) آن دقیقاً با مقدار ثبت‌شده در کلید مطابقت داشته باشد. به همین دلیل سرور می‌تواند با گواهی خودامضا (Self-signed) شروع به کار کند و هنگام تمدید گواهی معتبر نیز کلیدها همچنان کار خواهند کرد.
در تنظیمات پروتکل اپلیکیشن، کاربر می‌تواند به‌جای TCP گزینه‌های UDP یا QUIC را انتخاب کند. پروتکل UDP بسته‌های دستگاه را به پورت UDP سرور شما در قالب دیتاگرام‌های رمزگذاری‌شده با AES-GCM می‌فرستد. پروتکل QUIC نیز همان پیام‌های TCP را از بستر QUIC (که TLS داخلی دارد) منتقل می‌کند. سرور به هر اپلیکیشن اعلام می‌کند چه پروتکل‌هایی را ارائه می‌دهد، و در صورتی که گزینه انتخابی فعال نباشد (مثلاً در صورت استفاده از Reverse Proxy)، اپلیکیشن از TCP استفاده خواهد کرد. البته اگر شبکه‌ای پورت UDP را ببندد، ترافیک اپلیکیشنِ تنظیم‌شده روی UDP مسدود می‌شود تا زمانی که کاربر آن را دوباره به TCP برگرداند.
هر درخواستی به سرور شما که از سمت یک اپلیکیشن VpnHood نباشد، تنها یک خطای ساده HTTP دریافت می‌کند؛ درست مانند وب‌سایتی که برای ورود به آن به لاگین نیاز است.
TCP: به صورت بسته، یا یک درخواست به ازای هر اتصال
به‌طور پیش‌فرض، اپلیکیشن ترافیک TCP را به‌صورت بسته از طریق تونل می‌فرستد و سرور شما مثل یک روتر آن‌ها را از آداپتور شبکه خود عبور می‌دهد. این روش سریع‌ترین راهکار و کم‌مصرف‌ترین حالت برای باتری است.
در Cloak Mode، اپلیکیشن هر اتصال را روی خود دستگاه پایان می‌دهد و با درخواستی مجزا از سرور شما می‌خواهد آن را باز کند. سرور خودش به وب‌سایت مقصد وصل می‌شود و اطلاعات را به صورت دوطرفه ردوبدل می‌کند. برای ناظران شبکه، این ترافیک دیگر شبیه یک تونل یکپارچه نیست، بلکه مانند درخواست‌های مجزای یک مرورگر به نظر می‌رسد. این کار کمی از سرعت و باتری می‌کاهد، و اپلیکیشن از اتصالِ هر درخواستِ تمام‌شده برای درخواست بعدی دوباره استفاده می‌کند.
اپلیکیشن در شرایط دیگر نیز بدون Cloak Mode به همین شکل کار می‌کند: زمانی که سرور شما آداپتور شبکه اختصاصی ندارد (مانند Docker) و یا هنگامی که کاربر ترافیک را بر اساس دامنه تفکیک کرده باشد.
UDP و ping
ترافیک UDP صرف‌نظر از پروتکلِ انتخابیِ اپلیکیشن، به‌صورت بسته از طریق تونل عبور می‌کند. ping نیز به همین ترتیب منتقل می‌شود، ولی سایر پکت‌های ICMP رد می‌شوند و تنها Echo Request عبور می‌یابد. سرور شما هر دو را از طریق آداپتور شبکه خود می‌فرستد، یا اگر آداپتور نداشته باشد، با ایجاد سوکت‌های اختصاصی، عمل ping را از طرف دستگاه انجام می‌دهد.
سمت سرور
با نصب روی Linux، نرم‌افزار VpnHood! SERVER آداپتور شبکه اختصاصی خود را دارد و مانند یک روتر با NAT بسته‌ها را به اینترنت هدایت می‌کند. کانتینر Docker چنین آداپتوری ندارد؛ از این رو سرور در آنجا مانند یک پروکسی عمل می‌کند: اپلیکیشن‌ها ترافیک TCP را برای هر درخواست در یک اتصال می‌فرستند و سرور خودش هر اتصال، سوکت UDP و ping را باز می‌کند. اپلیکیشن‌ها به صورت خودکار به این حالت سوییچ می‌کنند.
در هر دو روش، سرور هرگز ترافیک را به آدرس‌های خود یا شبکه‌های محلی که روی آن قرار دارد عبور نمی‌دهد.
سرور نیاز دارد پورت TCP باز باشد، و همچنین پورت UDP که در نخستین راه‌اندازی برای اپلیکیشن‌هایِ روی وضعیت UDP در نظر گرفته شده است. QUIC تا زمان فعال‌سازی خاموش می‌ماند. راهنمای تنظیم آدرس‌های IP سرور نحوه مشاهده پورت UDP را توضیح می‌دهد.
یک سرورِ مدیریت‌شده از طریق HTTPS در access.vpnhood.com با VpnHood! MANAGER ارتباط برقرار می‌کند تا هنگام اتصال هر اپلیکیشن، کلید را بسنجد و میزان مصرف را گزارش دهد. نرم‌افزار MANAGER هرگز مستقیماً به سرور متصل نمی‌شود و اپلیکیشن‌ها نیز هرگز با MANAGER گفتگو نمی‌کنند. علاوه بر این، MANAGER می‌تواند کاربر را به سرور دیگری در مجموعه سرورها هدایت کند. یک سرور مستقل (Standalone)، کلیدها را از روی فایل‌های محلی خود اعتبارسنجی می‌کند.
محتویات کلید دسترسی
یک کلید دسترسی حاوی اطلاعاتی است که اپلیکیشن برای شناسایی و اعتماد به سرور شما نیاز دارد: نام دامنه و نشانی‌ها، پورت، نام یا اثر انگشت گواهی، و رمز اختصاصیِ خود کلید. این اطلاعات انکود شده‌اند، نه رمزگذاری؛ یعنی هر کسی کلید را داشته باشد می‌تواند نشانی‌های سرور را در آن ببیند و متصل شود. کلیدها را فقط در اختیار کاربران خود بگذارید، و صفحه جلوگیری از مسدود شدن IP سرور را بخوانید تا بدانید اپراتورها با نشانی‌های شناسایی‌شده چه می‌کنند.
