হেডলেস ব্রাউজারে প্রক্সি প্রমাণীকরণ VPN রুট নয়

একটি VPN ব্রাউজারের ট্রাফিক প্রক্সি সার্ভারে পৌঁছে দিয়েও ব্রাউজারকে সেই প্রক্সি ব্যবহার করতে অসমর্থ রাখতে পারে, কারণ রুট আর শংসাপত্র দুটি আলাদা জিনিস। হেডলেস অটোমেশনে এই ফাঁক দেখা আরও কঠিন, কারণ কোনো জানালা বা প্রম্পট নেই যা নজরে আসবে। ব্যর্থতা সাধারণত হ্যাং বা সাধারণ নেভিগেশন ত্রুটি হিসেবে দেখা যায়, আর প্রথম প্রবৃত্তি হলো টানেলকে দোষ দেওয়া। নিচের তালিকাটি সেই চারটি বিষয় আলাদা করে যা সত্য হতে হবে, তারপরই একটি প্রমাণীকৃত প্রক্সি দিয়ে হেডলেস অনুরোধ সফল হতে পারে।

দুটি কথোপকথন, দুটি শংসাপত্র

দুটি কথোপকথন ঘটে এবং তারা ভিন্ন পক্ষের। ব্রাউজার প্রথমে প্রক্সি শ্রোতার সাথে সংযোগ করে, যা তার কাছে শংসাপত্র চাইতে পারে; এরপর প্রক্সি গন্তব্যের দিকে পরবর্তী সংযোগ তৈরি বা অনুমোদন করে। একটি VPN প্রথম ধাপ বহন করতে পারে, কিন্তু ব্রাউজারকে চ্যালেঞ্জ করে এমন প্রান্তবিন্দু না হয়েও, দ্বিতীয় ধাপ সম্পর্কে তার কিছু বলার নেই।

HTTP 407 হলো সেই সংকেত যে ক্লায়েন্টকে প্রক্সি অনুরোধের জন্য প্রমাণীকরণ করতে হবে, যা Proxy-Authenticate-এ বহন করা হয় এবং উত্তর Proxy-Authorization-এ প্রত্যাশিত। এটি গন্তব্য ওয়েবসাইটের লগইন নয়, আর দুটিকে মিশ্রিত করা এখানে সবচেয়ে সাধারণ বিভ্রান্তির উৎস।

তাহলে চারটি যাচাই হলো: ব্রাউজার আসলে কোন প্রক্সি বেছে নিয়েছে, 407-এর উত্তর কে দেয়, ব্রাউজার প্রক্রিয়া কোন নেটওয়ার্কে আছে, এবং মানুষ ছাড়া শংসাপত্রটি কীভাবে পৌঁছায়। প্রতিটি স্বাধীনভাবে ব্যর্থ হতে পারে, আর প্রতিটি ব্যর্থতা বাইরে থেকে একই রকম দেখায়। ক্রম অনুযায়ী এগুলো করুন, কারণ পরের যাচাই আগেরটির ক্ষতি পূরণ করতে পারে না। যে প্রক্সি কখনো বেছে নেওয়া হয়নি তাকে প্রমাণীকৃত করা যায় না, আর যে শংসাপত্র শুধু আপনার ল্যাপটপে আছে তা কনটেইনারে পৌঁছাতে পারে না।

যাচাই 1: আসলে কোন প্রক্সি বেছে নেওয়া হয়েছে

নির্বাচন দিয়ে শুরু করুন, কারণ যে ব্রাউজার আপনার প্রক্সি সেটিং উপেক্ষা করে সে চ্যালেঞ্জ পর্যন্তই পৌঁছায় না। Chrome-এ ফ্ল্যাগ হলো --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: শংসাপত্রের পথ

শংসাপত্র নিজেই সেই জায়গা যেখানে বেশিরভাগ মানবহীন সেটআপ ভেঙে পড়ে। Selenium একটি প্রক্সি হোস্ট ও পোর্ট সেট করতে পারে, কিন্তু HTTP প্রক্সি প্রমাণীকরণ সেই কনফিগারেশনের বহনযোগ্য অংশ নয়, আর প্রক্সি URL-এ থাকা শংসাপত্র এমন ব্যবস্থা নয় যার উপর বিভিন্ন ব্রাউজার ও ড্রাইভার সংস্করণে ভরসা করা যায়। সমর্থিত বিকল্পগুলো হলো যেগুলো আপনার প্রকৃত স্ট্যাক নথিভুক্ত করে: চ্যালেঞ্জের উত্তর দেওয়া একটি ব্রাউজার এক্সটেনশন, হেডার যোগ করা এবং শুধু কাজ থেকে পৌঁছানো যায় এমন স্থানীয় ফরওয়ার্ডিং প্রক্সি, অথবা অন্য উপায়ে ওয়ার্কলোড প্রমাণীকরণকারী প্রক্সি। একটি সচেতনভাবে বেছে নিন এবং আপনি যে সঠিক ব্রাউজার, ড্রাইভার ও Selenium সংস্করণ চালাবেন তার বিপরীতে যাচাই করুন।

