ساخت ARM پشتیبانی FortiClient برای Raspberry Pi شما نیست

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

گام یک: ردیف یادداشت انتشار بستهٔ دقیق خود را بخوانید

اظهارات پشتیبانی به نسخه گره خورده‌اند، پس با یادداشت‌های انتشار بسته‌ای شروع کنید که سازمان شما تأیید می‌کند. برای نمونه‌ای مشخص، جدول FortiClient Standalone 7.4.7 سیستم‌های Ubuntu 22.04 و 24.04، Red Hat 9 و CentOS Stream 9 با GNOME را فهرست می‌کند. شرط پردازندهٔ Linux آن به شکل Intel یا معادل بیان شده است.

Raspberry Pi OS یکی از آن محیط‌های فهرست‌شدهٔ Linux نیست. این حکمی درباره همهٔ نسخه‌های FortiClient یا پیش‌بینی انتشارهای بعدی نیست؛ بیانیه‌ای درباره همان ردیف در همان سند است. ماتریس نسخه‌ای را که واقعاً می‌خواهید مستقر کنید بخوانید.

یادداشت‌های پردازنده را از ردیف‌های Windows یا macOS به ردیف Linux منتقل نکنید. فروشندگان سکوها را برای هر ویرایش و هر انتشار مستند می‌کنند، و یادداشتی که به یک ردیف مربوط است شاهد دیگری نیست.

گام دو: تأیید کنید Pi چه چیزی اجرا می‌کند

سه فرمان واقعیت‌های محلی را پیش از هر دانلودی روشن می‌کنند:

uname -m
cat /etc/os-release
dpkg --print-architecture

اولی معماری هسته را می‌گوید، دومی توزیع و انتشار، و سومی معماری فضای کاربری را که بسته‌ها برایش ساخته می‌شوند. هستهٔ 64 بیتی با فضای کاربری 32 بیتی ممکن است و این تغییر می‌دهد که کدام بسته را لازم دارید.

سپس بررسی کنید برای آن سکو واقعاً چه چیزی موجود است. جدول بسته‌های منتشرشدهٔ Debian trixie شامل ساخت‌های arm64 و armhf از openfortivpn است. این موجودبودن معماری را در آن توزیع ثابت می‌کند. ثابت نمی‌کند که Fortinet نسخهٔ مشتقی را واجد شرایط می‌داند، و ثابت نمی‌کند که دروازهٔ سازمان شما آن کلاینت را می‌پذیرد.

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

گام سه: پیش از سرزنش کلاینت، دروازه را بررسی کنید

Upstream، openfortivpn را کلاینتی PPP و TLS توصیف می‌کند که pppd را آغاز می‌کند. این پیاده‌سازی مشخصی است و لازم دارد دروازه حالتی سازگار ارائه دهد. نام برند سرور توافق پروتکل نیست.

انتشار دروازه و روش دسترسی فعال‌شده، نام میزبان تأییدشده و مادهٔ اعتماد آن، و جریان هویتی را که سرویس می‌خواهد جمع کنید، از جمله هر عامل دوم و بررسی وضعیت دستگاه. استقرار مدیریت‌شده ممکن است گام‌های ثبت‌نامی بخواهد که کلاینت شخص ثالث هیچ راهی برای انجامشان ندارد.

اتصال را با حسابی که به شما داده شده آزمایش کنید، نه با حساب مدیر، چون ثبت‌نام و سیاست معمولاً به کاربر گره می‌خورند:

sudo openfortivpn vpn.example.com:443 -u <username>

شکست را بخوانید، نه فقط کد خروج. خطای گواهی، وقت‌گذر PPP و رد سیاست سه مسئلهٔ متفاوت‌اند و تنها یکی از آنها مربوط به ARM است.

گام چهار: آن را روی دستگاه، در چارچوب توافق بپذیرید

تنظیم را با یک منبع خصوصی واقعی، تفکیک DNS از طریق تونل، و اتصال دوباره پس از قطع شبکه بپذیرید. سپس تأیید کنید مقصدی که باید دست‌نیافتنی بماند همچنان شکست می‌خورد، چون دسترسی به‌تنهایی درستی سیاست را ثابت نمی‌کند.

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

اگر کارفرما محیط FortiClient مدیریت‌شده‌ای می‌خواهد که Pi نمی‌تواند برآورده کند، یک نقطهٔ پایانی تأییدشده یا میزبان دسترسی تأییدشده بخواهید. اعتبارسنجی همتا را غیرفعال نکنید، بررسی‌های وضعیت را تقلید نکنید و دروازهٔ سازمان را برای جای‌دادن یک ماشین عوض نکنید. نتیجه‌ای که باید نوشته شود این است که کدام ترکیب پشتیبانی‌شده مجاز است، نه اینکه نرم‌افزار متن‌بسته هرگز نمی‌تواند ARM را هدف بگیرد.