مرورگر شعبه به پروکسی: دو اتصال، دو مسیر

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

گام 1: دو جریان را بنویسید

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

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

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

گام 2: به مرورگر مسیری به شنونده بدهید

نام میزبان پروکسی، پورت شنونده، الزامات احراز هویت و منابع مجاز شعبه را ثبت کنید. این فهرست معیار پذیرش جریان اول است و باید هم تحلیل نام داخلی و هم مسیر تونل را شامل شود.

برای سرویس مورد نظر یک قاعده شبکه محدود اعمال کنید، نه انتشار یک پروکسی بدون محدودیت در اینترنت. پروکسی می‌تواند در شبکه داخلی بماند وقتی کلاینت‌های مورد نظرش مسیر پشتیبانی‌شده‌ای به آن دارند.

گام 3: مرورگر را پیکربندی کنید، نه فقط جدول مسیرها را

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

بنویسید کدام برنامه‌ها این تنظیم را رعایت می‌کنند. کلاینت‌های ایمیل، به‌روزرسان‌ها و بازی‌ها اغلب رعایت نمی‌کنند و به استفاده از مسیر ساده ادامه می‌دهند.

گام 4: اتصال رو به جلو پروکسی را اثبات کنید

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

برای HTTPS، CONNECT تونلی باز می‌کند به مقصد درخواستی. ارسال معمولی صفحه رمزگشایی‌شده را به پروکسی نمی‌دهد و غیرفعال کردن اعتبارسنجی گواهی برای بداهه‌سازی بازرسی راه‌حل نیست.

گام 5: چهار خرابی را از هم جدا کنید

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

مرزی را که مشاهده کردید گزارش کنید، نه این خلاصه را که VPN شکست خورده است.

گام 6: دامنه را مشخص کنید و جایگزین را برنامه‌ریزی کنید

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

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