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

سه پاسخ به این پرسش که آیا VPN کار می‌کند

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

SignalAnswersBlind spot
scutil --nc statusIs the service connected?Third-party clients, wrong routes
route -n getWhere would this go?The peer may be down
A request to the far sideDoes it work now?Slow, and it changes state

یک بررسی سودمند دو مورد نخست را ترکیب می‌کند و سومی را به‌عنوان تأییدی به کار می‌برد که آن دو دروغ نگفته‌اند. هر یک به‌تنهایی حدسی با مهر زمانی است.

شناسه را بخوانید، نه نام نمایشی را

scutil --nc list
scutil --nc status "Office"

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

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

کلاینت شخص ثالث از فهرست پنهان می‌ماند

فهرست خالی به معنای نبود VPN نیست. پیکربندی‌هایی که در تنظیمات شبکهٔ خود سیستم ساخته شده‌اند اینجا دیده می‌شوند؛ یک کلاینت فروشنده، یک نمایهٔ مدیریت یا یک برنامهٔ شخص ثالث می‌تواند تونل فعالی را نگه دارد که این فرمان هرگز نمی‌بیند. ابزار خودش مرجع سرویس خودش است. پرسیدن از scutil دربارهٔ کلاینتی که هرگز نزد آن ثبت نشده چیزی برنمی‌گرداند، و «هیچ» همان پاسخ «قطع‌شده» نیست.

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

وضعیت با مسیریابی یکی نیست

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

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

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

نام‌گذاری مسئله‌ای جداگانه است

ماشین‌های دیگر نمی‌توانند در حالی که نشانی Mac کار می‌کند آن را با نام برسند، و این به‌عنوان نقص VPN گزارش می‌شود. نام میزبان محلی، نام میزبان و رکورد DNS سه چیز متفاوت‌اند. scutil --get LocalHostName نام Bonjour را نشان می‌دهد؛ sudo scutil --set HostName mac-office نامی را تعیین می‌کند که سیستم گزارش می‌کند.

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

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

مقالات مرتبط