آیا یک سرویس VPN می‌تواند دسکتاپ‌های Windows، Mac و Linux را پوشش دهد؟
یک طرح دسترسی می‌تواند به دسکتاپ‌های Windows، Mac و Linux خدمت کند، اما تنها پس از تثبیت هویت دروازه، اعتبارنامه، مسیرها و سیاست resolver.
سه لپ‌تاپ در یک تیم، سه منوی VPN متفاوت، و تیکتی که می‌گوید اتصال همه‌جا جز روی Mac کار می‌کند. طرح پشت این کلاینت‌ها می‌تواند یکسان باشد، حتی وقتی منوها یکسان نیستند. آنچه باید هماهنگ شود باریک‌تر از آن است که بیشتر استقرارها فرض می‌کنند: یک هویت دروازه، یک نوع اعتبارنامه، یک مجموعه مسیر و یک سیاست resolver. این چهار مورد را پیش از آنکه کسی پروفایلی صادر کند بنویسید، و کار پلتفرم به جای یک تحقیق به یک چک‌لیست تبدیل می‌شود.
با قرارداد دسترسی شروع کنید، نه با فایل کلاینت
قرارداد دسترسی پنج خط است که بازبین می‌تواند بدون باز کردن کنسول فروشنده آن را بررسی کند. نام می‌برد پیشوندهای خصوصی که باید قابل دسترسی باشند، نامهای داخلی که باید resolve شوند، resolverی که به آن‌ها پاسخ می‌دهد، ترافیکی که اجازه دارد در مسیر محلی بماند، و گواهی دروازه‌ای که کلاینت باید انتظار دیدنش را داشته باشد. هر چیز دیگری در استقرار ترجمه‌ای از این خطوط به قالب فایل است.
یک نمونه اداری شکل را مشخص می‌کند: سرورهای برنامه در 10.60.0.0/16، نامهای خصوصی زیر corp.example، یک resolver داخلی در 10.61.0.53، و مرور معمولی که روی همان مسیری که دستگاه از قبل استفاده می‌کند رها می‌شود. مورد آخر یک تصمیم سیاستی است نه پیش‌فرض کلاینت، و چند کلاینت اگر کسی خلافش را نگوید همه‌چیز را از تونل می‌فرستند. قرارداد را با تاریخ و مالک ثبت کنید، چون همان ثبت است که بعداً به شما می‌گوید تونل تغییر کرده یا سیاست.
یک پروتکل و یک جفت احراز هویت انتخاب کنید که بتوانید از آن دفاع کنید
IKEv2 با احراز هویت دروازه مبتنی بر گواهی و EAP برای کاربر گزینه معمول است وقتی هر سه پلتفرم باید بدون نرم‌افزار اضافی کار کنند، چون Windows، macOS و NetworkManager هر یک کلاینت IKEv2 را همراه دارند. مشکل این است که پشتیبانی از IKEv2 یک برچسب را توصیف می‌کند، نه مجموعه‌ای از قابلیت‌ها. روش‌های EAP، کلیدهای با پشتیبانی سخت‌افزاری، نگاشت گواهی به حساب و اتصال مجدد خودکار برای هر پلتفرم جداگانه پیاده‌سازی می‌شوند. ترکیبی که روی دو مورد از سه مورد کار کند آن‌قدر رایج است که باید تا زمان آزمودن آن را فرض کنید.
این جفت را روی هر پلتفرم هدف پیش از نوشتن راهنمای استقرار آزمایش کنید، نه پس از آن. دروازه‌ای که هم EAP-MSCHAPv2 و هم EAP-TLS را ارائه می‌دهد به شما فضای عقب‌نشینی می‌دهد، به شرطی که عقب‌نشینی به‌عنوان پشتیبانی‌شده مستند شده باشد و در میانه یک حادثه کشف نشود. دو مسیر پشتیبانی‌شده بیمه‌ای ارزان است؛ مسیر سوم مستندنشده یک تیکت آینده است.
وقتی هیچ جفتی هر سه کلاینت را پوشش نمی‌دهد، گزینه‌های صادقانه افزودن یک کلاینت، افزودن یک پروفایل دروازه، یا باریک کردن فهرست پلتفرم‌های پشتیبانی‌شده است. خاموش کردن اعتبارسنجی گواهی روی پلتفرمی که بلندترین شکایت را دارد یکی از آن‌ها نیست. آن تغییر یک شکاف سازگاری را به خطر شنود تبدیل می‌کند و هیچ گام بعدی در استقرار آن را ترمیم نمی‌کند.
از قرارداد برای هر پلتفرم یک مصنوع بسازید
Windows یک پروفایل VPNv2 می‌گیرد که از طریق MDM تحویل می‌شود یا به‌صورت محلی با Add-VpnConnection و بار XML آن ساخته می‌شود. بخش‌هایی که درد می‌کنند دامنه و اعتماد هستند. پروفایل با دامنه دستگاه و پروفایل با دامنه کاربر در مخزن‌های متفاوتی نصب می‌شوند، پس گواهی موردنیاز کلاینت باید در مخزنی باشد که با دامنه انتخاب‌شده می‌خواند. جفت‌سازی اشتباه پروفایلی می‌دهد که پاک وارد می‌شود و سپس در نخستین اتصال شکست می‌خورد.
macOS یک پروفایل پیکربندی با بار VPN مدیریت‌شده می‌گیرد که امضا و از طریق MDM فرستاده می‌شود یا برای یک پایلوت دستی نصب می‌شود. هویت و زنجیره CA به‌صورت بارهای جداگانه سفر می‌کنند، از همین رو یک پروفایل می‌تواند بی‌شکایت نصب شود و باز هم هنگام اتصال شکست بخورد. فهرست بارها را بررسی کنید، نه فقط نتیجه نصب.
Linux به بک‌اند پشت NetworkManager وابسته است، و strongSwan و افزونه NetworkManager بسته‌های جداگانه‌اند. ویژگی‌های اتصال مخصوص افزونه‌اند نه کلیدهای عمومی VPN، پس کلیدی که از افزونه دیگری کپی شده باشد اغلب بدون خطا ذخیره می‌شود و سپس هنگام فعال‌سازی شکست می‌خورد. اتصال را روی یک تصویر تمیز بسازید تا تأیید کنید افزونه همان‌جایی است که واقعاً اجرا خواهد شد.
سه مصنوع در قالب متفاوت‌اند، اما هر یک همان پنج خط قرارداد را رمزگذاری می‌کند. این آزمون تمام‌شدن یک مصنوع است: هر خط جایی بازنمایی شده و هیچ چیز اضافه‌ای در مسیر اختراع نشده است.
| Platform | Artifact | Check before handoff |
|---|---|---|
| Windows | VPNv2 profile or Add-VpnConnection | Scope matches certificate store |
| macOS | Managed VPN payload plus certificate payload | Both payloads present in one profile |
| Linux | NetworkManager connection with strongSwan backend | Plugin package installed on the image |
مسیرها، resolver و اتصال مجدد را روی یک حساب تمیز بررسی کنید
متصل‌بودن آزمون پذیرش نیست. در Windows، Get-VpnConnection پروفایل را نشان می‌دهد و route print نشان می‌دهد آیا پیشوند خصوصی روی رابط تونل نشسته است. در macOS، scutil --nc list سرویس فعال را تأیید می‌کند و scutil --dns ترتیب resolverی را نشان می‌دهد که سیستم واقعاً استفاده خواهد کرد.
در Linux، nmcli connection show --active ثابت می‌کند اتصال برپاست و resolvectl status DNS را برای هر پیوند نشان می‌دهد. resolverی که در فایل اتصال هست اما در خروجی هر پیوند نیست یعنی DNS تقسیم‌شده اعمال نمی‌شود. این تفاوت میان نام‌هایی است که resolve می‌شوند و نام‌هایی که از طریق تونل resolve می‌شوند، و تغییر می‌دهد کدام تیم پشتیبانی گام بعدی را دارد. خروجی هر پیوند را پیش و پس از بالا آمدن اتصال مقایسه کنید، نه فقط پس از آن.
کل بررسی را با حسابی تازه، بدون اعتبارنامه‌های کش‌شده و بدون گواهی نصب‌شده توسط مدیر اجرا کنید. سپس آن را پس از تعلیق و بازگشت دوباره کنید، و یک بار دیگر پس از وادار کردن به ورود دوباره اعتبارنامه‌ها. این دو گذار بیشتر شکست‌های اتصال مجدد را که نخستین اتصال هرگز نشان نمی‌دهد آشکار می‌کنند.
بسته را نسخه‌بندی کنید و مسیر بازگردانی نگه دارید
هر بسته پلتفرم را با بازبینی قراردادی که پیاده می‌کند برچسب بزنید و نسخه‌های کلاینت و دروازه‌ای را که آن را در برابرشان پذیرفتید یادداشت کنید. وقتی رفتار پس از به‌روزرسانی کلاینت تغییر می‌کند، برچسب به قراردادی برای آزمون دوباره اشاره می‌کند نه به فایلی برای حدس زدن.
بسته پیشین هر پلتفرم را در دسترس نگه دارید و فرمان حذفش را کنار آن بنویسید. حذف نصب یک پروفایل VPN تصویر آینه‌ای نصب آن در Windows، macOS یا Linux نیست، و تفاوت‌ها در بدترین زمان ممکن ظاهر می‌شوند. حذف را یک بار روی دستگاهی یدکی تمرین کنید تا بایگانی به جای یک امید، یک طرح شود.