چرا ورود openfortivpn هنگام چسباندن نشانی URL پورتال شکست می‌خورد

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

نشانی پورتال Fortinet مانند https://vpn.example.com/ext چند تکه اطلاعات را همزمان حمل می‌کند و تنها برخی از آن‌ها به کارخواه VPN تعلق دارند.

نقطه پایانی و realm دو ورودی جداگانه‌اند

openfortivpn یک نقطه پایانی به شکل host یا host:port می‌خواهد، به‌همراه یک حساب و، جایی که استقرار از آن استفاده می‌کند، مقدار realm. realm به دروازه می‌گوید کدام سیاست احراز هویت را پیش از ارزیابی حساب اعمال کند. این یک فیلد جداگانه است، نه پسوندی که کارخواه از یک URL بیرون بکشد.

برای استقرارهایی که اپراتور آن تأیید می‌کند realm برابر ext است، یک فراخوانی غیرمحرمانه چنین است: openfortivpn vpn.example.com:443 --username=alice --realm=ext. همان مقادیر به‌عنوان ورودی‌های host، port، username و realm در فایل پیکربندی جای می‌گیرند. رمز عبور را از هر دو شکل بیرون بگذارید و بگذارید کارخواه آن را بپرسد، تا در تاریخچه پوسته یا در فایلی که همه می‌خوانند نیفتد. تلاش دوم در حالی که کارخواه نخست هنوز تونل را در دست دارد، به‌دلیلی شکست می‌خورد که هیچ ربطی به realm ندارد.

راهنمای openfortivpn هر دو گزینه را فهرست می‌کند، بنابراین تأیید املای دقیق پیش از تماس با پشتیبانی آسان است. با این حال نمی‌تواند بگوید کدام realm روی دروازه شما پیکربندی شده است.

یک بخش مسیر به‌طور خودکار realm نیست

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

realm همچنین همان پسوند دامنه روی نام کاربری یا منطقه‌ای که دروازه در آن قرار دارد نیست. برخی استقرارها alice می‌خواهند و برخی alice@corp، و realm تعیین می‌کند دروازه کدام را می‌پذیرد. تغییر قالب حساب برای جبران یک realm نادرست معمولاً رد دومی با اطلاعات کمتر تولید می‌کند.

خطای realm را با تغییر میزبان برطرف نکنید

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

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

ورود ردشده را از تونل ناموفق جدا کنید

شکست‌های احراز هویت و شکست‌های تونل در لحظه‌های متفاوتی می‌رسند و پیام‌ها فرق دارند. خطای تحلیل نام پیش از هر دست‌دادن TLS رخ می‌دهد. رد TLS پیش از فرستادن اعتبارنامه‌ها رخ می‌دهد. رد realm یا حساب به‌صورت پاسخی در سطح HTTP از پورتال برمی‌گردد. تنها پس از آن مراحل است که مذاکره PPP آغاز می‌شود و تنها آنگاه مشکلات مسیریابی و DNS پدیدار می‌شوند.

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

مقادیر را جایی نگه دارید که اجرای بعدی آن‌ها را پیدا کند

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

یک اتصال را از ابتدا تا انتها دوباره آزمایش کنید و هم سیاست اعمال‌شده و هم دسترسی به منبعی را که واقعاً نیاز دارید تأیید کنید. موفقیت احراز هویت آغاز آن بررسی است، نه پایان آن.