VPNهای داوطلبانه و VPNهای تجاری اعتماد را در جاهای متفاوتی می‌گذارند

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

سه طرف، نه یک طرف

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

ترتیب تجاری معمولاً هر سه را در یک شرکت ادغام می‌کند، هرچند ممکن است سرورهایی از یک ارائه‌دهنده میزبانی اجاره کند. بخوانید که ارائه‌دهنده چه چیزی را اداره می‌کند، زیرا عبارت شبکه ما و عبارت سیاست ما می‌توانند سیستم‌های متفاوتی را پوشش دهند. جایی که شریکی دخیل است، سیاست باید نامش را ببرد، وگرنه به ترافیک شما نمی‌رسد.

چگونه یک نقطه پایانی ناپدید می‌شود

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

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

سیاست در واقع چه چیزی را پوشش می‌دهد

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

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

با یک سابقه تصمیم بگیرید، نه با یک برچسب

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

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

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