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

دو چیز را که در یک تیکت به صورت یک رشته می‌آیند جدا کنید: نشانی‌ای که به سرویس می‌رسد و ورودی‌ای که تعیین می‌کند احراز هویت از کجا شروع می‌شود. درست کردن اولی با نادیده گرفتن دومی همان راهی است که یک نام میزبان درست باز هم ورود اشتباه تولید می‌کند.

کلاینت پیش از آنکه فرمی ببینید چه می‌فرستد

با نشانی‌ای مانند https://vpn.example.net/partners، نخستین اقدام کلاینت درخواست HTTPS به همان مسیر است نه به میزبان خالی. آنچه برمی‌گردد معمولاً تغییرمسیر به نقطه ورود است، یا خود فرم. کلاینتی که فقط vpn.example.net را دریافت می‌کند از هر صفحه فرود پیش‌فرضی که باشد شروع می‌کند، که می‌تواند پورتال دیگر، فهرست گروه دیگر یا صفحه‌ای باشد که پروتکل کاملاً متفاوتی انتظار دارد. تفاوت در سرآیندهای پاسخ مدت‌ها پیش از تایپ هر مدرکی دیده می‌شود.

به همین دلیل یک زبانه مرورگر سالم و یک پروفایل کلاینت ناکام می‌توانند یک درگاه را نام ببرند و باز هم هم‌نظر نباشند. مرورگر مسیر را دنبال کرد؛ پروفایل هرگز آن را نداشت.

دو ورودی که قابل تبادل به نظر می‌رسند و نیستند

OpenConnect مسیر اولیه HTTPS را به صورت --usergroup آشکار می‌کند، و صفحه راهنما نشانی کامل حامل آن مسیر را همان درخواست می‌داند که به شکلی دیگر نوشته شده است. --authgroup گزینه‌ای جداگانه است: از فهرستی که درگاه درون فرم ورود نمایش می‌دهد یک مدخل برمی‌گزیند. برخی پروتکل‌ها آن مدخل را گروه می‌نامند، برخی دامنه یا درگاه، و درست همان‌جا این دو پرچم اشتباه گرفته می‌شوند.

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

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

چرا کوتاه کردن مسیر نتیجه را تغییر می‌دهد

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

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

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

پیش از ویرایش هر چیز دیگری نقطه ورود را تأیید کنید

سرآیندهای مسیری را که دریافت کرده‌اید بخوانید. درخواستی مانند curl -sS -o /dev/null -D - https://vpn.example.net/partners بدون دنبال کردن تغییرمسیر، سطر وضعیت و هر سرآیند Location را چاپ می‌کند. کد 302 که به یک نقطه ورود نام‌دار اشاره می‌کند تأیید می‌کند مسیر وجود دارد و نشان می‌دهد کجا می‌رود؛ کد 404 یعنی نشانی اپراتور کهنه است.

سپس همان نقطه ورود را در کلاینت تأییدشده بازتولید کنید، مثلاً openconnect --usergroup=partners vpn.example.net، و ببینید کدام فرم ظاهر می‌شود. اگر فرم درست است و تونل باز هم شکست می‌خورد، مسیر هرگز مشکل نبود و ایستگاه بعدی سیاست یا مسیریابی است.

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

مقالات مرتبط