Headless Browser Proxy Auth یک مسیر VPN نیست

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

دو گفتگو، دو اعتبار

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

HTTP 407 سیگنالی است که مشتری باید برای درخواست پروکسی احراز هویت کند، که در Proxy-Authenticate با پاسخ مورد انتظار در Proxy-Authorization انجام می شود. این ورود به وب سایت مقصد نیست، و ترکیب این دو رایج ترین منبع سردرگمی در اینجا است.

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

1 را بررسی کنید: کدام پروکسی در واقع انتخاب شده است

با انتخاب شروع کنید، زیرا مرورگری که تنظیمات پراکسی شما را نادیده می گیرد، هرگز به چالش نمی رسد. در کروم، پرچم --proxy-server=proxy.example:3128 است، با --proxy-bypass-list برای موارد استثنا، و Selenium همان چیزی را از طریق گزینه‌های مرورگر خود نشان می‌دهد. یک فایل PAC یک مکانیسم متفاوت با حالت های خرابی خاص خود است.

سپس از داخل محیط مرورگر در حال اجرا به جای از پوسته خود تأیید کنید. یک کاوشگر مستقل با همان پراکسی curl -x http://proxy.example:3128 -v https://example.com است و خروجی پرمخاطب آن نشان می‌دهد که آیا CONNECT موفق شد، چه Proxy-Authenticate برگشت و آیا یک 407 برگردانده شد. اگر curl یک 407 دریافت کرد و مرورگر هنگ کرد، مشکل مسیر اعتبارنامه است نه شبکه. اگر curl موفق شد و مرورگر موفق نشد، مرورگر از پروکسی که شما فکر می‌کنید استفاده نمی‌کند.

2 را بررسی کنید: چه کسی به 407 پاسخ می دهد

یک 407 یک مالک دارد، و نامگذاری آن تصمیم می‌گیرد که تعمیر به کجا برسد. اگر چالش از طرف پراکسی شرکت باشد، رفع مشکل اعتباری است که مرورگر می‌تواند بدون مراقبت ارائه کند. اگر از یک پروکسی بالادستی باشد که اولین مورد به آن فوروارد می کند، اعتبار متعلق به آن پرش دوم است و پراکسی اول ممکن است چالش را بدون تغییر ارسال کند. دامنه و میزبان احراز هویت را در هدر Proxy-Authenticate بخوانید، زیرا آنها کادری را که درخواست می کند نام می برند.

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

3: مسیر اعتبار را بررسی کنید

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

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

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

4 را بررسی کنید: زمینه شبکه خود فرآیند مرورگر

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

پنج واقعیت را برای کار ناموفق ثبت کنید: میزبان مرورگر، پروکسی پیکربندی شده، مسیر حل‌کننده اولیه، مسیر انتخاب شده و مالک احراز هویت. سپس یک درخواست مجاز بی ضرر از همان زمینه دقیق، با تأیید TLS مقصد معمولی و مجوز برنامه ارائه دهید. یک مرورگر بدون هد که با موفقیت راه اندازی می شود نه پذیرش پروکسی و نه پوشش VPN را ثابت می کند، و یک اسکرین شات از یک صفحه خالی هیچ چیزی را ثابت نمی کند. درخواستی که 200 را از طریق کل زنجیره برمی گرداند، تنها مدرکی است که اهمیت دارد.

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