VPN کاری روی Raspberry Pi: اول این پرسش‌ها را بپرسید
نشانی درگاه و واژهٔ Linux قرارداد مشتری نیستند. پیش از نصب هر چیزی، پاسخ‌های پروتکل، معماری، احراز هویت و خط‌مشی را بگیرید.
چهار پاسخ از کارفرما تعیین می‌کند که آیا یک Pi می‌تواند به VPN کاری بپیوندد: کدام پروتکل دروازه را صحبت می‌کند، کدام سیستم‌عامل‌ها و معماری‌ها را پشتیبانی می‌کند، احراز هویت چگونه باید انجام شود، و آیا مشتری‌ای غیر از مشتری رسمی مجاز است. نشانی درگاه و واژهٔ Linux هیچ‌یک از این‌ها را روشن نمی‌کند. پیش از دانلود هر چیزی بپرسید، چون پاسخ‌ها تغییر می‌دهند کدام بسته را نصب می‌کنید و آیا راه‌اندازی بدون صفحه‌نمایش اصلاً عملی است.
چهار پاسخ را بنویسید. باقی این متن چیزی است که هر یک تغییر می‌دهد.
پروتکل دروازه مشتری را تعیین می‌کند
دروازه به یک یا چند پروتکل صحبت می‌کند و مشتری باید همانی را پیاده‌سازی کند که سازمان شما واقعاً اجرا می‌کند. OpenConnect یک پیاده‌سازی مستقل است که با سازگاری با Cisco AnyConnect آغاز شد و اکنون چند دروازهٔ سازمانی دیگر را پوشش می‌دهد؛ این مشتری برندِ فروشنده نیست، و سازگاری پروتکل تضمینی برای پشتیبانی از هر ویژگی دروازه، بررسی وضعیت یا خط‌مشی دستگاه نیست. پروتکل را با تیم شبکه تأیید کنید، نه اینکه آن را از نشانی درگاه استنباط کنید. سپس تأیید کنید که کارفرما این مشتری را برای این استقرار می‌پذیرد.
شواهد سازگاری باید از مستندات کارفرما یا از همکاری که آن را روی همان مدل انجام داده بیاید، نه از وجود یک بسته در یک مخزن.
معماری جزئیات نیست
نسخهٔ سیستم‌عامل و معماری فضای کاربرِ Pi، نسخهٔ مشتری‌ای که قصد استفاده از آن را دارید، و منبع آن بسته را ثبت کنید. نصب‌کنندهٔ x86 به‌خاطر تغییر نام فایلش برای معماری دیگری مناسب نمی‌شود، و مشتری فروشنده‌ای که فقط ساخت‌های x86 ارائه می‌دهد اصلاً نمی‌تواند روی Pi اجرا شود. همین یک واقعیت می‌تواند کل مسئله را پیش از آنکه احراز هویت مطرح شود حل کند. نگهداری منبع بسته را بررسی کنید، نه اینکه یک فایل دودویی سرگردان از یک رشتهٔ انجمن نصب کنید.
فضای کاربر 64 بیتی روی هستهٔ 64 بیتی حالت ساده است؛ فضای کاربر 32 بیتی روی برد 64 بیتی جایی است که مردم بستهٔ اشتباه را نصب می‌کنند. dpkg --print-architecture و uname -m هر دو نیمه را در یک خط پاسخ می‌دهند.
احراز هویت جریان کار را تعیین می‌کند
گذرواژه‌ها، MFA و ورود از طریق مرورگر هر یک جریان کار خود را تحمیل می‌کنند. گواهی‌ای که روی توکن سخت‌افزاری نگهداری می‌شود ممکن است به درایوری نیاز داشته باشد که Pi ندارد، در حالی که جریان SSO می‌تواند پنجره‌ای مرورگر باز کند که نشست بدون صفحه‌نمایش نمی‌تواند نشان دهد. برخی دروازه‌ها دقیقاً برای همین حالت مسیر کد دستگاه یا کپی دستی را ارائه می‌دهند و برخی نه. بپرسید سازمان برای میزبان Linux بدون صفحه‌نمایش کدام روش را پشتیبانی می‌کند، سپس پیش از تکیه بر آن آزمایشش کنید.
یکپارچه‌سازی رابط کاربری انتخابی جدا از احراز هویت است. افزونهٔ NetworkManager می‌تواند اتصالی ترتیب دهد و رازهایش را ذخیره کند، اما نمی‌تواند روش احراز هویت پشتیبانی‌نشده‌ای را سازگار کند. این دو پرسش را جدا نگه دارید.
مرز کارفرما را دست‌نخورده نگه دارید
اگر سازمان مشتری رسمی خود، دستگاه مدیریت‌شده یا توزیع پشتیبانی‌شده‌ای را الزامی می‌کند، آن الزام را رعایت کنید یا جایگزین تأییدشده‌ای بخواهید. غیرفعال کردن بررسی گواهی‌ها، تقلید نتایج وضعیت یا خاموش کردن کنترل‌های نقطهٔ پایانی تا مشتری دیگری پذیرفته به نظر برسد، یک مشکل سازگاری را به نقض خط‌مشی تبدیل می‌کند. گذرواژه‌ها، کوکی‌های نشست و کلیدهای خصوصی را از تاریخچهٔ پوسته و رونوشت گفتگوها دور نگه دارید. یک چالش-پاسخ کارآمد مجوز انتشار مواد نشست نیست.
پس از ثبت‌نام تأییدشده، DNS خصوصی، منابع موردنظر، یک منبع ردشده و اتصال دوباره را بررسی کنید، همه از خود Pi. تونلی که به آن وارد شده‌اید باز هم می‌تواند مسیریابی نادرست داشته باشد یا فاقد مجوز باشد.
خروجی یک توافق قابل پشتیبانی با مالک مشخص است: کدام مشتری، کدام نسخه، کدام مسیر ثبت‌نام. این بهتر از نصب مشتری نزدیک به فروشنده و امیدواری به اختیاری بودن الزامات باقی‌مانده است.