پروفایل قفلشده به سرور پشت یک پروکسی TLS شکست میخورد: کدام نسل؟
Access Server 2.8 و 2.9 پروفایلهای قفلشده به سرور را متفاوت میسازند. پیش از تغییر فرانتاند تصمیم بگیرید پروکسی شما کدام مسیر را میشکند.
یک کاربر میتواند متصل شود و دیگری نمیتواند، از طریق همان پرتال، در همان روز. هر دو پروفایل قفلشده به سرور دارند، هر دو روی همان نسخه Access Server هستند، و تنها تفاوت این است که پروفایلشان چه زمانی تولید شده است. این همان الگویی است که ارزش شناختن دارد، زیرا «قفلشده به سرور» نام یک سیاست است، نه یک توالی اتصال. Access Server دو نسل از این مصنوع را عرضه کرده است، و یک پروکسی معکوس TLS فقط جلوی یکی از مسیرهای آنها قرار دارد. سه شرط تعیین میکند در کدام شاخه هستید.
دو نسل، دو توالی اتصال
در طراحی قدیمیتر، که تا 2.8 معتبر است، فایل واردشده یک شبهپروفایل است. OpenVPN Connect از آن برای احراز هویت در برابر API وب Access Server روی HTTPS استفاده میکند، یک پروفایل موقت قفلشده به کاربر و یک توکن نشست دریافت میکند، و تنها پس از آن VPN را برقرار میکند. دو حامل به ترتیب اجرا میشوند، و اولی یک درخواست وب معمولی است.
قالبی که با 2.9 معرفی شد، آن راهاندازی اولیه برای هر اتصال را انجام نمیدهد. این یک پروفایل بومی است که OpenVPN کلاینتهای سازگار میتوانند از آن استفاده کنند، نه فقط OpenVPN Connect. دانلود یا وارد کردن آن از طریق URL هنوز میتواند شامل HTTPS باشد — این یک مرحله انتشار است، نه واکشی یک پروفایل موقت برای هر اتصال.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
ارتقا لزوماً پروفایلهایی را که قبلاً صادر شدهاند بازنویسی نمیکند، بنابراین یک نسخه فعلی سرور هنوز میتواند مصنوع قدیمی را توزیع کند. نسخه ساخت سرور به شما میگوید چه چیزی ممکن است، نه اینکه این کاربر چه چیزی وارد کرده است.
سه شرطی که شاخه شما را انتخاب میکنند
شرط اول نسل مصنوع است. فایل را بخواهید، ببینید چگونه تولید شده، و نسخه کلاینتی را که آن را وارد کرده یادداشت کنید. اگر نمیتوانید نسل را از فایل تشخیص دهید، یک پروفایل تازه که برای حساب آزمایشی صادر شده به شما میگوید سرور امروز چه تولید میکند، و این اطلاعاتی متفاوت از آن است که کاربر ناموفق دارد.
شرط دوم این است که فرانتاند شما واقعاً چه چیزی را پایان میدهد. یک پروکسی معکوس HTTP در لایه هفت که TLS را برمیدارد، همان شیء یک هدایتکننده TCP در لایه چهار نیست، و یک هدایتکننده UDP هم نیست. چیدمان معمول Access Server روی پورت 443 باعث میشود دیمن OpenVPN TCP ترافیک مرورگر را تشخیص دهد و آن را به سرویسهای وب بسپارد، بنابراین قرار دادن یک پایاندهنده HTTPS نامرتبط در جلو، مدیریت پروتکل آن دیمن را حفظ نمیکند. اشتراک عدد 443 دو طراحی را معادل نمیکند.
شرط سوم این است که شکست کجا رخ میدهد. شکست پیش از VPN و شکست کانال کنترل در کلاینتی که فقط «در حال اتصال» میگوید شبیه به هم به نظر میرسند، اما شواهد را در جاهای مختلف باقی میگذارند. اگر قالب قدیمی در کار باشد، راهاندازی اولیه یک گزینه است. اگر قالب جدید در کار باشد، گزارش خالی دسترسی وب مورد انتظار است و هیچ چیزی را در هیچ جهتی اثبات نمیکند.
وقتی مصنوع قدیمی است: راهاندازی اولیه نخست شکست میخورد
خطای واقعی کلاینت را بخوانید، نه حالت نهایی آن. فیلدهای مهم عبارتند از خطای HTTPS، هویت سروری که کلاینت انتظار داشت، مقصدی که درخواست به آن رفت، و اینکه اعتبارسنجی گواهی کامل شد یا نه. سپس آنها را با گزارشهای سرویس وب و پروکسی در سمت سرور تطبیق دهید.
اینکه مرورگر به صفحه ورود برسد، مدرکی بر موفقیت احراز هویت API این کلاینت نیست. آنها درخواستهای متفاوتی با انتظارات گواهی متفاوت و اغلب نامهای میزبان متفاوت هستند. اگر پرتال درست سرو شود و کلاینت همچنان شکست بخورد، اختلاف در مسیر راهاندازی اولیه است، نه در گذرواژه کاربر.
مقایسه را با غیرفعال کردن اعتبارسنجی TLS یا شل کردن سیاست احراز هویت موفق نکنید. این یک ناسازگاری قابلتشخیص پیکربندی را به مسیری تبدیل میکند که کار میکند ولی تأیید نشده، و دقیقاً همان تغییری است که یک آزمون موقت را به یک حفره دائمی تبدیل میکند. مستندات Access Server درباره پروفایلهای اتصال هر دو نسل و جریان پروفایل موقت را توصیف میکند، و مرجعی است که باید پیش از فرض کردن تقصیر پروکسی بررسی شود.
وقتی مصنوع جدید است: به جای آن کانال کنترل را بخوانید
با یک پروفایل به سبک 2.9، کلاینت مستقیماً به نقطه پایانی بومی VPN میرود. نقاط پایانی در پروفایل، حامل مورد استفاده، و خطای کانال کنترل را بررسی کنید. اگر کلاینت هرگز درخواست HTTP صادر نکند، این با طراحی سازگار است و نشانه مشکل نیست.
اینجا هم پرسش پروکسی شکل عوض میکند. باربرداری HTTPS نمیتواند جریانی را که فقط TCP است و هرگز آن را نمیبیند بشکند، اما هنوز میتواند دانلودی را که پروفایل را منتشر میکند بشکند، و یک هدایتکننده فقط TCP اصلاً UDP را حمل نمیکند. پیش از نتیجهگیری که فرانتاند بیربط است، بررسی کنید پروفایل کدام حامل را میخواهد.
عبور TLS برای یک جریان واحد چیدمانی باریک است. هدایت UDP ارائه نمیدهد، و رفتار هدایت سرویس خود دیمن روی 443 را بازتولید نمیکند. اگر فرانتاند شما یکی از این کارها را میکند، بگویید کدام، زیرا درمان متفاوت است.
درمانهایی که باریک میمانند
کممداخلهترین بررسی این است که یک پروفایل پشتیبانیشده تازه برای حساب آزمایشی تولید کنید و از طریق نقطه پایانی بومی مورد نظر با همان الزامات احراز هویت متصل شوید. اگر آن کار کند و پروفایل قدیمی نگهداشتهشده نکند، در یک قدم مصنوع را از سرور و از پروکسی جدا کردهاید.
توزیع یک پروفایل قفلشده به کاربر وابستگی به راهاندازی اولیه قدیمی را کاملاً حذف میکند، زیرا هیچ تبادل پروفایل موقتی برای شکست خوردن وجود ندارد. باید برای کاربر مورد نظر صادر شود، هرگز از یک مدیر کپی نشود، و تغییر میدهد کلاینت مجاز به چه کاری است، پس آن را یک تصمیم سیاست بدانید نه یک راهحل موقت.
سپس چیدمان انتشار را درست کنید تا هر مسیر لازم وجود داشته باشد: مسیر وب برای دانلودها و استفاده از پرتال، و مسیر بومی VPN روی حاملی که پروفایلها انتظار دارند. کار پروکسی را در یک لایه نگه دارید. تونل قفلشده به کاربر که کار میکند ثابت میکند آن مسیر کار میکند؛ ثابت نمیکند هر چیدمان پروکسی هر نسل را پشتیبانی میکند، و شکست راهاندازی اولیه قدیمی قالب جدیدتر را محکوم نمیکند.
- پیش از دست زدن به پروکسی، نسل مصنوع را مشخص کنید.
- مشخص کنید شکست پیش از تونل رخ میدهد یا درون آن.
- تأیید کنید فرانتاند چه چیزی را پایان میدهد: HTTP، جریان TCP، یا UDP.
- یک پروفایل تازه صادرشده را با سیاست بدون تغییر در برابر نقطه پایانی بومی آزمایش کنید.