ایمیل بدون VPN به سرور می‌رسد: کجا باید قاعده را اعمال کرد
برنامه ایمیل می‌تواند در حالی که VPN قطع است همچنان به سرور برسد. تصمیم بگیرید که سرویس کلاینت‌های مستقیم را رد می‌کند یا مک اصلاً تلاشی نمی‌کند.
ایمیل مدام سراغ سرور می‌رود و VPN قطع است، اما حساب هنوز همگام‌سازی می‌شود. برنامه همان کاری را می‌کند که برایش پیکربندی شده است؛ هیچ چیز در یک نمایه ایمیل معمولی نمی‌گوید سرور فقط از راه تونل در دسترس است. این دو نیاز متفاوت باقی می‌گذارد و آسان است که با هم اشتباه شوند: سرویس باید کلاینت‌های مستقیم را رد کند، یا مک اصلاً نباید تلاش کند.
پیش از انتخاب محصول، نیاز را انتخاب کنید. قاعده سرور و قاعده کلاینت در جاهای متفاوتی شکست می‌خورند، شواهد متفاوتی تولید می‌کنند و به مالکان متفاوتی تعلق دارند. اعمال هر دو زمانی معتبر است که هر دو گزاره درست باشند، اما یکی جایگزین دیگری نیست. هر دو نیاز مشروع‌اند؛ فقط کنترل یکسانی نیستند.
نشانه شبیه مک است، اما سرور می‌تواند منشأ نشت باشد
وقتی ایمیل بیرون از تونل همگام می‌شود، از آنچه سرور می‌پذیرد شروع کنید. اگر شنونده ایمیل به اتصال مستقیم از اینترنت پاسخ می‌دهد، هیچ تنظیم راحتی در سمت کلاینت این واقعیت را تغییر نمی‌دهد. مک در برابر سرویسی که هنوز باز است رفتار عادی دارد.
از مدیر ایمیل بپرسید سرویس چه نشانی مبدأیی می‌بیند. دروازه VPN، پروکسی معکوس یا متعادل‌کننده بار می‌تواند نشانی کلاینت را ترجمه کند، پس مجموعه نشانی‌های پیکربندی VPN ممکن است با آنچه به فرایند ایمیل می‌رسد همخوان نباشد. قاعده‌ای که برای مبدأ اشتباه نوشته شده باشد یا همه را می‌بندد یا هیچ‌کس را.
همین پاسخ می‌گوید سرویس اصلاً می‌تواند کلاینت‌های VPN را تشخیص دهد یا نه. اگر هر کلاینت از همان نشانی پروکسی برسد، پذیرش بر پایه مبدأ نمی‌تواند آن‌ها را جدا کند و نیاز باید به احراز هویت یا به سمت کلاینت منتقل شود.
پذیرش در سرور: مبدأ را رد کنید، نه برنامه را
دیوار آتش میزبان یا شبکه می‌تواند شنونده ایمیل را به بازه‌های مبدأ تأییدشده محدود کند و احراز هویت و TLS را بدون تغییر بگذارد. شرط قاعده‌ای که نشانی‌های دور، زیرشبکه‌ها یا بازه‌ها را تطبیق می‌دهد بلوک ساختمانی معمول است؛ نحو دقیق متعلق به محصول دیوار آتش سرور است، نه به برنامه ایمیل.
این قوی‌ترین مرز است وقتی نیاز چنین باشد که «سرویس نباید به کلاینت‌های مستقیم خدمت کند». حتی اگر کاربر کلاینت ایمیل دیگری نصب کند دوام می‌آورد، چون رد شدن پیش از احراز هویت رخ می‌دهد. همچنین از مک‌ای که سیاست VPN خود را نادیده می‌گیرد جان سالم به در می‌برد.
محدودیتش به همان اندازه مهم است. اتصال ردشده اثبات می‌کند سرویس نشست را رد کرده است؛ اثبات نمی‌کند مک هیچ تلاشی نکرده است. تفکیک DNS، یک TCP SYN به متعادل‌کننده بار پیشین و تلاش دوباره پس از شکست همه می‌توانند پیش از رسیدن به قاعده سرور رخ دهند. اگر نیاز درباره آشکارسازی تلاش‌ها باشد نه دسترسی، پذیرش در سرور فقط نیمی از کنترل است.
اعمال در کلاینت: تلاش را مسدود کنید، نه فقط تونل را
قاعده سمت کلاینت باید ترافیک را ممنوع کند، نه اینکه فقط هنگام باز کردن ایمیل تونلی راه بیندازد. محرک فعال‌سازی برای یک دامنه ایمیل می‌تواند VPN را در لحظه درست بالا بیاورد، اما تعیین نمی‌کند وقتی تونل قطع است یا پس از شکستش چه می‌شود.
از سیاست مسدودسازی پشتیبانی‌شده محصول نقطه پایانی استفاده کنید و دامنه‌اش را آگاهانه تعیین کنید. قاعده در سطح برنامه هر حسابی در آن برنامه ایمیل را در بر می‌گیرد، از جمله حساب‌های شخصی. قاعده در سطح مقصد باید نقاط پایانی IMAP، ارسال و احراز هویت حساب کاری را نام ببرد و باید هنگام تغییر آن نشانی‌ها همچنان کار کند.
هر دو خانواده نشانی و نشست‌های موجود را پوشش دهید. سیاستی که اتصال‌های جدید IPv4 را می‌بندد اما IPv6 یا سوکت برقرارشده را رها می‌گذارد، همگام‌سازی‌های متناوبی می‌سازد که تصادفی به نظر می‌رسند. تغییرات شبکه و چرخه‌های خواب بخشی از همان آزمون‌اند.
قواعد سطح برنامه و سطح مقصد دامنه اثر متفاوتی دارند
مسدودسازی در سطح برنامه ساده است: هیچ ترافیکی از ایمیل بدون تونل خارج نمی‌شود. همچنین خشن است، چون همان برنامه ممکن است حساب شخصی‌ای داشته باشد که هیچ ربطی به سیاست ندارد. کاربران نخست همین را متوجه می‌شوند و آن را به‌عنوان برنامه ایمیل خراب گزارش می‌کنند.
مسدودسازی در سطح مقصد باریک‌تر و نگهداری‌اش سخت‌تر است. به مجموعه کامل نقاط پایانی‌ای نیاز دارد که حساب استفاده می‌کند، از جمله سرویس‌های کشف و احراز هویت، و به فرایندی برای به‌روزرسانی آن‌ها. یکی جا بیفتد و حساب نصفه کار می‌کند؛ بیش از حد در بگیرید و ایمیل بی‌ربط می‌ایستد.
بر پایه واژه‌بندی نیاز انتخاب کنید. «این حساب کاری نباید مستقیم وصل شود» به دامنه مقصد اشاره دارد. «این مک نباید ایمیل را بیرون از VPN اجرا کند» قاعده گسترده‌تر برنامه را توجیه می‌کند، به شرطی که مالک اثر جانبی حساب شخصی را بپذیرد.
رد شدن و نبود تلاش را جداگانه بیازمایید
با یک حساب آزمون اختصاصی، از راه VPN وصل شوید و کارکرد عادی را تأیید کنید. سپس قطع کنید و دو بار بیازمایید: یک بار برای دیدن اینکه سرور ورود را رد می‌کند، و یک بار برای دیدن اینکه مک اصلاً اتصالی را می‌کوشد. این‌ها مشاهده‌های متفاوتی هستند و به گزارش‌های متفاوتی تعلق دارند.
شواهد سمت کلاینت را برای یک SYN یا پرس‌وجوی DNS در حال قطع بودن ببینید، و گزارش سمت سرور را برای نشست ردشده یا پذیرفته‌شده. اگر سرور رد می‌کند اما کلاینت هنوز می‌کوشد، قاعده سرور کار می‌کند و قاعده کلاینت غایب است. اگر کلاینت هیچ تلاشی نمی‌کند اما سرور هنوز کلاینت‌های دیگر را می‌پذیرد، مرز دقیقاً همان‌جایی است که آن را گذاشتید.
مالک اعمال، نشانی مبدأیی که سرور واقعاً می‌بیند، و حساب آزمون استفاده‌شده را ثبت کنید. تغییر بعدی شبکه یا پروکسی می‌تواند آن مبدأ را جابه‌جا کند، و یادداشتی که مقدار مشاهده‌شده را نام می‌برد سریع‌تر از یک دور دیگر حدس بررسی می‌شود.