کد چالش ایستا در ورود OpenVPN کجا قرار می‌گیرد
چالش ایستا یک ورودی دوم در کنار گذرواژه اضافه می‌کند و کارخواه پشتیبان می‌تواند هر دو را در یک فیلد رمزگذاری‌شده بگنجاند. بفهمید در کدام حالت هستید.
کارخواه پس از فیلد گذرواژه کادر دومی نشان می‌دهد، شما کد را از توکن سخت‌افزاری وارد می‌کنید و ورود هنوز با خطای احراز هویت شکست می‌خورد. آن کادر وجود دارد، پس نمایه آن را خواسته است. اینکه سرور هرگز مقدار را در قالبی که می‌فهمد دریافت کرده است یا نه پرسش دیگری است و همان پرسشی است که ارزش دارد نخست پاسخ داده شود.
از همان اعلانی شروع کنید که کارخواه شما واقعاً نشان می‌دهد
نمایه می‌تواند یک دستور چالش ایستا با رشته اعلان و پرچمی حمل کند که کنترل می‌کند پاسخ هنگام تایپ نمایش داده شود یا نه. اعلان همان چیزی است که در گفتگو می‌بینید؛ پرچم یک ترجیح نمایشی برای همان ورودی است. هیچ‌کدام به سرور نمی‌گوید چگونه چیزی را بررسی کند.
فیلدهایی را که واقعاً به شما داده شده بشمارید. یک فیلد برای نام کاربری به‌همراه یک فیلد پوشیده، ورود عادی با گذرواژه و بدون هیچ چالشی است. فیلد دومی که پس از گذرواژه با برچسب خودش ظاهر می‌شود، همان کارخواهی است که تعامل چالش را پیاده می‌کند.
اگر کادر دوم هرگز در کارخواهی که استفاده می‌کنید ظاهر نشود، ممکن است آن کارخواه تعامل را پیاده نکرده باشد، یا آن را فقط از طریق یک واسط جلویی دیگر مانند واسط مدیریت پیاده کند. بررسی کارخواه ارزان‌تر از بازنویسی نمایه است و معمولاً همان‌جاست که ناسازگاری واقعاً قرار دارد.
آنچه سرور باید از پیش پشتیبانی کند
نمایه توصیف می‌کند کارخواه چه چیزی باید گردآوری کند. این نمایه بررسی را روی سرور فعال نمی‌کند و سروری بدون یکپارچه‌سازی احراز هویت متناظر صرفاً گذرواژه‌ای دریافت می‌کند که آن را نمی‌شناسد. به همین دلیل برخی استقرارها اعلان را نشان می‌دهند و هر کدی را رد می‌کنند و به همین دلیل پاسخ اپراتور درباره اینکه کدام سازوکار بررسی را انجام می‌دهد همان پاسخی است که اهمیت دارد.
از اپراتور بپرسید کدام سازوکار بررسی را انجام می‌دهد. می‌تواند افزونه‌ای باشد که با PAM سخن می‌گوید، یک قلاب اسکریپتی که پاسخ را در برابر سرویس توکن اعتبارسنجی می‌کند، یا یکپارچه‌سازی مبتنی بر مدیریت که خودش مقدار بسته‌بندی‌شده را تجزیه می‌کند. هر یک از آن‌ها ورودی کمی متفاوتی انتظار دارد.
اینجاست که انتظارات نیز باید کالیبره شوند. اعلان دوم یک سازوکار ورودی است، نه دلیلی بر اینکه عامل دومی اعمال می‌شود، زیرا اعمال در سمت سرور رخ می‌دهد و تنها وقتی کد اشتباهی را آزمایش کنید نمایان می‌شود.
فیلد رمزگذاری‌شده‌ای که واسط مدیریت می‌فرستد
وقتی یک واسط جلویی اتصال را از طریق واسط مدیریت هدایت می‌کند، گذرواژه و پاسخ چالش پیش از ارسال در یک مقدار بسته‌بندی می‌شوند. مرجع واسط مدیریت قالب را مستند می‌کند: یک پیشوند، سپس گذرواژه و پاسخ به‌عنوان مؤلفه‌های جداگانه Base64.
Base64 یک رمزگذاری است، نه یک محافظت. چیزی را از کسی که می‌تواند فیلد را بخواند پنهان نمی‌کند و کد یک‌بارمصرف را به چیزی قابل استفاده مجدد تبدیل نمی‌کند. مقدار بسته‌بندی‌شده سزاوار همان برخوردی است که گذرواژه دارد: بیرون از نمایه‌های مشترک، بیرون از خطوط فرمان و بیرون از گزارش‌های عیب‌یابی.
این رمزگذاری همچنین رایج‌ترین منبع سردرگمی است، زیرا اکنون سه شکل وجود دارد که شبیه هم به نظر می‌رسند و قابل جایگزینی نیستند. یک پرونده اعتبارنامه ساده گذرواژه را نگه می‌دارد. الحاق تحت‌اللفظی گذرواژه و کد رشته دیگری را نگه می‌دارد. پاسخ بسته‌بندی‌شده کارخواه مدیریت سومی را نگه می‌دارد. پیش از تغییر یک فیلد فقط به این دلیل که خطایی از میان رفت، تأیید کنید مسیر بررسی شما کدام را انتظار دارد.
ایستا در برابر پویا: زمان‌بندی متفاوت
چالش ایستا پیش از ارسال نخستین اعتبارنامه شناخته شده است، پس کارخواه می‌تواند آن را از پیش بخواهد. چالش پویا دیرتر می‌رسد، پس از آنکه تبادلی آغاز شده، جریان احراز هویت آن را می‌فرستد و به کارخواهی نیاز دارد که بتواند درخواستی در میانه گفتگو را مدیریت کند.
پشتیبانی از یکی دیگری را به شما نمی‌دهد. دستور نمایه‌ای که اعلان ایستا را تنظیم می‌کند چالش آغازشده از سوی سرور را پیاده نمی‌کند و واسط جلویی که درخواست‌های پویا را مدیریت می‌کند ممکن است هنوز یکی ایستا را نشان ندهد. خواندن اینکه کدام طرف درخواست را آغاز کرده سریع‌ترین راه برای تفکیک آن‌هاست.
بهره‌برداری بدون نظارت همان جایی است که این به پرسش طراحی تبدیل می‌شود، نه پرسش واسط. کد ذخیره‌شده اعتبارنامه پایدار زمان راه‌اندازی نیست و اتصال دوباره چند ساعت بعد ورودی تازه می‌خواهد، مگر آنکه استقرار چیدمان توکنی را پشتیبانی کند که اپراتور آگاهانه فعال کرده است.
موفقیت و شکست را آزمایش کنید، نه فقط گفتگو را
هر دو نیمه آزمایش را اجرا کنید. اعتبارنامه درست با پاسخ معتبر باید موفق شود؛ اعتبارنامه درست با پاسخ عمداً اشتباه باید رد شود. اگر هر دو موفق شوند، کارخواه ورودی‌ای گرد می‌آورد که هیچ چیز آن را بررسی نمی‌کند و گفتگو با یک کنترل اشتباه گرفته شده است. همین یک آزمایش بیش از هر بازبینی نمایه استقرارها را می‌گیرد.
سپس اتصال را پس از اتصال دوباره، با حسابی که ثبت‌نام نشده و از طریق همان کارخواهی که کاربران شما واقعاً اجرا می‌کنند تکرار کنید. ظاهر شدن اعلان رفتاری از کارخواه است؛ رد شدن کد اشتباه یعنی سرور چیزی را اعمال می‌کند.