چرا یک فهرست VPN نمی‌تواند ضامن گره‌ای باشد که پشت آن است
یک مدخل هم اتصال را توصیف می‌کند و هم فهرستی را که آن را منتشر کرده است. گردآوری و نگهداری به اپراتور تعلق دارد که می‌تواند طرف دیگری باشد.
مدخل‌های فهرستی که یک نام میزبان، یک کشور و مجموعه‌ای از پروتکل‌ها را فهرست می‌کنند، شواهدی درباره اتصال‌پذیری‌اند، نه درباره آنچه ماشین طرف دیگر ثبت می‌کند. تصمیم مهم اینجا این نیست که آیا به فهرست‌ها به‌طور کلی اعتماد کنیم. بلکه این است که کدام طرف در موقعیتی است که به پرسشی که واقعاً می‌پرسید پاسخ دهد.
چهار طرف پشت یک مدخل
پیش از خواندن هر وعده‌ای نقش‌ها را جدا کنید. فهرست مدخل را منتشر می‌کند، پروژه نرم‌افزاری پیاده‌سازی پروتکل را فراهم می‌کند، ارائه‌دهنده میزبانی ماشین و شبکه را فراهم می‌کند، و اپراتور گره سرویس را پیکربندی می‌کند. هر یک از این چهار می‌تواند سازمانی متفاوت باشد، و هر کدام تنها می‌تواند از بخش خودش سخن بگوید.
این تفکیک توضیح می‌دهد که چرا یک گزاره می‌تواند درست و در همان حال بی‌فایده باشد. توسعه‌دهنده‌ای که مستند می‌کند پروتکل محتوا را ثبت نمی‌کند، چیزی درباره اپراتوری نمی‌گوید که ثبت دقیق اتصال‌ها را روی یک رله روشن کرده است. هر دو گزاره می‌توانند بی‌هیچ تناقضی کنار هم بمانند. دقیقاً به همین دلیل پرسش باید به طرفی نام‌برده شود.
برخی سرویس‌ها نقطه‌های پایانی خود را خودشان اداره می‌کنند و آنگاه مدخل و سیاست از یک طرف می‌آیند. این جایگاه قوی‌تری است، اما هنوز باید اثبات شود، نه از قالب صفحه حدس زده شود. بیان‌نامه را بخواهید و بررسی کنید که سرویسی را که مدخل به آن اشاره دارد نام می‌برد.
سندی را بخواهید که با ادعا می‌خواند
ادعایی درباره گردآوری به سندی نیاز دارد که سامانه، دسته داده و دوره را نام ببرد. ادعایی درباره نگهداری به یک عدد و یک دامنه نیاز دارد. ادعایی درباره استقلال به توصیف اینکه چه کسی مالک چیست نیاز دارد، نه به یک صفت.
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
پروژه‌های داوطلبانه اغلب روشن‌ترین نمونه‌اند، چون برخی الزامات صریح ثبت گزارش را برای گره‌هایی که می‌پذیرند منتشر می‌کنند. آن سند شواهد اولیه‌ای درباره قواعد پروژه است و هنوز شواهدی درباره اپراتور فردی که آن‌ها را نادیده گرفته نیست.
ممیزی‌ها همان منطق را در مقیاسی دیگر دنبال می‌کنند. گزارشی که یک استقرار مشخص را در بازه‌ای مشخص بررسی کرده در همان مرز سودمند است. اگر به هر نسخه مستقل همان نرم‌افزار گسترده شود، به تضمینی تبدیل می‌شود که هیچ‌کس صادر نکرده است. پیش از خواندن نتیجه، بند دامنه را بخوانید.
وقتی بیانیه حریم خصوصی یک فروشنده سرویس خودش را پوشش می‌دهد، آن را به‌عنوان بیانیه همان فروشنده درباره سامانه‌های خودش بخوانید. استفاده دوباره از آن برای توصیف رله‌ای از طرف سوم خطای دسته‌بندی است، حتی وقتی پروتکل یکسان است.
تصمیم بگیرید با هر گزینه چه می‌خرید
گره عمومی دسترس‌پذیری و تنوع را به بهای پاسخ‌گویی می‌خرد. اپراتوری که هیچ به شما بدهکار نیست می‌تواند ناپدید شود، پیکربندی را تغییر دهد یا بدون اطلاع سوابق را نگه دارد، و راه چاره شما محدود است به عوض کردن نقطه‌های پایانی. این معاوضه برای برخی کارها پذیرفتنی است و برای برخی نه.
سرویس پرداختی یک طرف مقابل با سیاست منتشرشده و چیزی برای از دست دادن می‌خرد. تضمین فنی نمی‌خرد و نیاز به خواندن سیاست را برنمی‌دارد، اما سازمانی نام‌برده با بیانیه نگهداری آسان‌تر از یک رله بی‌نام ارزیابی می‌شود.
قاعده تصمیمی که در هر دو حالت دوام می‌آورد این است که شواهد را با ریسک منطبق کنید. اگر کار نقطه پایانی چرخشی را تحمل می‌کند، فهرست ابزاری کارآمد است. اگر به وعده مشخصی درباره پردازش داده وابسته است، تنها طرفی که می‌تواند آن وعده را بدهد اهمیت دارد، و فهرست یک سهولت مسیریابی است، نه یک تضمین.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'دستور بالا ارزش اجرا دارد چون دو پرسش را به‌تمیزی جدا می‌کند. نشانی‌ای را نشان می‌دهد که ترافیک شما واقعاً به کار برده است، که این خود واقعیتی درباره اتصال‌پذیری است، و چیزی درباره اینکه اپراتور آن نشانی با فراداده اتصال چه کرده نمی‌گوید.
پرسش‌های سمت مشتری را جدا نگه دارید
سیاست اپراتور یک لایه است، و امنیت کاری که از تونل انجام می‌دهید لایه‌ای دیگر. HTTPS در مقصد، مدیریت نشست در مرورگر و استحکام حسابی که با آن وارد شدید از کنترل‌های شما می‌مانند، و رله آسان‌گیر آن‌ها را ضعیف نمی‌کند همان‌گونه که رله عالی آن‌ها را تقویت نمی‌کند.
این تفکیک از دو اشتباه رایج پیشگیری می‌کند. یکی دانستن سیاست سخت‌گیرانه اپراتور به‌عنوان دلیلی برای رد کردن HTTPS، و دیگری دانستن اتصال HTTPS کارآمد به‌عنوان دلیلی برای نادیده گرفتن اینکه چه کسی رله را اداره می‌کند. هر دو اشتباه دو لایه را در یکی ادغام می‌کنند و بعد درباره لایه اشتباه بحث می‌کنند.
یک ارزیابی کوتاه نوشتاری هر دو را حل می‌کند. طرفی را که هر وعده را می‌دهد نام ببرید، سندی را که از آن پشتیبانی می‌کند پیوست کنید و تاریخ را بنویسید. سپس تصمیم بگیرید که کار به ادعای قوی‌تر نیاز دارد یا فقط به مسیری کارآمد.
مدخل کار خود را کرد همان لحظه که گفت کجا می‌توانید وصل شوید. باقی پرسش به کسی تعلق دارد که آن نقطه پایانی را اداره می‌کند، و پاسخ صادقانه اغلب این است که نمی‌توانید بدانید و باید بر همان اساس انتخاب کنید.