VPN مک یک بار وصل می‌شود و سپس زمان‌اش تمام می‌شود: دیمن IKE را پاک کنید

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

در macOS، آن چیز معمولاً دیمن IKE است.

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

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

این تحقیق را پیش از باز کردن حتی یک گزارش محدود می‌کند. پرسش این می‌شود که کدام فرایند مالک درگاه IKE است و فکر می‌کند چه کار می‌کند.

دو دیمن، یک درگاه

سیستم اجرا می‌کند racoon وقتی اتصالی به IKE نسخهٔ 1 صحبت می‌کند. نسخه‌های کنونی هم می‌آورند iked برای IKEv2 و پشتهٔ تازه‌تر IPsec. هر دو می‌توانند UDP 500 و UDP 4500 را بگیرند، و هر دو می‌توانند یک انجمن امنیتی نیمه‌باز را پس از آنکه تلاش اتصال در پرسش رمز لغو شد یا با تغییر شبکه قطع شد نگه دارند.

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

پیش از کشتن هر چیزی مالک را پیدا کنید، چون پاسخ تعیین می‌کند کدام سرویس را دوباره راه بیندازید و بعد کدام گزارش را بخوانید.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

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

کار را دوباره راه بیندازید، نه فرایند را

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

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

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

سپس یک بار وصل شوید و گزارش کلاینت را از ابتدا بخوانید. مذاکره‌ای که از فاز 1 جلو می‌رود و سپس خطای ارسال گزارش می‌کند همان مشکل سوکت محلی را تکرار می‌کند؛ مذاکره‌ای که همتا رد می‌کند بلیت کاملاً دیگری است.

وقتی سرور رد می‌کند

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

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

پیش از تغییر دوبارهٔ کلاینت، گزارش همتا را بخوانید. رد شدن، ناسازگاری سیاست و حذف خاموش سه علت متفاوت‌اند که همه روی صفحهٔ مک شبیه «در حال اتصال» به نظر می‌رسند.

کلاینت‌های قدیمی‌تر و هستهٔ 64 بیتی

کلاینت قدیمی Cisco IPSec یک افزونهٔ هسته بار می‌کند که برای سیستم‌های 32 بیتی و PowerPC ساخته شده است. روی مک‌بوکی که با هستهٔ 64 بیتی بوت شده، آن افزونه بار نمی‌شود و کلاینت زود با خطای 51 شکست می‌خورد چون اصلاً به زیرسیستم VPN نمی‌رسد. هیچ مقدار راه‌اندازی مجدد دیمن افزونهٔ هسته‌ای با معماری اشتباه را درست نمی‌کند.

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

• یک بار بازتولید کنید، سپس پیش از دست زدن به پروفایل بررسی کنید کدام دیمن مالک UDP 500 است.
• نخستین شکست پس از فاز 1 را بخوانید: خطای ارسال به سوکت محلی اشاره دارد.
• کار launchd را دوباره راه بیندازید، نه فقط فرایند را، و تأیید کنید که درگاه آزاد است.
• یک حساب دوم را امتحان کنید تا پنجرهٔ احراز هویت دوبارهٔ سمت سرور را از خرابی کلاینت جدا کنید.
• معماری هسته را پیش از سرزنش کلاینت ثبت کنید.

VPN که دقیقاً یک بار کار می‌کند تا خلافش ثابت شود یک مشکل وضعیت است. پاک کردن دیمن از راه‌اندازی مجدد سریع‌تر است و شواهد گزارش را نگه می‌دارد که راه‌اندازی مجدد دور می‌ریخت.