GlobalProtect روی Linux Mint: پیش از نصب چه چیزی را تأیید کنیم
پیش از انتخاب بسته، از مالک VPN درباره پورتال، نسخه کلاینت و جریان احراز هویت بپرسید. وجود یک فایل DEB ثابت نمی‌کند که Mint پشتیبانی می‌شود.
پورتال را در مرورگر باز می‌کنید، وارد می‌شوید و صفحه دانلود کلاینتی را پیشنهاد می‌دهد که ماتریس فروشنده آن را برای توزیع شما فهرست نکرده است. همان لحظه جای توقف و پرسیدن پرسش است، نه لحظه امتحان کردن بسته به هر حال. تصمیم نخست محیط نقطه پایانی پشتیبانی‌شده است و اینکه یک فایل DEB باز می‌شود بخشی از آن نیست. از پورتال شروع کنید و به بیرون بروید.
این ترتیبی است که پیش از نصب هر چیزی با مالک VPN طی می‌کردم.
1. پورتال و نسخه تأیید‌شده را بخواهید
نشانی پورتال، نسخه کلاینتی که سازمان واقعاً مستقر می‌کند و الزامات احراز هویت را از مالک بگیرید. نشانی پورتال از یادداشت‌های یک همکار همان نشانی تأیید‌شده نیست، و نسخه مهم است چون قابلیت‌ها بین نسخه‌ها تفاوت دارند.
سپس پورتال را باز کنید و ببینید برای Linux چه چیزی پیشنهاد می‌دهد. صفحه دانلود معمولاً پیکربندی دروازه را بازتاب می‌دهد نه وضعیت پشتیبانی توزیع شما، پس بسته پیشنهادی می‌تواند هنوز ترکیبی پشتیبانی‌نشده باشد. شماره نسخه‌ای را که صفحه ذکر می‌کند بنویسید و با نسخه مستقر‌شده مقایسه کنید.
2. ماتریس سازگاری را مانند یک جدول بخوانید، نه مانند یک شعار
ماتریس سازگاری فروشنده نسخه‌های Linux را در برابر نسخه‌های برنامه فهرست می‌کند و معماری را از پشتیبانی رابط جدا می‌کند. یک ورودی Ubuntu همه توزیع‌های مشتق از Ubuntu را پشتیبانی‌شده اعلام نمی‌کند، پس ایستگاه کاری Mint پاسخ خودش را لازم دارد. نسخه دقیق، معماری پردازنده و اینکه CLI یا GUI رابط پشتیبانی‌شده برای آن ترکیب است را بررسی کنید.
وقتی ماتریس نسخه‌ای از Ubuntu را نام می‌برد اما Mint را نه، پاسخ صادقانه برای آن ایستگاه کاری نه است، هرقدر هم بسته تمیز نصب شود. جایگزین پشتیبانی‌شده توزیعی است که ماتریس واقعاً نام می‌برد، یا نسخه‌ای که مالک از قبل روی یکی از آن‌ها مستقر می‌کند.
3. جریان احراز هویت را با نوع کلاینت هم‌خوان کنید
مسیر احراز هویت تعیین می‌کند کدام کلاینت می‌تواند ورود را کامل کند. جریان SAML به مرورگر نیاز دارد و پشتیبانی SAML در CLI لینوکس با GlobalProtect app 6.2.1 آمد، پس یک CLI قدیمی‌تر نمی‌تواند همان جریان GUI را کامل کند.
پیش از انتخاب بین CLI و GUI بپرسید دروازه کدام جریان را الزام می‌کند، چون پاسخ یک ترجیح نیست. ورود با گواهی، اعلان‌های MFA و هر ارزیابی دستگاه یک مرحله اضافه می‌کنند که کلاینت باید پشتیبانی کند. کلاینتی که متصل می‌شود و سپس در ارزیابی شکست می‌خورد شبیه خطای شبکه به نظر می‌رسد و چنین نیست.
4. بدانید کلاینت شخص ثالث از کجا دیگر یک گزینه نیست
کلاینت شخص ثالث تنها زمانی شدنی است که مدیر پروتکل و مجموعه قابلیت‌های آن را پشتیبانی کند. هم‌کنش‌پذیری با XAuth/IPsec قدیمی یک ترتیب خاص دروازه است، نه اجازه جایگزینی هر برنامه‌ای که خود را کلاینت SSL VPN می‌نامد. تأیید سرور، الزامات دستگاه و اعتبارنامه‌ها دقیقاً همان‌گونه می‌مانند که سازمان تعیین کرده است. تضعیف آن‌ها برای سازگاری با یک کلاینت محلی تغییری در سیاست است که برچسب سازگاری دارد.
آزمونی که مالک اعمال می‌کند کوتاه است: آیا دروازه SAML، اعلان MFA یا ارزیابی دستگاهی را الزام می‌کند که این کلاینت نمی‌تواند کامل کند؟ اگر هر یک از این‌ها لازم باشد، هیچ هم‌کنش‌پذیری در سطح پروتکل جایگزینی را نجات نمی‌دهد و گفتگو باید به نقاط پایانی پشتیبانی‌شده برود.
5. پاسخ را به مالک برگردانید
ترکیب مشخص را به مالک VPN ببرید: توزیع و نسخه، معماری، رابط، جریان احراز هویت و نسخه کلاینتی که پیشنهاد می‌دهید. این فهرست آن‌قدر کوتاه است که در یک پیام پاسخ داده شود.
اگر ترکیب پشتیبانی نشود، پاسخ پشتیبانی‌شده معمولاً محیط نقطه پایانی تأیید‌شده دیگری است نه یک راه‌حل دور زدن. این را صریح بخواهید، چون درخواستی که با این قالب نوشته شود که کلاینت من را راه بیندازید به تغییر دروازه دعوت می‌کند، در حالی که درخواستی که با این قالب نوشته شود که برای این کاربر کدام نقطه پایانی را پشتیبانی می‌کنید به تصمیم دعوت می‌کند. در هر حال آنچه توافق شده را بنویسید تا نفر بعد همان مسیر را تکرار نکند.