پیش از آنکه یک charm از Juju به VPN شما تبدیل شود: هویت، قرارداد، پورت‌ها

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

گام یک: مصنوعی را که درباره‌اش می‌خوانید پین کنید

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

juju info CHARM_NAME در Juju 3.6 کانال‌ها، پایه‌ها و معماری‌ها را گزارش می‌کند و مستندات یادآور می‌شود که پرس‌وجوی یک نسخه مشخص را نمی‌توان با این فیلترها ترکیب کرد. نسخه را به‌تنهایی بپرسید، نه اینکه ترکیبی بسازید که فرمان آن را رد می‌کند. پایه و معماری را هم بخوانید، چون یک کانال می‌تواند بیش از یکی را پوشش دهد.

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

گام دو: پیکربندی را به‌عنوان قرارداد بخوانید

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

رابط‌ها و اقدام‌هایی را که charm واقعاً ارائه می‌دهد دنبال کنید. فرض نکنید اقدام ثبت‌نام وجود دارد فقط چون charm دیگری برای همان نرم‌افزار یکی دارد.

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

گام سه: شنونده را از مسیر ارسال‌شده جدا کنید

شنونده بیرونی سوکتی است که تونل را می‌پذیرد. ارسال آن چیزی است که با ترافیک درون آن رخ می‌دهد، و مسیر بازگشت چیزی است که پاسخ‌ها را برمی‌گرداند. یک charm می‌تواند اولی را تحویل دهد و دو مورد دیگر را به تیم زیرساخت بسپارد.

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

گام چهار: مواجهه یک اقدام دیوار آتش است

در Juju 3.6، در معرض قرار دادن یک برنامه قواعد دیوار آتش ابری را تنظیم می‌کند و به‌طور پیش‌فرض ترافیک را از هر منبعی به پورت‌هایی که بار کاری باز کرده است اجازه می‌دهد. انتخاب‌گرهای endpoint و CIDR در فرمان دقیقاً برای این هستند که بتوان آن پیش‌فرض را محدود کرد.

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

گام پنج: با چهار آزمون بپذیرید

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

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