تونل زمانی باز می‌شود که یک نام داخلی را درخواست می‌کنید و زمانی بسته می‌ماند که برنامه بعدی به همان اندازه به آن نیاز دارد. این یک اشکال در برنامه نیست؛ این شکل یک قاعده دامنه است. پیکربندی on-demand اپل شرایط برقراری اتصال را توصیف می‌کند و شکل دامنه‌ای این شرایط پیش از حرکت حتی یک بسته از resolver سیستم یک پرسش می‌کند. دو پرسش مدام با هم اشتباه می‌شوند: تونل چه زمانی باید بالا بیاید و تونل پس از وجود چه چیزی را حمل می‌کند. اولی یک محرک است، دومی سیاست مسیر و resolver، و یک پروفایل معمولاً هر دو را در همان payload تنظیم می‌کند، به همین دلیل یک قاعده دامنه درست باز هم می‌تواند شما را در شبکه اشتباه رها کند.

محرک و انتخاب ترافیک در لایه‌های مختلف قرار دارند

قاعده on-demand در فرهنگ on-demand یک payload VPN زندگی می‌کند: فهرستی مرتب از قواعد که هر یک یک کنش و مجموعه‌ای از شرایط تطبیق دارد. سیستم آن‌ها را زمانی ارزیابی می‌کند که اتصال تغییر کند یا چیزی بخواهد به شبکه برسد، و کنش تعیین می‌کند که تونل بالا بیاید، ارزیابی شود، قطع شود یا نادیده گرفته شود. همه این‌ها در لایه شبکه پلتفرم رخ می‌دهد، پیش از آنکه برنامه شما سوکت داشته باشد.

آنچه پس از آن می‌آید گروه جداگانه‌ای از کلیدهاست: تنظیمات IPv4 و IPv6 تونل، مسیرهای شامل و خارج‌شده آن، نشانی سرورهای DNS و در iOS و iPadOS نگاشت به‌ازای هر برنامه که تعیین می‌کند کدام برنامه‌ها اصلاً اجازه استفاده از تونل را دارند. یک پروفایل می‌تواند محرک گسترده را با مسیر باریک جفت کند، یا محرک باریک را با مسیر پیش‌فرض. فقط یک نیمه را بخوانید و نیمه دیگر مانند یک نقص به نظر می‌رسد.

من یک پروفایل آزمایشگاهی دارم که هر زمان چیزی زیر یک دامنه داخلی درخواست شود متصل می‌شود، اما فقط یک /16 را به تونل مسیریابی می‌کند. دقیقاً همان کاری را می‌کند که payload آن می‌گوید، و از آن نوع پروفایل‌هایی است که تیکت تولید می‌کند: مردم فرض می‌کنند تونل متصل یعنی ترافیکشان داخل آن است.

قاعده دامنه واقعاً چه چیزی از resolver می‌پرسد

شکل دامنه‌ای قاعده، که اغلب connect-if-needed نامیده می‌شود، payload بسته‌ها را بررسی نمی‌کند و URLها را نمی‌پاید. وقتی نامی resolve می‌شود، سیستم آن را با دامنه‌های قاعده مقایسه می‌کند و در صورت تطبیق می‌پرسد آیا آن نام را می‌توان از طریق سرورهای DNS که تونل فراهم می‌کند resolve کرد. اگر resolver تونل پاسخ دهد، نام داخلی شمرده می‌شود و اتصال آغاز می‌شود. اگر به‌جای آن resolver محلی پاسخ دهد، نام خارجی تلقی می‌شود و تونلی ظاهر نمی‌شود. مرور کلی استقرار اپل این‌ها را تشخیص شبکه و سپس ارزیابی اتصال توصیف می‌کند.

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

حافظه نهان هم محرک را حذف می‌کند. به نامی که از قبل در حافظه نهان است ممکن است بدون کاوشی که تونل را شروع می‌کرد پاسخ داده شود، بنابراین قاعده‌ای که دیروز کار می‌کرد پس از راه‌اندازی مجدد یا پس از آنکه تونل مدتی بالا بوده شکست می‌خورد. در macOS دستور sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder وضعیت را بازنشانی می‌کند؛ در iOS روشن و خاموش کردن حالت هواپیما یا راه‌اندازی مجدد دستگاه شروع تمیزی مشابه به شما می‌دهد.

دامنه تطبیق: نام‌ها، برنامه‌ها و شبکه‌ها

تطبیق دامنه یک نوع از چند نوع است. یک قاعده می‌تواند با نوع رابط (Wi-Fi، همراه، Ethernet) و SSID مشخص هم تطبیق یابد، و ورودی‌های به‌ازای هر برنامه یا دامنه Safari یک تونل را به یک گردش‌کار می‌بندند. این بستن تجربه عجیبی را توضیح می‌دهد که در آن فقط یک برنامه متفاوت از بقیه رفتار می‌کند: برنامه‌های دیگر بیرون از دامنه تونل هستند، بنابراین همچنان از مسیر محلی استفاده می‌کنند حتی وقتی نماد تونل می‌گوید متصل است.

