استثناهای VPN برای هر برنامه وقتی یک سرویس مشترک داده می‌آورد از کار می‌افتند

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

در این تیکت‌ها معمولاً دو چیز با هم خراب می‌شود: مؤلفه اشتباه مستثنی می‌شود، و استثنا بعداً هرگز باریک نمی‌شود.

فرایند را پیدا کنید، نه پنجره را

عملیات ناموفق را بازتولید کنید و فرایندی یا بسته‌ای را که هنگام رخ دادن، مالک اتصال است شناسایی کنید. در Windows این پرسشی متفاوت از این است که کدام پنجره تمرکز دارد، چون انتقال پس‌زمینه می‌تواند توسط سرویسی که با هویت خودش اجرا می‌شود میانجی‌گری شود. در Linux و macOS همان شکاف به شکل فرایندهای کمکی و دیمن‌های سیستم پدیدار می‌شود.

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

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

با DNS مانند مسیری جداگانه رفتار کنید

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

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

ثبت کنید کدام حل‌کننده پاسخ داد و از طریق کدام واسط. همین یک مشاهده سهم بزرگی از گزارش‌های «برنامه مستثنی است اما نام حل نمی‌شود» را حل می‌کند، پس آن را همراه تیکت نگه دارید.

یک کمک‌کننده مشترک را گسترده نکنید

یک سرویس مشترک برای چند برنامه کار انجام می‌دهد، پس مستثنی کردن آن برای تعمیر یک جریان کار، ترافیک بی‌ربط را هم تغییر می‌دهد. سرویس انتقال هوشمند پس‌زمینه در Windows نمونه خوبی از این شکل است: زیرساختی است که بسیاری از برنامه‌ها می‌توانند از آن استفاده کنند، و هویت آن هویت برنامه‌ای نیست که انتقال را درخواست کرده است.

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

اگر الزام به‌کلی نتواند به‌صورت مرز برنامه بیان شود، یک سیاست مبتنی بر مقصد یا طرح تأییدشده دیگری ممکن است از فهرست روبه‌رشد استثناهای کمک‌کننده‌ها فهمیدنی‌تر و ایمن‌تر باشد.

کل جریان کار را بیازمایید، نه گام شکست‌خورده را

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

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

دلیل را بگذارید، نه فهرست نام‌ها را

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

یک خط برای هر استثنا کافی است: بدون آن چه می‌شکند، آن جریان کار مال کیست، و آخرین بار چه زمانی بررسی شده است. این سه میدان فهرستی مرموز را به سیاستی تبدیل می‌کند که کسی می‌تواند از آن دفاع کند.