دو دسته تنظیم، دو چرخه تغییر
مستندات Traefik میان تنظیمات نصب و آغاز به کار، و تنظیمات مسیریابی تفاوت می‌گذارند؛ این دو دسته در نام‌گذاری قدیمی به‌ترتیب static و dynamic بودند. بخش نخست، مواردی مانند Providerها و EntryPointهای شنونده را تعیین می‌کند. بخش دوم مشخص می‌کند درخواست چگونه بررسی و به سرویس مقصد هدایت شود و می‌تواند بدون راه‌اندازی مجدد همه فرایند بازخوانی شود.
در مسیر HTTP، Router قواعد تطبیق درخواست را بررسی می‌کند؛ Middleware می‌تواند پردازش میانی انجام دهد و Service مقصد یا توازن بار را توصیف می‌کند. دیدن یک Router در پنل به معنی درست‌بودن گواهی، دسترسی شبکه یا پاسخ برنامه نیست. هر بخش قرارداد مستقل دارد.
آزمایش پیشنهادی تحریریه
برای یک دامنه آزمایشی، سرویس کوچکی در نظر بگیرید که فقط نام میزبان پاسخ‌دهنده را برگرداند. ابتدا یک EntryPoint و یک مسیر ساده ایجاد کنید. پیش از افزودن احراز هویت، کش یا تغییر مسیر، تطبیق نام میزبان و رسیدن به سرویس را بررسی کنید.
سپس سه خطای کنترل‌شده بسازید: نام میزبان متفاوت، مقصد خاموش و پورت اشتباه. نتیجه هر خطا را همراه با زمان و شناسه درخواست ثبت کنید. این کار نشان می‌دهد یک پاسخ ناموفق همیشه از یک لایه نمی‌آید. بازکردن گسترده فایروال برای خطایی که از قاعده تطبیق ناشی شده، فقط مسئله تازه‌ای ایجاد می‌کند.
اعتماد به اطلاعات ورودی
در طراحی پیشنهادی، دقیقاً مشخص کنید کدام پراکسی اجازه دارد اطلاعات آدرس کاربر یا پروتکل اولیه را به لایه بعدی منتقل کند. برنامه نباید صرف وجود یک Header، آن را حقیقت قطعی بداند. برای زنجیره چند پراکسی، یک نقشه از نقاط خاتمه TLS و مسیر بازنویسی Header تهیه کنید.
یک سناریوی منفی هم داشته باشید: درخواست مستقیم به مقصد نباید بدون عبور از کنترل‌های لازم همان دسترسی کاربر مجاز را بگیرد. این آزمون را در محیطی انجام دهید که مجوز و محدوده آن روشن است.
تغییر کوچک و قابل برگشت
پیشنهاد ما نگهداری تنظیمات در کنترل نسخه و بررسی تفاوت هر تغییر است. نخست یک مسیر کم‌خطر را منتقل کنید و برای پاسخ‌های خطا و تأخیر، حد پذیرش بنویسید. تعریف یک مسیر تازه، تغییر گواهی و تغییر منطق احراز هویت را در یک گام مخلوط نکنید؛ هنگام شکست باید بتوانید علت و نقطه بازگشت را تشخیص دهید.
یک درخواست را از نام دامنه تا برنامه دنبال کنید
فرض کنید کاربر نشانی یک سامانه گزارش را در مرورگر وارد می‌کند. پیش از آنکه قاعده مسیریابی ارزیابی شود، نام دامنه باید به نشانی مناسب حل شود و ارتباط شبکه به پورت ورودی برسد. اگر TLS در همین نقطه پایان می‌یابد، گواهی و نام مورد انتظار نیز باید معتبر باشند. سپس درخواست HTTP با نام میزبان و مسیر خود به مسیریاب می‌رسد. هر کدام از این مراحل می‌تواند شکست بخورد و نشانه متفاوتی ایجاد کند؛ خطای حل نام را با افزودن قاعده مسیر نمی‌توان اصلاح کرد.
برای جدا کردن لایه‌ها، ابتدا رسیدن به پورت را بررسی کنید و سپس گواهی و درخواست HTTP را بسنجید. هنگام آزمایش مستقیم با نشانی IP، توجه کنید که نام میزبان و نام مورد استفاده در TLS ممکن است با درخواست مرورگر متفاوت باشند. بنابراین موفقیت اتصال به IP به تنهایی نشان نمی‌دهد قاعده مربوط به دامنه درست انتخاب می‌شود. یک درخواست شاهد با دامنه و مسیر واقعی، برای مقایسه با حالت ناموفق ارزش بیشتری دارد.
EntryPoint محل ورود است، Router تصمیم مسیر
EntryPoint مشخص می‌کند پراکسی روی کدام نشانی و پورت منتظر ارتباط باشد. Router بر اساس قواعد خود درخواست را به مسیر مناسب می‌فرستد. ایجاد یک Router بدون اتصال درست به ورودی، شنونده تازه‌ای ایجاد نمی‌کند. در سمت دیگر، باز بودن یک پورت هم به معنای وجود قاعده‌ای برای همه دامنه‌ها نیست. هنگام بررسی، فهرست ورودی‌های فعال و ارتباط هر مسیریاب با آنها را کنار هم ببینید تا این دو مفهوم با هم اشتباه نشوند.
اگر چند قاعده می‌توانند یک درخواست را تطبیق دهند، اولویت و دامنه آنها اهمیت دارد. یک قاعده عمومی برای همه مسیرها ممکن است با قاعده اختصاصی هم‌پوشانی داشته باشد. برای آزمایش، چند مسیر مرزی بسازید: مسیر دقیق، زیرمسیر و مسیری با پیشوند مشابه ولی معنای متفاوت. نتیجه باید نشان دهد درخواست به سرویس درست می‌رود. تنها آزمون صفحه اصلی برای اثبات صحت مجموعه‌ای از قواعد پیچیده کافی نیست.
Middleware قرارداد ورودی برنامه را تغییر می‌دهد
میان‌افزار می‌تواند روی مسیر، سربرگ، احراز هویت یا رفتار پاسخ اثر بگذارد. ترتیب اعمال آن مهم است، زیرا هر مرحله ورودی مرحله بعد را می‌سازد. برای نمونه، حذف پیشوند مسیر قبل یا بعد از یک کنترل مبتنی بر مسیر ممکن است نتیجه متفاوتی داشته باشد. پیش از زنجیره کردن چند میان‌افزار، درخواست را در هر مرحله به زبان ساده توصیف کنید: نام میزبان چیست، مسیر کدام است و چه اطلاعات هویتی به برنامه می‌رسد؟
در آزمایش حذف پیشوند، فقط صفحه آغازین را بررسی نکنید. لینک‌های نسبی، مسیر فایل‌های ایستا، نشانی بازگشت ورود و هدایت‌های برنامه نیز باید درست بمانند. برنامه‌ای که تصور می‌کند در ریشه دامنه نصب شده ممکن است کاربر را به مسیر اشتباه هدایت کند. این خطا الزاماً با بازنویسی بیشتر در پراکسی حل نمی‌شود؛ گاهی تنظیم نشانی پایه خود برنامه لازم است. مسئولیت هر تغییر را مشخص کنید تا چند لایه هم‌زمان یک مسیر را بازنویسی نکنند.
Service به مقصد واقعی اشاره می‌کند
در مدل مسیریابی، Service مقصد یا مجموعه مقصدهای قابل توازن بار را توصیف می‌کند. نام آن با نام فرایند سیستم‌عامل یا نام سرویس تجاری الزاماً یکسان نیست. اگر مقصد اشتباه باشد، تطبیق کامل Router هم پاسخ درست تولید نمی‌کند. از محیط خود پراکسی دسترسی به نشانی و پورت مقصد را بررسی کنید؛ دسترسی موفق از لپ‌تاپ مدیر نمی‌گوید شبکه میان پراکسی و برنامه باز است. تفاوت مسیر شبکه یکی از علت‌های رایج تشخیص اشتباه است.
در محیط کانتینری یا خوشه، کشف پورت و شبکه باید با استقرار واقعی هماهنگ باشد. برنامه ممکن است درون کانتینر روی پورتی متفاوت از پورت منتشرشده میزبان گوش کند. همچنین وجود چند شبکه می‌تواند انتخاب نشانی مقصد را مبهم کند. مشاهده پیکربندی مؤثر و نشانی انتخاب‌شده به جای حدس از روی فایل اولیه، بررسی را کوتاه می‌کند. بعد از اصلاح مقصد، پاسخ خود برنامه را هم بررسی کنید تا خطای داخلی با موفقیت اتصال اشتباه نشود.
TLS بیرونی و ارتباط داخلی را مستقل طراحی کنید
پایان دادن TLS در پراکسی، وضعیت رمزگذاری مسیر بعدی تا برنامه را تعیین نمی‌کند. ممکن است ارتباط داخلی نیز TLS داشته باشد یا بر اساس طراحی شبکه به شکل دیگری محافظت شود. این تصمیم باید با مرز اعتماد و نیاز سازمان هماهنگ باشد. اگر TLS داخلی فعال است، نام گواهی، زنجیره اعتماد و اعتبار زمانی آن را بررسی کنید. خاموش کردن بررسی گواهی برای حل سریع خطا، رابطه اعتماد را تغییر می‌دهد و نباید بدون تصمیم روشن باقی بماند.
تمدید گواهی را پیش از نزدیک شدن به انقضا آزمایش کنید و مالک ذخیره‌سازی وضعیت مربوط به آن را مشخص سازید. چند نمونه پراکسی که هم‌زمان یک دامنه را مدیریت می‌کنند به طراحی سازگار نیاز دارند. همچنین پیام خطای مرورگر و خطای ارتباط پراکسی با مقصد را جدا نگه دارید؛ هر دو ممکن است به گواهی مربوط باشند ولی در دو اتصال متفاوت رخ دهند. ثبت نقطه پایان هر اتصال، عیب‌یابی را بسیار دقیق‌تر می‌کند.
سربرگ‌های واسط و هویت کاربر
برنامه پشت پراکسی معمولاً به اطلاعاتی درباره نشانی اصلی کاربر و پروتکل اولیه نیاز دارد. این اطلاعات باید فقط از واسط‌های مورد اعتماد پذیرفته شوند. اگر درخواست مستقیم کاربر بتواند همان سربرگ‌ها را تعیین کند، ثبت نشانی یا تصمیم امنیتی ممکن است بر داده جعلی تکیه کند. در زنجیره چند پراکسی، مشخص کنید هر کدام کدام مقدار را اضافه، حفظ یا بازنویسی می‌کند. این قرارداد را با یک درخواست دارای سربرگ ساختگی آزمایش کنید.
اگر احراز هویت در پراکسی انجام می‌شود، برنامه مقصد باید فقط از مسیر کنترل‌شده در دسترس باشد یا خودش نیز هویت را معتبر بررسی کند. در غیر این صورت، اتصال مستقیم به مقصد می‌تواند کنترل لایه ورودی را دور بزند. برای آزمون مجاز، مسیر عادی و مسیر مستقیم را با حساب محدود مقایسه کنید. هدف اثبات این است که اطلاعات هویتی ارسال‌شده توسط پراکسی از درخواست دلخواه کاربر قابل تقلید نیست و مرز اعتماد در شبکه نیز اجرا شده است.
خطاها را با نشانه درست دسته‌بندی کنید
پاسخی که هیچ قاعده‌ای برای آن انتخاب نشده با شکست اتصال به مقصد تفاوت دارد. همچنین برنامه ممکن است خودش پاسخ خطا تولید کند در حالی که پراکسی وظیفه‌اش را درست انجام داده است. گزارش دسترسی، نام مسیر انتخاب‌شده، مقصد و مدت پاسخ را کنار هم بررسی کنید. شناسه درخواست مشترک میان پراکسی و برنامه کمک می‌کند رویدادها به هم متصل شوند. از ذخیره بی‌دلیل کوکی و اعتبارنامه در گزارش‌ها خودداری کنید؛ برای ارتباط رویدادها معمولاً شناسه غیرحساس کافی است.
اگر فقط بعضی درخواست‌ها شکست می‌خورند، تفاوت اندازه بدنه، روش HTTP، مدت اجرا و نوع ارتباط را بررسی کنید. درخواست بارگذاری فایل با صفحه کوچک تفاوت دارد و ارتباط طولانی نیز ممکن است به زمان انتظار متفاوتی نیاز داشته باشد. افزایش همه محدودیت‌ها بدون شناخت نیاز، مصرف منابع را تغییر می‌دهد. یک نمونه بازتولید کوچک با همان ویژگی مهم بسازید و تنها تنظیم مربوط به همان محدودیت را آزمایش کنید.
انتشار و بازگشت پیکربندی
پیش از تغییر مسیر پرترافیک، سرویس شاهدی با پاسخ ساده داشته باشید تا مطابقت نام میزبان و مقصد قابل دیدن باشد. سپس یک مسیر محدود را منتقل کنید و میزان خطا، تأخیر و رفتار هدایت را مقایسه کنید. تغییر هم‌زمان روش کشف سرویس، TLS و احراز هویت، نسبت دادن شکست به یک عامل را دشوار می‌کند. نگهداری نسخه قبلی پیکربندی کافی نیست؛ باید بدانید بازگشت چه زمانی اعمال می‌شود و اتصال‌های موجود چه رفتاری خواهند داشت.
پس از بازخوانی تنظیمات، وضعیت مؤثر را بررسی کنید و تنها به موفقیت ذخیره فایل تکیه نکنید. خطای نحو یا منبع کشف می‌تواند باعث شود انتظار شما با تنظیم فعال متفاوت بماند. آزمون پذیرش باید از دید کاربر انجام شود و مسیرهای اصلی، ورود و خروج، فایل‌های ایستا و پاسخ مقصد را پوشش دهد. در پایان، نقشه کوتاهی از ورودی، قواعد، میان‌افزارها و مقصدها نگه دارید تا تغییر بعدی بر پایه ساختار روشن انجام شود و هر مشکل به یک گزینه تصادفی نسبت داده نشود.
