کدام کلاینت می‌تواند ورود SAML در AWS Client VPN را کامل کند
میزکارهای لینوکس با کلاینت AWS می‌توانند انتقال SAML در مرورگر را کامل کنند؛ یک ورود OpenVPN عمومی روی اندروید نمی‌تواند. سه شرط مورد شما را تعیین می‌کند.
دو نفر یک پرسش را درباره AWS Client VPN و SAML می‌پرسند و پاسخ‌های متضاد می‌گیرند. یکی هر صبح از یک لپ‌تاپ Ubuntu وارد می‌شود؛ دیگری تلفن، یک پروفایل دانلودشده و کلاینتی دارد که یک خط در آن را رد می‌کند. تفاوت نه شانس است و نه یک کلید پنهان در داشبورد. ماجرا به سه شرط برمی‌گردد: اینکه پلتفرم از آن‌هایی باشد که AWS برای کلاینت خودش پشتیبانی می‌کند، اینکه ابزار در دست شما بتواند تبادل مرورگر فدرال را انجام دهد، و اینکه نقطه پایانی اصلاً برای SAML پیکربندی شده باشد. اگر یکی از این سه جا بیفتد، ورود در نقطه‌ای دیگر متوقف می‌شود.
سه شرط تعیین می‌کند که ورود می‌تواند تمام شود یا نه
پلتفرم اول است. AWS کلاینت Client VPN خودش را برای Windows، macOS و Ubuntu روی AMD64 عرضه می‌کند، و تا اواخر اکتبر 2026 صفحه الزامات لینوکس از Ubuntu 22.04، 24.04 و 26.04 نام می‌برد. یک ساخت بازبسته‌بندی‌شده، یک بسته تبدیل‌شده یا توزیعی دیگر ممکن است اجرا شود، اما پلتفرم پشتیبانی‌شده نیست، و وقتی خراب شود، خط پشتیبانی شمایید.
کلاینت دوم است. ورود فدرال یک گزینه پروفایل نیست که هر برنامه سازگار با OpenVPN آن را تجزیه کند. کلاینت ارائه‌شده ارائه‌دهنده هویت شما را در مرورگر باز می‌کند، پاسخ احراز هویت امضاشده را می‌گیرد و آن پاسخ را به نقطه پایانی می‌فرستد. برنامه‌ای که فقط پروفایل را می‌خواند و تونل برپا می‌کند این مرحله را انجام نمی‌دهد، هرقدر هم گزارش اتصالش تمیز به نظر برسد.
نقطه پایانی سوم است. نقطه پایانی‌ای که از اعتبارنامه‌های Active Directory یا گواهی‌های دوطرفه استفاده می‌کند سازوکاری کاملاً متفاوت دارد و عوض کردن کلاینت آن را تغییر نمی‌دهد. پیش از عیب‌یابی هر چیز دیگری، حالت احراز هویت را با کسی که پروفایل را صادر کرده تأیید کنید.
در مجموع، سه شرط یک جدول تصمیم کوتاه می‌دهند:
| Platform | AWS-provided client | Completes the SAML exchange | What that means |
|---|---|---|---|
| Ubuntu 22.04 / 24.04 / 26.04, AMD64 | Yes | Yes | Normal sign-in path; debug stages, not platforms |
| Windows or macOS | Yes | Yes | Same path, different installer |
| Android | No published client | No | Needs a different access design, not a different profile |
| Other Linux distributions | No | Depends on the tool | Runs at your own support risk |
چرا ورود OpenVPN در auth-federate متوقف می‌شود
پروفایل صادرشده AWS Client VPN دستوری دارد که به کلاینت می‌گوید احراز هویت بیرون از تونل و از طریق فدراسیون انجام می‌شود. کلاینت عمومی OpenVPN یا آن خط را یکسره رد می‌کند یا نادیده می‌گیرد و آن‌گاه هیچ اعتبارنامه‌ای برای عرضه ندارد. اینجا بیشتر تلاش‌های اندروید پایان می‌یابد: پروفایل وارد می‌شود، برنامه اعتراض می‌کند، یا اتصال با خطای پیکربندی می‌میرد پیش از آنکه حتی یک بسته دستگاه را ترک کند.
حذف auth-federate گام بعدی وسوسه‌انگیز است و یک شکست روشن را به شکستی گیج‌کننده تبدیل می‌کند. برداشتن یک دستور، نقطه پایانی SAML را به احراز هویت با نام کاربری و گذرواژه تبدیل نمی‌کند. نقطه پایانی هنوز پاسخ SAML امضاشده انتظار دارد و آنچه کلاینت به‌جای آن می‌فرستد را رد می‌کند. گذرواژه حساب شما، پروفایل دانلودشده و یک اظهارنامه کپی‌شده اعتبارنامه‌های قابل‌تبادل نیستند.
ورود به ارائه‌دهنده هویت در Chrome روی تلفن فقط ثابت می‌کند که ارائه‌دهنده هویت کاربر را پذیرفته است. درباره رسیدن پاسخ به کلاینتی که بتواند آن را به نقطه پایانی بازگرداند چیزی نمی‌گوید. الزامات احراز هویت فدرال دقیقاً به همین دلیل کلاینت ارائه‌شده را بخشی از جریان می‌کنند: مرحله مرورگر لازم است و کافی نیست.
مسیر پشتیبانی‌شده میزکار لینوکس چگونه است
بسته‌ای را که AWS برای Ubuntu AMD64 منتشر می‌کند با مدیر بسته سیستم نصب کنید و سپس اتصال را از همان کلاینت باز کنید، نه اینکه پروفایل را در یک برنامه VPN همه‌کاره وارد کنید. از پروفایلی استفاده کنید که مدیر شما برای این نقطه پایانی صادر کرده است؛ نشانی بازگشت یا شناسه کلاینت را از راهنمای قدیمی‌تر جایگزین نکنید، حتی اگر کلاینت آن را بپذیرد.
اتصال را آغاز کنید، ورود و هر درخواست MFA را در مرورگری که باز می‌شود کامل کنید و بگذارید جریان بازگشت از مرورگر به کلاینت تمام شود. سپس نشانی خصوصی‌ای را که واقعاً نیاز دارید، از نو درخواست کنید. صفحه‌ای که ورود موفق را اعلام می‌کند شاهد برپا شدن تونل نیست.
کلاینت لینوکس پورت‌های TCP محلی 8096 تا 8115 را برای پاسخ‌های SAML رزرو می‌کند. وقتی انتقال پس از پذیرش شما توسط ارائه‌دهنده هویت معلق می‌ماند، ببینید چه چیزی از قبل در آن بازه گوش می‌دهد:
ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"
یک پورت اشغال‌شده، یا نرم‌افزار امنیتی نقطه پایانی که شنونده loopback را مسدود می‌کند، ورودی می‌سازد که کامل به نظر می‌رسد و سپس هرگز وصل نمی‌شود. آن بازه را محلی نگه دارید. این مسیر بازگشت سمت کلاینت است، نه چیزی که در گروه امنیتی EC2 یا قاعده فایروال دروازه باز شود، و باز کردنش به اینترنت مواجهه را زیاد می‌کند بی‌آنکه چیزی را درست کند.
پیش از تغییر هر چیز، مرحله شکست‌خورده را بخوانید
سرزنش کلاینت واکنش معمول است، اما هر نقطه شکست به صاحب دیگری تعلق دارد. نخست روشن کنید واقعاً کجا هستید.
- هیچ پنجره مرورگری باز نمی‌شود. حالت احراز هویت پروفایل، اتصالی که انتخاب کردید و یکپارچگی با مرورگر پیش‌فرض میزکار را بررسی کنید.
- ارائه‌دهنده هویت حساب را رد می‌کند. تخصیص حساب، ثبت MFA یا پیکربندی برنامه SAML، همه قلمرو مدیر است.
- مرورگر تمام می‌شود اما کلاینت هرگز وصل نمی‌شود. پاسخ احراز هویت منقضی یا غیرقابل‌استفاده، پورت بازگشت مسدودشده، یا انتقال ناموفق.
- تونل برپاست اما برنامه در دسترس نیست. مسیرهای نقطه پایانی، قواعد مجوزدهی، گروه‌های امنیتی، DNS. تکرار ورود مرورگر نمی‌تواند مجوز شبکه‌ای را که نیست بیفزاید.
هنگام ارجاع، متن خطای کلاینت و زمان تلاش را نگه دارید. این ادعا که SAML خراب است و این ادعا که کلاینت هرگز پاسخ احراز هویت معتبری دریافت نکرده، آدم‌ها را به دو جای کاملاً متفاوت می‌فرستد.
وقتی با این حال نیاز اندروید است
اندروید پلتفرمی نیست که AWS کلاینتش را برای آن منتشر کند، پس پاسخ صادقانه این است که کلاینت موبایل پشتیبانی‌شده‌ای برای نصب وجود ندارد. این یک محدودیت طراحی است، نه معمايی که روی تلفن با ویرایش پروفایل تا وصل شدن چیزی حل شود.
آنچه می‌تواند تغییر کند طراحی دسترسی پشت آن است و این تصمیم با مدیر است: یک مسیر دسترسی برنامه‌ای تأییدشده به تنها سرویس داخلی که تلفن نیاز دارد، یک محصول VPN موبایل‌پذیر که سازمان از قبل اداره می‌کند، یا یک میزکار پشتیبانی‌شده برای نقطه پایانی‌ای که فقط SAML به کار می‌برد. هر گزینه پیکربندی نقطه پایانی، ثبت هویت و قواعد مجوزدهی خودش را می‌آورد و کاربر هیچ‌یک از این‌ها را از پروفایل دانلودشده نمی‌تواند بسازد.
ابزارهای شخص ثالث که ادعا می‌کنند این شکاف را می‌بندند به بازبینی صریح پشتیبانی و امنیت نیاز دارند که MFA، مدیریت پاسخ، سیاست دستگاه و آهنگ به‌روزرسانی را پوشش دهد. وجودشان آن‌ها را کلاینت اندروید ارائه‌شده از سوی AWS نمی‌کند و نباید برای کار کردن یکی از آن‌ها مواد احراز هویت قابل‌استفاده مجدد را به تلفن منتقل کنید.
به مدیر سه واقعیت بدهید نه یک رشته طولانی درباره دستورها: حالت احراز هویت نقطه پایانی، منبع خصوصی‌ای که تلفن باید به آن برسد و مهلت. همین برای انتخاب میان میزکار، مسیر دسترسی برنامه‌ای و یک محصول VPN تازه کافی است.
پیش از باز کردن تیکت دیگر، شرط‌ها را به ترتیب بررسی کنید: پلتفرم در فهرست کلاینت‌های ارائه‌شده، ابزاری که بتواند تبادل مرورگر را کامل کند، نقطه پایانی‌ای که واقعاً برای فدراسیون پیکربندی شده، و در لینوکس بازه پورت‌های loopback. نخستین موردی که شکست می‌خورد همان است که باید درست شود. هر چه پس از آن است حدس است.