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

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

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

ویژگی پشت قاعده

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

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

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

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

بررسی‌ها را به ترتیب اجرا کنید

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

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

هر پاسخ یک واقعیت است، و درخواست استثنا به واقعیت‌ها نیاز دارد. بحث درباره اینکه VPN آزاردهنده است یکی از آن‌ها نیست. پیش از آغاز گفتگو پاسخ‌ها را بنویسید.

استثنایی باریک بخواهید

برنامه، مقصد و عملیات ناموفق را به همین ترتیب گزارش کنید. درخواست نگه داشتن یک به‌روزرسان روی مسیر مستقیم قابل بررسی است؛ درخواست دور زدن تونل برای کل مرورگر نه.

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

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

استثنا را پایدار کنید

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

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