শংসাপত্রকে ফাঁস হওয়ার জায়গা থেকে দূরে রাখুন। কমান্ড লাইন প্রক্রিয়া তালিকায় দেখা যায়, স্ক্রিনশট টেস্ট রিপোর্টে ঢোকে, ব্রাউজার ট্রেস ও HAR ফাইল হেডার ধরে রাখে, আর কমিট করা টেস্ট কনফিগারেশন চিরকাল থাকে। কাজের সিক্রেট সরবরাহ ব্যবস্থা ও তার রিড্যাকশন নিয়ম ব্যবহার করুন, এবং প্রক্সি অ্যাকাউন্টকে প্রয়োজনীয় গন্তব্য বা ভূমিকায় সীমিত করুন।

যদি প্রতিষ্ঠান বাধ্যতামূলক প্রক্সির বদলে অনুমোদিত সরাসরি VPN রুট দেয়, দুটি নকশা স্পষ্টভাবে তুলনা করুন। নীতি এড়াতে প্রক্সি চুপচাপ বন্ধ করবেন না বা অন্য ক্লায়েন্টের প্রমাণীকরণ নকল করবেন না।

যাচাই 4: ব্রাউজার প্রক্রিয়ার নিজস্ব নেটওয়ার্ক প্রসঙ্গ

এটি সেই যাচাই যা মানুষ এড়িয়ে যায়। একটি ওয়ার্কার, কনটেইনার বা দূরবর্তী Selenium Grid নোড যে ব্রাউজার চালু করে, সেটি সেই পরিবেশের নেটওয়ার্কিং ব্যবহার করে, তাই আপনার ল্যাপটপের VPN সংযোগ ও আপনার শেলের প্রক্সি ভেরিয়েবল এমন পথ বর্ণনা করে যা ব্রাউজার কখনো স্পর্শ না-ও করতে পারে।

ব্যর্থ কাজের জন্য পাঁচটি তথ্য লিখুন: ব্রাউজার হোস্ট, কনফিগার করা প্রক্সি, প্রাথমিক রিজলভার পথ, নির্বাচিত রুট এবং প্রমাণীকরণের মালিক। তারপর ঠিক সেই প্রসঙ্গ থেকে একটি নিরীহ অনুমোদিত অনুরোধ করুন, গন্তব্যের স্বাভাবিক TLS যাচাই ও অ্যাপ্লিকেশন অনুমোদন চালু রেখে। সফলভাবে চালু হওয়া হেডলেস ব্রাউজার প্রক্সি প্রবেশ বা VPN কভারেজ কোনোটিই প্রমাণ করে না, আর ফাঁকা পাতার স্ক্রিনশট কিছুই প্রমাণ করে না। পুরো শৃঙ্খল দিয়ে 200 ফেরত আসা অনুরোধই একমাত্র গণ্য প্রমাণ।

সমাপ্ত ওয়ার্কফ্লোর তিনটি বৈশিষ্ট্য আছে যা একসাথে যাচাই করার মতো। ব্রাউজার হোস্ট থেকে প্রক্সি পর্যন্ত একটি সমর্থিত রুট আছে, একটি স্পষ্ট মধ্যস্থতাকারী নীতি আছে যা প্রক্সি ও গন্তব্যগুলোর নাম বলে, এবং শংসাপত্রের জীবনচক্র আছে যা অপারেটরের অদৃশ্য প্রম্পটের উত্তর দেওয়ার উপর নির্ভর করে না। তিনটির কোনোটিই যদি মানুষের উপর নির্ভর করে, তাহলে কাজটি এখনো মানবহীন নয়, এক্সিট কোড যাই বলুক। পরবর্তী ব্যক্তি পাইপলাইন উত্তরাধিকার পাওয়ার আগে পাঁচটি তথ্য লিখে রাখুন।