سیستم عامل شما از قبل کدام پروتکلهای VPN را میفهمد؟
Windows، macOS و ChromeOS هر کدام فهرست کوتاهی از تونلها دارند. پیش از افزودن درایور دیگر، از دروازه پروتکل و روش احراز هویت آن را بپرسید.
پیش از دانلود یک کلاینت دیگر، ببینید سیستم عامل از قبل چه چیزی را پیاده کرده است، چون پاسخ اغلب کافی است تا نصبکننده را کاملاً کنار بگذارید. Windows، macOS و ChromeOS هر کدام فهرست ثابت و کوتاهی از پروتکلهای تونل دارند، و دروازهای که یکی از آنها را میفهمد به درایور، سرویس یا مسیر بهروزرسانی اضافه نیاز ندارد. این را نام فروشنده روی بروشور تعیین نمیکند. پروتکل تعیین میکند، اینکه نقطه پایانی چگونه احراز هویت میکند، و اینکه چه نشانی را انتظار دارد.
پروتکل را بخواهید، نه نام محصول را
نام محصول درباره آنچه از سیم میگذرد بسیار کم میگوید. دو دروازه که با یک برچسب فروخته میشوند ممکن است تونلهای کاملاً متفاوتی بخواهند، و یکی ممکن است کلاینت داخلی را بپذیرد در حالی که دیگری همه چیز جز درگاه خودش را رد میکند. دو مدیر که یک جعبه را توصیف میکنند ممکن است اختلاف داشته باشند و هر دو درست باشند، چون لایههای متفاوتی را توصیف میکنند. تونل زیرین است که تعیین میکند نصبکننده لازم است یا نه.
سه پرسش از کسی که دروازه را اداره میکند بپرسید: کدام پروتکل تونل، کدام روش احراز هویت، و کلاینت باید کدام نشانی و پسوند DNS را بپذیرد. پروتکل را با نام بخواهید، و وقتی پاسخ به شکل نام محصول آمد، توضیح دهید چرا به پروتکل نیاز دارید. آن سه پاسخ پیش از دانلود هر نرمافزاری مسئله کلاینت را حل میکند.
دلیلی دارد که نام محصول در این همه تیکت زنده میماند. نشانی درگاه چیزی است که کاربران میبینند، و تونل تا وقتی کار میکند نامرئی است. نوشتن پروتکل در یادداشت تحویل یک خط هزینه دارد و ابهام را برای همه کسانی که بعداً میآیند برمیدارد.
فهرست داخلی کجا متوقف میشود
فهرستهای بومی کوتاهاند، و لبههایشان از محتوایشان مهمتر است. سکویی که L2TP روی IPsec را با کلید از پیش به اشتراکگذاشته میفهمد، SSTP را نمیفهمد، و همین تفاوت کلاینت را تعیین میکند. جدول بر اساس تونل مرتب شده نه فروشنده، پس میتوانید پروتکلی را که دروازه نام برده جستوجو کنید.
| Tunnel | Windows | macOS | ChromeOS | Linux |
|---|---|---|---|---|
| PPTP | built in | removed in 10.12 | no | package |
| L2TP over IPsec, pre-shared key | built in | built in | built in | package |
| L2TP over IPsec, certificate | built in | built in | built in | package |
| SSTP | built in | no | no | package |
| IKEv2 | built in | built in | no | package |
| Cisco IPsec with XAuth | no | built in | no | package |
| OpenVPN | no | no | built in | package |
جدول را در برابر نیازهای دروازه بخوانید نه بروشور. اگر پاسخ L2TP روی IPsec با کلید از پیش به اشتراکگذاشته است، سه سکوی نخست بدون نصب چیز اضافهای وصل میشوند. اگر پاسخ OpenVPN است، پیش از نصب هر چیزی فقط ChromeOS پوشش دارد. پروتکلی که در هیچ ستون داخلی نیست نشانه صادقانهای است که نصبکنندهای در راه است.
Linux ستونی است که در برابر تعمیم مقاومت میکند. پشتیبانی پروتکل آن در دیمنها و افزونههایی زندگی میکند که توزیع تصمیم میگیرد بستهبندی کند، پس یک تصویر مینیمال ممکن است تا وقتی آنها را اضافه نکنید هیچکدام را نفهمد، و دو توزیع با میزکار یکسان میتوانند متفاوت باشند.
پروفایل را از خط فرمان بسازید
هر چیزی که پنل گرافیکی مینویسد جایی ذخیره میشود که میتوانید به آن برسید، و همین است که پروفایل داخلی را قابل خودکارسازی میکند. Windows ورودیهای VPN را در .pbk پروندهها زیر پروفایل کاربر و زیر ProgramData نگه میدارد، و rasphone میتواند ورودیهایی را فهرست و ویرایش کند که فهرست شبکه نشان نمیدهد. این وقتی اهمیت دارد که ماشینی با اسکریپت آمادهسازی میشود و کسی با جادوگر کلیک نخواهد کرد. همچنین توضیح میدهد که چگونه یک پروفایل میتواند وجود داشته باشد بدون اینکه هرگز در سینی سیستم ظاهر شود.
rasdial
rasdial "VpnName" alice
rasdial "VpnName" /disconnect
ویرایش دستی یک .pbk پرونده کار میکند، و همچنین سریعترین راه خراب کردن آن است، پس بگذارید ابزار مالک قالب باشد. macOS سرویسهایش را در پیکربندی سیستم نگه میدارد، و networksetup آنها را با نام سرویس خطاب میکند؛ چند سوئیچ نشانی میخواهند نه نام میزبان، پس نخست نقطه پایانی را حل کنید و مقداری را ذخیره کنید که کلاینت واقعاً به کار میبرد. این تفاوت هنگام خودکارسازی گاز میگیرد، چون اسکریپتی که با نشانی کار میکند میتواند با نام شکست بخورد و خطا مانند دروازه خراب به نظر میرسد نه آرگومان ردشده.
networksetup -listallnetworkservices
networksetup -getinfo "ServiceName"
networksetup -setmanualwithdhcprouter "ServiceName" 198.51.100.20
نامهای سرویس بومیسازیشده و قابل ویرایش توسط کاربرند، پس اسکریپتی که Wi-Fi را سختکد میکند روی نخستین ماشینی که به زبان دیگری تنظیم شده میشکند. نام را از فرمان فهرست بخوانید و به جای حدس زدن آن را منتقل کنید.
گواهیها بدون کلاینت اختصاصی
برخی استقرارها گواهی کلاینت میخواهند و چیز اختصاصی دیگری نه، و این همان حالت میانی است که پیش از پذیرش درایور ارزش آزمایش دارد. گذاشتن گواهی در انبار سکو پشتیبانی میشود؛ این همان کار انداختن ریشه فروشنده در آنجا و اعتماد به اینکه کلاینت پیدایش میکند نیست. اولی جایگذاری آگاهانه است؛ دومی حدسی است با یک تیکت پشتیبانی چسبیده.
جزئیاتی که مردم را میگیرد این است که کلاینت کدام انبار را میخواند. گواهی در انبار کاربر برای کلاینتی که برای انبار ماشین پیکربندی شده نامرئی است، و پیامی که میگیرید میگوید گواهی نیست، نه اینکه در جای اشتباه است. پیش از نتیجهگیری که گواهی اشتباه است هر دو انبار را بررسی کنید. بنویسید پیکربندی کارکننده کدام را به کار میبرد، چون آن یادداشت وقتی ماشین بازسازی میشود از گواهی بیشتر عمر میکند.
Windows دو انبار را صریحاً جدا میکند، و macOS جاکلیدی ورود را از جاکلیدی سیستم جدا میکند. نامها فرق دارند، اما شیوه شکست یکسان است: گواهی معتبری که کلاینت هرگز به آن نگاه نمیکند.
چه چیزی نصبکننده را الزام میکند
برخی دروازهها کلاینت را به انبار گواهی خصوصی، عامل وضعیت، یا تبادل ورودی میبندند که سیستم عامل راهی برای انجامش ندارد. استقرارهای ساختهشده روی سختافزار Check Point، Cisco یا Fortinet اغلب همانجا فرود میآیند، و در آنها کلاینت داخلی میانبر نیست. جایگزین شخص ثالث ممکن است وصل شود و باز هم سیاست را نقض کند، که این را به تصمیم امنیتی تبدیل میکند نه تصمیم راحتی. آنچه سیاست میخواهد را نصب کنید و دلیل را کنار نسخه نصبکننده بنویسید.
آن سابقه بخشی است که مردم از آن میگذرند و بخشی که یک هفته برای مدیر بعدی صرفهجویی میکند: پروتکل، روش احراز هویت، خانواده نشانی و پسوند لازم، با یک خط توجیه برای هر فایل دودویی که باید اضافه میشد. آن را جایی بگذارید که یادداشتهای نصبکننده زندگی میکنند نه در رشته گفتوگو. دو خط مستندسازی از بررسی تکراری جلوگیری میکند.