VPN همتا به همتا هنوز وابستگی‌های مرکزی دارد

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

نمودار بدون فلش ارسال مرکزی می‌تواند یک مرجع ثبت‌نام، یک سرویس کشف و یک رله را پنهان کند که همه‌شان وابستگی‌های عملیاتی‌اند.

مسیر مستقیم، صفحه کنترل مشترک

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

هر کار را جداگانه رسم کنید حتی وقتی یک میزبان همه را انجام می‌دهد. در غیر این صورت نمودار یک صفحه داده غیرمتمرکز را نشان می‌دهد و واقعیت عملیاتی را که هر همتای جدید به همان دو سرویس نیاز دارد پنهان می‌کند.

کشف، اعتماد و رله سه کارند

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

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

هر وابستگی کجا شکست می‌خورد

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

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

بپرسید از کدام قطعی می‌توانید جان سالم به در ببرید

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

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

واژه غیرمتمرکز وقتی جای خود را می‌یابد که این خرابی‌ها را نام ببرد. بدون آن فهرست، نموداری را توصیف می‌کند نه یک سیستم.