موتور OpenVPN یا Tunnelblick: چه کسی مالک نشست VPN مک است؟

Homebrew یک برنامه OpenVPN نصب می‌کند؛ Tunnelblick مدیری نصب می‌کند که یک یا چند موتور را اجرا می‌کند. این‌ها لایه‌های متفاوتی هستند و پرسش سودمند این نیست که آیا از استفاده از ترمینال خوشتان می‌آید. پرسش این است که چه کسی مالک پیکربندی، تغییرات DNS، درخواست اعتبارنامه و پاک‌سازی هنگام پایان نشست است. یک مالک واحد برای این لایه‌ها همان چیزی است که راه‌اندازی را قابل پیش‌بینی می‌کند.

پنج بررسی زیر را به ترتیب انجام دهید. اولین بررسی که دو مالک دارد همانی است که حالت‌های عجیب نیمه‌متصل را می‌سازد که مردم آن را به خود OpenVPN نسبت می‌دهند. هر بررسی شاهدی را که آن را روشن می‌کند نام می‌برد.

بررسی یکم: کدام فایل دودویی OpenVPN واقعاً اجرا می‌شود

در حالی که متصل هستید pgrep -fl openvpn را اجرا کنید و خط فرمان کامل را بخوانید. مسیر نخست همان موتوری است که واقعاً اجرا می‌شود. در Apple Silicon نصب Homebrew معمولاً زیر /opt/homebrew قرار دارد، در حالی که مک‌های Intel از /usr/local استفاده می‌کنند، و Tunnelblick موتوری را از داخل بستهٔ برنامهٔ خودش اجرا می‌کند.

Tunnelblick موتورها را بسته‌بندی می‌کند و اجازه می‌دهد پیکربندی یکی را انتخاب کند. به‌روزرسانی فرمول Homebrew فایل دودویی مستقل را تغییر می‌دهد، نه موتوری را که یک پروفایل Tunnelblick راه می‌اندازد. اگر برای توضیح تفاوت رفتاری نسخه‌ها را مقایسه می‌کنید، موتور موجود در فهرست پردازه‌ها را مقایسه کنید نه آن یکی در مدیر بسته. فقط رشتهٔ نسخه به شما نمی‌گوید که آن موتور کدام پروفایل را بارگذاری کرده است.

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

بررسی دوم: چه کسی DNS و مسیرها را تغییر می‌دهد

موتور می‌تواند دستورهای up و down خود OpenVPN را اجرا کند، اما مدیر ممکن است مالک همان چرخهٔ عمر باشد. تنظیمات کارساز نامِ Tunnelblick اسکریپت‌های استاندارد اتصال و قطع آن را کنترل می‌کند، و وقتی این یکپارچگی فعال باشد، دستورهای رقیب در پروفایل می‌توانند نادیده گرفته شوند.

این مهم است چون DNS جایی است که یک تونل سالم بیشتر از همه خراب به نظر می‌رسد. در حالی که متصل هستید scutil --dns را بررسی کنید، توجه کنید کدام تحلیل‌گر اول است و تأیید کنید پس از قطع برمی‌گردد. اگر پروفایل انتظار دارد DNS را خودش تنظیم کند در حالی که مدیر هم آن را مدیریت می‌کند، یکی از آن دو می‌بازد.

پیش از نخستین اتصال تصمیم بگیرید کدام لایه مالک DNS است، سپس دستور بازنده را بردارید به جای آنکه هر دو را سر جایشان بگذارید. تغییرات مسیر هم از همان قاعده پیروی می‌کنند: یک مالک، قابل مشاهده در پیکربندی، با مسیر بازگردانی مستند.

بررسی سوم: اعتبارنامه‌ها از کجا می‌آیند

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

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

بررسی چهارم: چه کسی پردازه را آغاز، نظارت و متوقف می‌کند

استقرار مستقل اگر قرار است بالا بماند به یک ناظر نیاز دارد. Launchd می‌تواند موتور را هنگام ورود یا بر حسب تقاضا آغاز کند، پس از فروپاشی دوباره راه بیندازد و تمیز متوقف کند، اما کسی باید آن کار را بنویسد و مالکش باشد. اجرای دستور در ترمینال برای یک آزمون کار می‌کند و نه برای کاربری که پنجره را می‌بندد.

اگر Tunnelblick مالک بماند، به جای راه‌اندازی موتور دوم از کنترل‌های پشتیبانی‌شدهٔ آن استفاده کنید. فایل دودویی Homebrew، وقتی پروفایل کپی‌شده‌ای به آن بدهید، اتصالی مستقل با پیکربندی و بافت یکپارچگی خودش باز می‌کند، نه اینکه به نشست موجود Tunnelblick فرمان بدهد.

هر مالکی که انتخاب کنید، تعریف کنید در خواب، تغییر شبکه و خروج چه اتفاقی می‌افتد. مدیر معمولاً این رویدادها را مدیریت می‌کند؛ پردازهٔ خالی معمولاً نه، و مسیر یا تحلیل‌گر کهنهٔ حاصل به‌آسانی خطای کارساز خوانده می‌شود.

بررسی پنجم: تحویل چگونه تأیید می‌شود

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

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

برای تحویل به Tunnelblick، موتور را برای پیکربندی انتخاب کنید، یکپارچگی DNS مورد نظرتان را فعال کنید و دستورهای پروفایلی را که با آن می‌جنگند بردارید. سپس همان سه بررسی را تکرار کنید. اتصالی که کار می‌کند اما تحلیل‌گر را تغییر یافته رها می‌کند تحویلی ناکام است، حتی اگر تونل بالا آمده باشد.

بسته‌بندی سازگاری با کارساز را روشن نمی‌کند. نیازهای کارخواه خود سرویس را بررسی کنید و تنها وقتی موتور را به‌تنهایی انتخاب کنید که قصد دارید مدیریتش را خودتان تأمین کنید.