ترتیب بیش از آنچه مردم انتظار دارند مهم است. قواعد به ترتیب ارزیابی می‌شوند و نخستین تطبیق کنش را می‌دهد، بنابراین یک قاعده گسترده اتصال-روی-هر-Wi-Fi که بالای یک قاعده دامنه باریک قرار گیرد بی‌صدا برنده می‌شود و قاعده دامنه را غیرقابل‌آزمایش می‌کند. پیش از بازنویسی فهرست دامنه‌ها، تأیید کنید که هیچ قاعده قبلی از قبل تطبیق نیافته است.

به همین دلیل always-on فقط یک قاعده on-demand سخت‌گیرانه‌تر نیست. اجرای always-on یک حالت استقرار جداگانه است با الزامات نظارت و مدیریت خودش؛ تونل را باز نگه می‌دارد به‌جای واکنش به یک نام. اگر چیزی که نیاز دارید تونلی است که هرگز قطع نمی‌شود، قاعده دامنه ابزار اشتباهی است.

حالت‌های شکستی که قاعده خراب را تقلید می‌کنند

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

What you seeLayerFirst check
Tunnel comes up, internal site still failsroute or resolver after connectnetstat -rn, scutil --dns
Tunnel never comes up for that nametrigger pathfresh lookup, cache flush, private DNS
Tunnel comes up for every appscope, or an earlier rulerule order, per-app mapping
Tunnel drops and will not return on the same Wi-Fiinterface or SSID match, admissioncaptive portal, SSID string, auth prompt
Tunnel returns after you disconnect itprofile ownershipprofiles show

درگاه‌های اسیر خط خودشان را دارند، چون Wi-Fi هتل و فرودگاه دقیقاً همان جستجویی را رهگیری می‌کند که قاعده به آن وابسته است. تا زمانی که درگاه دستگاه را نپذیرد، سرور DNS تونل دسترسی‌ناپذیر است، کاوش شکست می‌خورد و شکست مانند دامنه‌ای با املای غلط به نظر می‌رسد. احراز هویت حالت خاموش دیگر است: قاعده می‌تواند فعال شود، تونل می‌تواند شروع به اتصال کند و اتصال روی گواهی منقضی یا اعلانی که روی نمایشگر دیگری ظاهر می‌شود بمیرد.

IPv6 گونه‌ای می‌سازد که تشخیص نادرستش آسان است. به نامی با هر دو خانواده نشانی ممکن است نخست از رکورد AAAA پاسخ داده شود، در حالی که فهرست مسیرهای تونل فقط IPv4 را حمل می‌کند. یک مرورگر موفق می‌شود، دیگری شکست می‌خورد و فهرست دامنه‌ها کاملاً بی‌گناه است.

با یک درخواست واقعی آزمایش کنید، به این ترتیب

پیش از حدس زدن سیاست را بخوانید. در macOS دستور sudo profiles show -type configuration پروفایل‌های نصب‌شده از جمله payload VPN را چاپ می‌کند، scutil --nc list وضعیت سرویس را نشان می‌دهد و scutil --nc show <service> فرهنگ on-demand مورد استفاده سیستم را چاپ می‌کند. در iPhone یا iPad تحت مدیریت همان payload از کنسول مدیریت یا گزارش MDM می‌آید. گزارش‌های شبکه با log stream --predicate 'subsystem == "com.apple.networkextension"' در macOS و از طریق کنسول دستگاه وقتی تلفن متصل است در دسترس‌اند.

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

پس از بالا آمدن تونل، دو لایه را جداگانه بررسی کنید. netstat -rn -f inet و netstat -rn -f inet6 نشان می‌دهند هر پیشوند به کجا اشاره دارد، scutil --dns ترتیب resolverها و اینکه کدام رابط مالک کدام resolver است را نشان می‌دهد و nettop -m route نشان می‌دهد کدام رابط بایت‌ها را حمل کرده است. اگر تونل بالاست و resolver درست است اما منبع همچنان شکست می‌خورد، ویرایش قاعده را متوقف کنید؛ مجوز سمت سرور و مسیر بازگشت را بررسی کنید.

وقتی قاعده متعلق به شخص دیگری است

اگر تونل پس از قطع کردن دوباره ظاهر شد، قاعده معمولاً به یک پروفایل تعلق دارد نه یک برنامه: پیکربندی ارسال‌شده با MDM، یک پروفایل شخصی باقی‌مانده، یا پروفایلی که کلاینت دیگری نصب کرده است. sudo profiles show -type configuration به‌همراه جستجوی کلیدهای on-demand آن را محدود می‌کند و مسیر حذف خود پروفایل است، نه کلید در نوار منو. حذف ورودی سرویس یا برنامه قاعده را باقی می‌گذارد و نصب بعدی دوباره آن را به ارث می‌برد.

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

پیش از ثبت این به‌عنوان اشکال، همان پنج بررسی را انجام دهید: نشانی‌های resolver تونل در payload حاضرند، نامی که در حافظه نهان نبود، هیچ قاعده قبلی از قبل تطبیق نیافته، مسیر AAAA که فهرست مسیرها پوشش می‌دهد، و برنامه داخل دامنه تونل. وقتی هر پنج برقرار باشند، قاعده کار خود را می‌کند و خطا جایی جلوتر در مسیر است.

مقالات مرتبط