پیش از جایگزینی IPsec با Shadowsocks، کارهای گمشده را فهرست کنید

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

با این شروع کنید که ترافیک چگونه گرفته می‌شود

پروتکل دو نیمه دارد. یک مؤلفهٔ محلی اتصال را می‌پذیرد، جریانی را که با نشانی مقصد شروع می‌شود رمز می‌کند و آن را به یک مؤلفهٔ دور می‌فرستد. نیمهٔ دور اتصالی به آن مقصد باز می‌کند و بایت‌ها را منتقل می‌کند. UDP با داده‌گرام‌ها همان شکل را دنبال می‌کند. این ارسال برای جریان‌هایی است که می‌گیرد و دربارهٔ جریان‌هایی که نمی‌گیرد چیزی نمی‌گوید. برنامه‌ای که صریحاً با پروکسی حرف می‌زند آسان است؛ هر چیز دیگر برای اینکه اصلاً گرفته شود به یک آداپتور یا قواعد مسیریابی نیاز دارد.

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

هر مقصد و پروتکل را نام ببرید

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

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

رمزنگاری مجوزدهی نیست

روش‌های مستند AEAD در Shadowsocks رمزنگاری احرازشده ارائه می‌دهند، پس رد کردن کل خانواده به عنوان ناامن نادرست است. اینکه بگذاریم این واقعیت به پرسش دسترسی پاسخ دهد هم به همان اندازه نادرست است. کسی باید تصمیم بگیرد چه کسی به کدام سرویس می‌رسد، دسترسی هنگام رفتن یک نفر چگونه برداشته می‌شود، رازها کجا نگهداری می‌شوند و کدام مؤلفه مرز را اعمال می‌کند. یک راز مشترک به هر دارنده همان گستره را می‌دهد و خارج کردن یک نفر به چرخش برای همه تبدیل می‌شود.

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

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

کار بهره‌برداری را بشمارید

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

برای یک برنامهٔ وب، یک پروکسی تنگ می‌تواند کافی باشد. برای دسترسی به کل شبکه با مجوزهای فردی، قطعات اضافی معمولاً بیشتر از تونلی که جایگزینش کردند هزینه دارند.

تصمیم این نیست که کدام محصول امن‌تر به نظر می‌رسد. تصمیم این است که کدام طرح کارهای فهرست‌شده را با کنترل‌هایی تمام می‌کند که تیم واقعاً نگهداری خواهد کرد.